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

[[e-mail]]

Hi all,

Thank you for the persons who responded either on list or of-list.

Support has been expressed for the use of a non-transitive attribute for draft-ietf-idr-next-hop-capability and no objection raised.

Draft will be updated accordingly.

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.