Re: [Idr] draft-ietf-idr-next-hop-capability

[Aijun Wang <[e-mail]>]

Hi, Bruno:

No. Let the “BGP Next-hop dependent Capabilities Attributes” transitive is more reasonable.
There is also another drawback of your bellowing proposal: how to encode the RLD value? Keep still the current “Entropy Label Next-Hop dependent Capabilities” in your document? Then there will be two places to encode the same information.

Aijun Wang
China Telecom

> On Sep 16, 2022, at 21:45, [e-mail] wrote:
> 
> 
> Of-list, I’ve been told that some form of backward compatibility with a deployed software (namely ELCv2, minus the squatted code-point) is a significant aspect for some actors.
>  
> I think that there may be a path to account for both the past history (ELCv2) and the future generic capabilities (BGP Next-Hop Capability) with the following attribute encoding:
> -Transitive BGP attribute, code point TBD.
> - Capability encoding :
>  
>       +---------------------------------------------------------+
>       | Address Family Identifier (2 octets)                    |
>       +---------------------------------------------------------+
>       | Subsequent Address Family Identifier (1 octet)          |
>       +---------------------------------------------------------+
>       | Length of Next Hop Network Address (1 octet)            |
>       +---------------------------------------------------------+
>       | Network Address of Next Hop (variable)                  |
>       +---------------------------------------------------------+
>  
> Followed by an optional set of NH Capabilities encoded as
>                      +------------------------------+
>                      | Capability Code (2 octets)   |
>                      +------------------------------+
>                      | Capability Length (2 octets) |
>                      +------------------------------+
>                      | Capability Value (variable)  |
>                      ~                              ~
>                      +------------------------------+
>  
>  
> That way:
> - Existing implementations see the same content as ELCv2/v3. All they need is to accept and ignore trailing octets
> - Other BGP Next-Hop capabilities may be encoded as BGP Next-Hop capability code and allowing capability value.
>  
> The main drawback that I can see is that if, in a distant future, one implementation would need to advertise some BGP Next-Hop Capabilities but without advertise ELC, we would need to define a BGP Next-Hop capability code to signal the non-support  of ELC (negative capability announcement).
> However, given the existing history (ELCv2), that may be seen as a reasonable way to merge both approaches into a single solution, with minimal impact for existing implementations (accept trailing octets, use a different codepoint).
>  
> Hope this helps,
> Regards,
> Bruno
>  
>  
>  
>  
>  
>  
> From: DECRAENE Bruno INNOV/NET 
> Sent: Friday, September 16, 2022 2:11 PM
> To: [e-mail]; 'Gyan Mishra' <[e-mail]>
> Subject: draft-ietf-idr-next-hop-capability
>  
> Dear WG, Gyan
>  
> draft-ietf-idr-next-hop-capability provides the ability to advertise BGP Next-Hop dependent capabilities. This is typically useful for advertising data plane related capabilities.
> The draft also defines a first BGP Next-Hop capability to advertise the Entropy Label Capability. As such the draft updates RFC6790.
>  
> For this, the draft defines a new non-transitive BGP Attribute.
> The use of a non-transitive attribute (vs a transitive attribute) has benefits and disadvantages, more specifically with regards to legacy implementations not supporting draft-ietf-idr-next-hop-capability.
>  
> - the benefit of using a non-transitive attribute is that the attribute is automatically removed by implementation not supporting draft-ietf-idr-next-hop-capability, with no extra complexity (logic, data, code and related tests/bugs) as RFC 4271 already provides the non-transitivity.
> - the cost of using a non-transitive attribute is that a BGP node which is both 1) propagating the BGP route while not in the data plane path (not changing the BGP Next-Hop) and  2) not supporting draft-ietf-idr-next-hop-capability will remove the attributes/Next-Hop capabilities even though it would not need to as the BGP Next-Hop (hence the Next-Hop capabilities) is unchanged. So essentially the benefit is for BGP Route Reflectors which do not support yet draft-ietf-idr-next-hop-capability. The benefit is likely to be transient and for a small portion of the nodes (e.g. 1%)  however it’s definitely real and helps for incremental deployments.
>  
> I have two questions for the WG:
> - is the above pro & con analysis complete or are there points that would need to be added or removed ?
> - given the pro & con, does the WG prefer the use of a non-transitive or a transitive capability?
>  
>  
> Note that moving to a transitive attribute would require to add extra logic/code and extra data in the attribute (both being described in draft-scudder-idr-entropy-label) and in short:
> - the extra data: capability Next-Hop (AFI, SAFI, length of Next-Hop field, Next-Hop address)
> - the extra logic: if Next-Hop address is different in the attribute and in the BGP Next-Hop, then disregard and remove the attribute.
> The editor and authors of draft-scudder would be welcome to join as co-authors. (To be transparent, the chairs and AD would likely impose a 5 or 6 authors limit)
>  
> Regards,
> Bruno
>  
>  
>  
>  
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr