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

Shyam Sethuram <> Thu, 01 June 2017 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E1C8129ABD; Thu, 1 Jun 2017 15:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 f9Pq306gzq18; Thu, 1 Jun 2017 15:42:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4785A129AA3; Thu, 1 Jun 2017 15:42:55 -0700 (PDT)
Received: by with SMTP id j17so35944816uag.3; Thu, 01 Jun 2017 15:42:55 -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=5PSpX9s/b+YMpP6cFZPWjAea93PjtRPHM6gHcpwks3I=; b=GFvZtOla4HQlTxDSbJzkSbeXoWywXzpVoQ2PqeKykmO3zXdvDWKE64SroCDI+LuXDe /p01Ggbo2SLjdsGyVbBtm430U9FYDpA2nCck1X/YYOrgxz0fCSf4k+B59uh64VyWlFml n5qIM3OzrrL2O7/0n41+QoUN6EipSlljewhWc2a+bPdvcxQ0zFNvUazMipsDf5OEOnZa 6JQla2/yeLwy6z9uGvaoJjGC72WGoJ/ll8NkA+CXwiUCG0PXVY/1Ev1wPBwOWJqcROjr SxAppQOyT/UBkR21UuusxX8wqRgLdP5SlcgTLy2/NBb2QDtYmPu8gUBZiKzXRLz2VNCs meyA==
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=5PSpX9s/b+YMpP6cFZPWjAea93PjtRPHM6gHcpwks3I=; b=eoz/MHKc4q99KcyspcR+A8vuzRDeDjxjB8N/Q2TmmyBbz3J6M/60DkFKLF7bT2i2wL r28WAAMgMujDuHMvKCEdBL1Fwjl0BjCF4PotFMxe/NJCLFinI921Up4C5XVmdchDUYEu g/Q+7ksou7Ik8qDLyLkah9vnTbthoXblBcfpAuRn7PFXBacjXnSrLDa9vp0r1hLh/MNw a/jb3H4OrTOKSUBUKzh6a5Yf/PBCF8mIV4sDoyxKAIdCFcMBHUKbuNy4imT9Q8YQ6AF7 KfgV8eaVTHzyFA5gagFUhGwCfGush3dmFkSZ9ugvlsLQLS1jk4gk+uGHanOUpBMHk+Hg 11Ug==
X-Gm-Message-State: AODbwcD/B8Jx9XK/4XCTU4iO236spU6oi79bCa6Ef4si6LvEvDHAqyZ1 MhBAPZsbRGkrvpeRcYgSrMcTULfhGA==
X-Received: by with SMTP id r9mr2181249uaa.149.1496356974465; Thu, 01 Jun 2017 15:42:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Jun 2017 15:42:53 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Shyam Sethuram <>
Date: Thu, 1 Jun 2017 15:42:53 -0700
Message-ID: <>
To: "John G. Scudder" <>
Cc: "idr@ietf. org" <>,,
Content-Type: multipart/alternative; boundary="f403045dcf9ceb9c2a0550edc140"
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: Thu, 01 Jun 2017 22:42:57 -0000

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

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; infact it can be totally avoided and just
call it "Nexthop capabilites"
- 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


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