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

[[e-mail]]

Hi Aijun,

Thanks for your valuable feedback.
Please see inline [Bruno]



Orange Restricted
From: Aijun Wang <[e-mail]>
Sent: Friday, September 16, 2022 5:10 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: [e-mail]; Gyan Mishra <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Idr] draft-ietf-idr-next-hop-capability

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.
[Bruno] RLD is a good point. Thanks for raising it. May one option would be to define an “RLD Next-Hop dependent capability”
Yes the below proposal is a compromise (because IMO having two independent solutions would be worse).
Regards,
Bruno
Aijun Wang
China Telecom


On Sep 16, 2022, at 21:45, [e-mail]<mailto:[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]<mailto:[e-mail]>; 'Gyan Mishra' <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.