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

Dear Shyam,

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

From: Shyam Sethuram [mailto:shyam.ioml@gmail.com]
Sent: Friday, June 02, 2017 12:43 AM
To: John G. Scudder
Cc: idr@ietf. org; mpls@ietf.org; draft-decraene-idr-next-hop-capability@bgp.nu
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

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?

Thanks,
Regards,
--Bruno

thanks--shyam

On Thu, May 18, 2017 at 9:32 AM, John G. Scudder <jgs@juniper.net<mailto:jgs@juniper.net>> 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
mpls@ietf.org<mailto:mpls@ietf.org>
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.