[bess] Re: Errata on RFC7117 and RFC8584

[Igor Malyushkin <[e-mail]>]

Gyan,

I’m sorry for a mistake with your name. I’ll be more attentive next time!

Ср, 29 янв. 2025 г. в 17:04, Igor Malyushkin <[e-mail]>:

>
> 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 <[e-mail]>:
>
>>
>> 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 [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>>
>>
>> On Tue, Jan 28, 2025 at 9:24 AM Jorge Rabadan (Nokia) <jorge.rabadan=
>> [e-mail]> wrote:
>>
>>> Hi Matthew,
>>>
>>> I checked the two errata and I agree they are correct.
>>> Thanks.
>>> Jorge
>>>
>>> From: Matthew Bocci (Nokia) <matthew.bocci=[e-mail]>
>>> Date: Monday, January 27, 2025 at 3:17 AM
>>> To: [e-mail] <[e-mail]>
>>> Cc: Gunter van de Velde (Nokia) <[e-mail]>
>>> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> BESS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>