Hi Gian, Section 9.2.2 cannot be applied, it says that explicitly:
Usage of leaf A-D routes is described in the "*Inter-AS* Inclusive P-Multicast Tree A-D/Binding" and "Optimizing Multicast Distribution via Selective Trees" sections. The section in question is named "*Intra-AS* Inclusive P-Multicast Tree Auto-discovery/Binding", not *Inter*. Please, pay attention to it. At the same time, Sections 4 and 4.1 describe which routes they exactly expect: VPLS auto-discovery using BGP, as described in [RFC4761 <https://www.rfc-editor.org/rfc/rfc4761>] and [RFC6074 <https://www.rfc-editor.org/rfc/rfc6074>], enables a PE to learn the VPLS instance membership of other PEs. And: To participate in the VPLS auto-discovery/binding, a PE router that has a given VSI of a given VPLS instance originates a BGP VPLS Intra- AS A-D route and advertises this route in Multiprotocol (MP) IBGP. The route is constructed as described in [RFC4761 <https://www.rfc-editor.org/rfc/rfc4761>] and [RFC6074 <https://www.rfc-editor.org/rfc/rfc6074>]. These must be VPLS A-D routes, not Leaf routes, and they don't have an Originating Router IP field. ... then the local PE MUST use the Originating Router's IP Address information carried in the *Intra-AS A-D route* to add the PE, that originated the route, as a leaf node to the LSP. This MUST be done irrespective of whether or not the received Intra-AS A-D route carries the PMSI Tunnel attribute. In my understanding, a "leaf" above is specifically *for the RSVP-TE* *case *when a sending PE can't expect any actual leaf routes from others because of the nature of *inclusive *tree construction and it still needs to signal tunnels toward them (thus, needs to know their addresses). So, I still think the errata is correct. P.S. I don't like the idea of using the BGP NH as an identifier of a sender. I think the IETF should provide better tools for that case (as well as for the case of the identification of a service instance from a sender). But this is out-of-scope and cannot be applied right here for the problem in question, so BGP NH is the only option. ср, 29 янв. 2025 г. в 14:10, Gyan Mishra <hayabusa...@gmail.com>: > > Hi Jorge > > I reviewed the errata. > > For the RFC 7117 errata I had a question. > > Notes: > > There is no such field as the Origination Router's IP Address in any VPLS > A-D routes (RFC4761, RFC6074). For Intra-AS cases the BGP NH IP address can > be used for the leaf tracking. > Section 9.2,2 describes the VPLS Leaf A-D route which has route key and > originating routers IP address that the source sends Leaf A-D for S-PMSi > w/o PTA attribute present. > > RFC 6514 procedure uses the same leaf a-d route for mLDP P2MP of RSVP-TE > P2MP PTA described in section 4.4 for lead a-d route. > > To me it seems the text is correct in RFC 7117. > > The other errata is correct for RFC 8584. > > > Kind Regards > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > > > On Tue, Jan 28, 2025 at 9:24 AM Jorge Rabadan (Nokia) <jorge.rabadan= > 40nokia....@dmarc.ietf.org> wrote: > >> Hi Matthew, >> >> I checked the two errata and I agree they are correct. >> Thanks. >> Jorge >> >> From: Matthew Bocci (Nokia) <matthew.bocci=40nokia....@dmarc.ietf.org> >> Date: Monday, January 27, 2025 at 3:17 AM >> To: bess@ietf.org <bess@ietf.org> >> Cc: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> >> Subject: [bess] Errata on RFC7117 and RFC8584 >> >> WG >> >> >> >> There are a couple of errata on these RFCs that I would appreciate your >> feedback on: >> >> >> >> https://www.rfc-editor.org/errata_search.php?eid=7977 (Multicast in >> Virtual Private LAN Service (VPLS)) >> >> - I believe this is correct and can be verified. >> >> >> >> https://www.rfc-editor.org/errata_search.php?eid=5900 (Framework for >> Ethernet VPN Designated Forwarder Election Extensibility) >> >> - I believe this is correct and can be verified. >> >> >> >> Please let me know by Monday 10th Feb if you have any concerns with >> verifying these. >> >> >> >> Best regards >> >> >> >> Matthew >> _______________________________________________ >> BESS mailing list -- bess@ietf.org >> To unsubscribe send an email to bess-le...@ietf.org >> > _______________________________________________ > BESS mailing list -- bess@ietf.org > To unsubscribe send an email to bess-le...@ietf.org >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
