Hi Igor Good catch on the intra-as / inter-as.
Igor & Jorge I agree the errata is correct. Thanks <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 Wed, Jan 29, 2025 at 5:55 AM Jorge Rabadan (Nokia) < jorge.raba...@nokia.com> wrote: > Hi Igor and Ryan, > > I also think the errata is correct, and I agree with your analysis, Igor. > > Thanks. > Jorge > > From: Igor Malyushkin <gmalyush...@gmail.com> > Date: Wednesday, January 29, 2025 at 2:04 AM > To: Gyan Mishra <hayabusa...@gmail.com> > Cc: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Matthew Bocci > (Nokia) <matthew.bo...@nokia.com>, bess@ietf.org <bess@ietf.org>, Gunter > van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > Subject: Re: [bess] Re: Errata on RFC7117 and RFC8584 > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > 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
