Gyan, I’m sorry for a mistake with your name. I’ll be more attentive next time!
Ср, 29 янв. 2025 г. в 17:04, Igor Malyushkin <gmalyush...@gmail.com>: > > 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
