Hi Igor Ditto & me more attentive in reading the draft!
Cheers Gyan On Wed, Jan 29, 2025 at 5:56 AM Igor Malyushkin <gmalyush...@gmail.com> wrote: > 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
