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

Shyam Sethuram <> Mon, 05 June 2017 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECA46124D6C; Sun, 4 Jun 2017 18:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gcq1fy-2XXtI; Sun, 4 Jun 2017 18:31:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9CB9124B0A; Sun, 4 Jun 2017 18:31:09 -0700 (PDT)
Received: by with SMTP id p62so24893752vkp.0; Sun, 04 Jun 2017 18:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=20bUqupbTHe/I3yp0dyHnImL99rqg5AQknMnh7vV6Fo=; b=qh3FQnGkui6/8kKZbLOqnrN0rhoYI4znPm6qBdm3MhK2Bz9SXxlv6PJ0qb7yVUg/UW S4MVlQmlTsLacJte9De+pBym7AIiBVIJUPjaQt4HdKR1ELkQCIQEx6K7jLNids2RGB90 TKaHmhvRzyPLJ309ToZRQAlJt9bZ3e8lFbXjYgxT/E+PZXp8HcSVHsm4ovi+uGZ2UzdT fdKtSU4FH4mP8Ch0CpTkHfTr/k/3HEh28AFiBeL3q1MIaf+9SAvvoU0XXTwFOoyH2exF GD3nLGq7Uh4aHKZ+a6RWKBrXn7Ry9oI8SpW4z5GX3u8W7sOKPDVnU86c2F7X46v4a9CN xJkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=20bUqupbTHe/I3yp0dyHnImL99rqg5AQknMnh7vV6Fo=; b=WcF/hRTfPyFhjC1EPy41twtftxbMBWcbTmmTdfc4PEt858USNXawwJX7VOeBvQo5ov bj5wlgoClBwxLMZ37CdLail8eYaHBdiVR/sGhdUCU3zwR21aWJzHC2fMpwAzZhypODsd 0m8MngkMI9a5pEyA2iSKWUZxOlvM8PXBkaSNYtWPccnK4UOCpVEl3NBXvpxcF5MDOgTi +5u+rBRf6O4yTM0glik4AK3jGLBlkQoOPg2K2xQoO3OFdq6D2qQx9HbQw7HF2YN82V3j Hrbxzryt5IEV8jDTTBbjIazNjyASDPA/jwTsmWpoymLEQy+vrANS96ZiFLcsStVzFdBx uM0g==
X-Gm-Message-State: AODbwcCKQdj2s/+9B1xaj1Ih/w7oNd1xRXJdvNzOkFfbs+nv57zZbzcX utOrXjiwFibtq1geG8Ha+mLKc9awAQ==
X-Received: by with SMTP id l139mr8981421vkd.39.1496626268853; Sun, 04 Jun 2017 18:31:08 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 4 Jun 2017 18:31:08 -0700 (PDT)
In-Reply-To: <18660_1496398338_59313A02_18660_383_1_53C29892C857584299CBF5D05346208A31D3870E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <> <> <18660_1496398338_59313A02_18660_383_1_53C29892C857584299CBF5D05346208A31D3870E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Shyam Sethuram <>
Date: Sun, 4 Jun 2017 18:31:08 -0700
Message-ID: <>
Cc: "idr@ietf. org" <>, "" <>, "John G. Scudder" <>, "" <>
Content-Type: multipart/alternative; boundary="001a11457cc21ddc0505512c759f"
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: Mon, 05 Jun 2017 01:31:12 -0000

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

On Fri, Jun 2, 2017 at 3:12 AM, <>; wrote:

> 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;; draft-decraene-idr-next-hop-
> *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

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.

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
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 :-)
So I guess we'll see if anyone else has any opinion on this.

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.

> 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
nexthop-properties or nexthop-forwarding-info or some such thing. No big
it's just a nit.


> Thanks,
> Regards,
> --Bruno
> thanks--shyam
> 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:
> doc/draft-decraene-idr-next-hop-capability/
> slides from IETF-98:
> 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
> _________________________________________________________________________________________________________________________
> 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.