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

<> Fri, 02 June 2017 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B765412E05C; Fri, 2 Jun 2017 03:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aCNuk8cMq2ub; Fri, 2 Jun 2017 03:12:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 612B2126DED; Fri, 2 Jun 2017 03:12:20 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id A7C82406F7; Fri, 2 Jun 2017 12:12:18 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by (ESMTP service) with ESMTP id 718C71A0051; Fri, 2 Jun 2017 12:12:18 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0339.000; Fri, 2 Jun 2017 12:12:18 +0200
From: <>
To: Shyam Sethuram <>
CC: "idr@ietf. org" <>, "" <>, "John G. Scudder" <>, "" <>
Thread-Topic: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03
Thread-Index: AQHS2yhsdTrNoJjhFUemOGtXLiyqVKIRVsqQ
Date: Fri, 2 Jun 2017 10:12:17 +0000
Message-ID: <18660_1496398338_59313A02_18660_383_1_53C29892C857584299CBF5D05346208A31D3870E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A31D3870EOPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jun 2017 10:12:23 -0000

Dear Shyam,

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

From: Shyam Sethuram []
Sent: Friday, June 02, 2017 12:43 AM
To: John G. Scudder
Cc: idr@ietf. org;;
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

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?



On Thu, May 18, 2017 at 9:32 AM, John G. Scudder <<>> 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:
slides from IETF-98:

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).


mpls mailing list<>


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.