Subject: [Idr] draft-decraene-idr-next-hop-capability-01.txt

From: <[email-masked]>
Date: Mon, 6 Jul 2015 20:13:50 +0000

Hi all,

Please find below an updated version of the draft presented in Dallas.

Main changes are the following:
- New co-authors: Kireeti Kompella,  Wim Henderickx
- Slightly improved "error handling" section of the BGP attribute
- New section defining the "error handling" of the MPLS Entropy Label BGP Next-Hop Capability.
- Some re-rewording of the "Entropy Label Next-Hop Capability" section
	- -00 was mostly a copy past from RFC 6790 (which defines the MPLS Entropy Label & the original and now deprecated BGP attribute)
	- -01 is expected to be more precise thanks to comments from Eric Rosen (many thanks)
- New section 4 "BGP Next-Hop Capability Code Operation"
	- Nothing outstanding, but better when explicitly stated	 
- Addition of the optional ability to advertise the "Readable Label Depth" of the LSP(s) advertised in the NLRI
	- Still need some polishing
- Improved wording, some typo corrected

Diff:           https://www.ietf.org/rfcdiff?url2=draft-decraene-idr-next-hop-capability-01

Comments welcomed.

In particular, the name of the BGP Attribute could have a better name (to be proposed):
	- Currently called Next-Hop Capability
	- But the capability is not only Next-Hop specific but more precisely Next-Hop AND path specific. In particular, for different UPDATE having the same Next-Hop, the capability may be different.
	- I’d welcome any suggestion of name.
		- We probably want to keep the term "Next-Hop" somewhere as this is a key property of the BGP attribute which is removed when the Next-Hop is changed.

Thanks,
Regards,
Bruno

PS: long (boring) email, but you saved a (boring) presentation in Pragues

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 9:46 PM
To: Wim Henderickx; Kireeti Kompella; Kireeti Kompella; DECRAENE Bruno IMT/OLN; Wim Henderickx; DECRAENE Bruno IMT/OLN
Subject: New Version Notification for draft-decraene-idr-next-hop-capability-01.txt

A new version of I-D, draft-decraene-idr-next-hop-capability-01.txt
has been successfully submitted by Bruno Decraene and posted to the IETF repository.

Name:		draft-decraene-idr-next-hop-capability
Revision:	01
Title:		BGP Next-Hop Capabilities
Document date:	2015-07-06
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-decraene-idr-next-hop-capability-01.txt
Status:         https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/
Htmlized:       https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-decraene-idr-next-hop-capability-01

Abstract:
   RFC 5492 defines capabilities advertisement for the BGP peer.  In
   addition, it is useful to know the capabilities of the BGP Next-Hop,
   in particular for forwarding plane features.  RFC 5492 is not
   applicable because the BGP peer may be different from the BGP Next-
   Hop, in particular when BGP Route Reflection is used.  This document
   defines a mechanism to advertise such BGP Next Hop Capabilities.

   This document defines a new BGP non-transitive attribute to carry
   Next-Hop Capabilities.  This attribute is deleted when the BGP Next
   Hop is changed.

   This document also defines a Next-Hop capability to advertise the
   ability to handle the Entropy Label defined in RFC 6790.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_________________________________________________________________________________________________________________________

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.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 14 Jul 2015 08:28:58 +0000

Hi Bruno, 

I've read this draft and here are some comments:

section 1. 

Currently it says " This attribute is deleted when the BGP Next Hop is changed." 

According to the specification in section 3, to make it complete it is better to add "A new Next-Hop Capabilities attribute MAY be added each time the BGP Next Hop is changed to reflect the capabilities of the new Next Hop."

section 6. 

It says "A BGP speaker S that sends an UPDATE with the BGP Next-Hop NH MAY include the Entropy Label Next-Hop Capability only if ..."

According to the conditions of including the entropy label next hop capability, it actually reflects the entropy label capability of the whole downstream path. To make this work, it would require that each hop along the path include the Entropy Label Next-Hop Capability in its update if it meets these conditions. Thus I'd suggest to replace the "MAY" here with "MUST" or "SHOULD".

section 6.1

The "readable label depth" can be regarded as another forwarding plane feature, which may be used independent of the entropy label capability. Thus I'd suggest to allocate a dedicated Next-hop capability code for it.

As for the name of this new attribute, I agree it is Next-Hop AND path specific. Personally I think "Next-Hop capability" is OK, since it is called a BGP Path Attribute, which implies that it could be path-specific:).

Best regards,
Jie

> From: Idr [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, July 07, 2015 4:14 AM
> To: idr wg list
> Subject: [Idr] draft-decraene-idr-next-hop-capability-01.txt
> 
> Hi all,
> 
> 	- -00 was mostly a copy past from RFC 6790 (which defines the MPLS
> Entropy Label & the original and now deprecated BGP attribute)
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-decraene-idr-next-hop-capability-01
> 
> 
> Comments welcomed.
> 
> 	- But the capability is not only Next-Hop specific but more precisely
> Next-Hop AND path specific. In particular, for different UPDATE having the same
> Next-Hop, the capability may be different.
> 		- We probably want to keep the term "Next-Hop" somewhere as this is
> a key property of the BGP attribute which is removed when the Next-Hop is
> changed.
> 
> 
> Thanks,
> Regards,
> Bruno
> 
> To: Wim Henderickx; Kireeti Kompella; Kireeti Kompella; DECRAENE Bruno
> IMT/OLN; Wim Henderickx; DECRAENE Bruno IMT/OLN
> Subject: New Version Notification for
> draft-decraene-idr-next-hop-capability-01.txt
> 
> 
> URL:
> https://www.ietf.org/internet-drafts/draft-decraene-idr-next-hop-capability-01
> .txt
> Status:
> https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/
> Htmlized:
> https://tools.ietf.org/html/draft-decraene-idr-next-hop-capability-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-decraene-idr-next-hop-capability-01
> 
> Abstract:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Fri, 31 Jul 2015 14:03:52 +0000

Hi Jie,

Thanks for your careful reading and feedbacks.
Sorry for the delay.

Please see inline [Bruno]

> From: Dongjie (Jimmy) [mailto:[email-masked]] > Sent: Tuesday, July 14, 2015 10:29 AM
> 
> Hi Bruno,
> 
> According to the specification in section 3, to make it complete it is better to
> add "A new Next-Hop Capabilities attribute MAY be added each time the
> BGP Next Hop is changed to reflect the capabilities of the new Next Hop."

[Bruno] You are correct.
Proposed new text: "When the BGP Next Hop is changed, this attribute is deleted or possibly modified to take into account the capabilities of the new BGP Next-Hop."
 
> section 6.
> 
> It says "A BGP speaker S that sends an UPDATE with the BGP Next-Hop NH
> MAY include the Entropy Label Next-Hop Capability only if ..."
> 
> According to the conditions of including the entropy label next hop capability,
> it actually reflects the entropy label capability of the whole downstream
> path.

[Bruno] You are correct.
This is inline with what RFC 6790 originally defined for the BGP Entropy Label Capability attribute (later deprecated in RFC 7447)

> To make this work, it would require that each hop along the path
> include the Entropy Label Next-Hop Capability in its update if it meets these
> conditions. Thus I'd suggest to replace the "MAY" here with "MUST" or
> "SHOULD".

[Bruno] "MUST" is not needed as this is not an interoperabilty issue. Besides, between ASes, one may want to filter this capability which advertises capability of your own AS.
"SHOULD" is debatable. This is a configuration/policy choice.

Note that regarding the Entropy Label part, as priory I felt that the right option was to specify the same behavior as originally defined in RFC 6790. On this specific point RFC 6790 used as MAY:
"However, if T changes the NEXT_HOP attribute for U and in the data plane pops the entire label stack to process the payload, T MAY include an ELC attribute for UPDATE U' if both of the following are true:"
https://tools.ietf.org/html/rfc6790#section-5.2

> section 6.1
> 
> The "readable label depth" can be regarded as another forwarding plane
> feature, which may be used independent of the entropy label capability.
> Thus I'd suggest to allocate a dedicated Next-hop capability code for it.

[Bruno] Good point.
In theory, you are right. In practice, this really depends how the "readable label depth" is specified.
In draft-ietf-mpls-spring-entropy-label, it is specified in the context of the Entropy Label, hence the presence of the Entropy Labels is assumed.
However, you are perfectly right that the concept could be generalized to different ways of doing the load-balancing. (e.g. on the IP/customer packet).
I'll think more about this point. In the meantime, feel free to express your comment to the authors of draft-ietf-mpls-spring-entropy-label ;-)

> As for the name of this new attribute, I agree it is Next-Hop AND path
> specific. Personally I think "Next-Hop capability" is OK, since it is called a
> BGP Path Attribute, which implies that it could be path-specific:).

[Bruno] Thanks for the feedback.
(a naming option is "Next-Hop dependant" which is more accurate but longer)

Many thanks,
Best regards,
Bruno 

> > - Addition of the optional ability to advertise the "Readable Label
> > Depth" of the
> > LSP(s) advertised in the NLRI
> > In particular, the name of the BGP Attribute could have a better name
> > (to be
> > proposed):
> > Next-Hop AND path specific. In particular, for different UPDATE having
> > the same Next-Hop, the capability may be different.
> > a key property of the BGP attribute which is removed when the Next-Hop
> > is changed.
> >
> >
> > Thanks,
> > Regards,
> > Bruno
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> > 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.