[bess] Re: Errata on RFC7117 and RFC8584

[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]
>