Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03

[<[e-mail]>]

Hi Shyam,

Please see inline [Bruno2]

From: Shyam Sethuram [mailto:[e-mail]]
Sent: Monday, June 05, 2017 3:31 AM
To: DECRAENE Bruno IMT/OLN
Cc: idr@ietf. org; [e-mail]; John G. Scudder; [e-mail]
Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03


Hi Bruno,
Thanks for the response. Please see inline...


On Fri, Jun 2, 2017 at 3:12 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Dear Shyam,

Thanks for the review and feedback
Please see inline [Bruno]

From: Shyam Sethuram [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, June 02, 2017 12:43 AM
To: John G. Scudder
Cc: idr@ietf. org; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03

Dear authors,

Some of the language sounds similar to that in draft-ietf-idr-tunnel-encaps.
Did you consider augmenting tunnel-encaps in order to signal EL by
adding a new sub-TLV ? It is a transitive attribute but it has a
Remote Endpoint sub-TLV to bind the capability to the specific nexthop.
(It may require a new "tunnel type" to represent plain MPLS nexthops.)
[Bruno] To be honest, we have not considered using draft-ietf-idr-tunnel-encaps. That being said, if it’s a transitive attribute, it seems like a no go as this is the reason why the original ELC BGP attribute had been deprecated: cf this short section https://tools.ietf.org/html/rfc7447#section-1


Yes any transitive attribute would have this issue. The tunnel-encaps
solves this by encoding the nexthop address also in the Remote Endpoint
sub-TLV. The receiver can then compare that with the MP_REACH nexthop
and perform required validations.
[Bruno2] Yes, this may work. Yet, possibly one downstream BGP speaker may remove this tunnel-encaps/Remote EndPoint sub-TLV, in which case this would break the ELC signaling.

At a high level, I wanted to see if there was a way to avoid
having two separate attributes that both essentially deal with nexthops.
It is quite possible that a speaker receives both nexthop-cap and tunnel-encaps
attributes for that same nexthop and has to synthesize the two data before
installing into forwarding. On the other hand, tunnel-encaps has turned into a
"monster attribute" with the whole kitchen sink in it; I can see a fertile
breeding ground for implementation bugs :-)
[Bruno2] Regarding the need of the Entropy Label capability signaling, IMHO idr-next-hop-capability provides a simpler (yet generic) solution than tunnel-encaps. I originally refrained from making this argument as it’s a bit too close to the “my solution is simpler” argument ☹. But your comment seems to be on the same page

So I guess we'll see if anyone else has any opinion on this.
[Bruno2] +1

Coming back to your attribute, as I said earlier w.r.t. coloring, I know
atleast one usecase that wants to apply EL only to particular
types of overlay traffic (for example, L2 vs L3 VPN) recursing to
a given nexthop with EL capability. There are many ways to
address that - a config knob, signal within the NH attribute, use the
color extcomm and so on. If you have any thoughts on the same,
please add it to the draft.
[Bruno2] Valid discussion point. Thanks for bringing it.
A priori, I’d say that coloring is orthogonal. This attribute advertises the capability to receive entropy label. It seems to leave open the ability to use it or not.
Besides, regarding your use case, it seems that the coloring/policy would rather be on the VPN route using the LSP.
Personally, I’m open to add this point to the draft, but I’d welcome other opinions as it seems that the “orthogonal” argument would also be valid.

This would avoid the need to upgrade all the BGP speakers between egress
and ingress. tunnel-encaps also has a Color sub-TLV that can be useful,
for example, when using recursive resoltion, to select a subset of overlay
prefixes that would actually use EL for forwarding.

That said, some nitpicks:
- dependant==>dependent;
[Bruno] Thanks
infact it can be totally avoided and just call it "Nexthop capabilites"
[Bruno] Yes and that was the initial text. However, this had generated some misunderstanding. In particular because the attribute is not advertising the capability of the Next-Hop, but capability of this Next-Hop _for the routes advertised with this capability. In particular, one Next-Hop may advertise different capabilities for different routes. This is in needed for the Entropy Label Capability, as this ELC is FEC specific.
That being said, I’m not that happy with the wording “Next-Hop dependent capability”, hence any other suggestion is welcomed.

- that said, it would be better to avoid reusing the term "Capabilities" for this
attribute though I understand you are trying to draw a parallel with
session capabilities
[Bruno] Indeed, I was trying to draw a parallel with session capability. Could you elaborate on why the term “Capabilities” is not optimal? Would you have alternate suggestion?

I don't have a strong opinion on this, it just seemed odd to reuse
terminology from the base spec for a different purpose. I guess we can call it
nexthop-properties or nexthop-forwarding-info or some such thing. No big deal,
it's just a nit.

[Bruno2] Terminology may be significant point. I would not dismiss it.
On the other hand, “capability” seems a valid term for what we want to advertise so forcing the use of a different term may also create more confusion. The question seems whether the term “capability’ be already to connotated to “session capability”. I’d welcome additional opinion.

Thanks for the feedback.
--Bruno

thanks--shyam



Thanks,
Regards,
--Bruno

thanks--shyam

On Thu, May 18, 2017 at 9:32 AM, John G. Scudder <[e-mail]<mailto:[e-mail]>> wrote:
Hi All,

IDR working group adoption has been requested for draft-decraene-idr-next-hop-capability-03. Please send your comments to the IDR mailing list before June 2, 2017. Please remember that we need affirmative support in order to adopt the draft, so don't be shy.

draft datatracker page: https://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/
slides from IETF-98: https://www.ietf.org/proceedings/98/slides/slides-98-idr-08-bgp-next-hop-dependent-capabilities-00.pdf

Since in part this draft specifies a replacement for the Entropy Label Capability Attribute (ELCA) that was defined by the MPLS WG in RFC 6790 and deprecated by RFC 7447, I have cc'd the MPLS WG mailing list. Since the proposed new attribute is a generic container with the ELCA replacement just the first application, the current draft is targeted to IDR and not MPLS (this was discussed during IETF-93).

Thanks,

--John
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls


_________________________________________________________________________________________________________________________



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.


_________________________________________________________________________________________________________________________

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.