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

Shyam Sethuram <shyam.ioml@gmail.com> Mon, 05 June 2017 01:31 UTC

Return-Path: <shyam.ioml@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA46124D6C; Sun, 4 Jun 2017 18:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcq1fy-2XXtI; Sun, 4 Jun 2017 18:31:10 -0700 (PDT)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CB9124B0A; Sun, 4 Jun 2017 18:31:09 -0700 (PDT)
Received: by mail-vk0-x230.google.com with SMTP id p62so24893752vkp.0; Sun, 04 Jun 2017 18:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.31.137.145 with SMTP id l139mr8981421vkd.39.1496626268853; Sun, 04 Jun 2017 18:31:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.23.13 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: <D0E98341-9619-4AE9-AC28-95E4E727E4B4@juniper.net> <CAEGVVtAqzLg7WH20O0L=Yb1NxKzJ9WAOPs+fWMUNHHORj1c-bA@mail.gmail.com> <18660_1496398338_59313A02_18660_383_1_53C29892C857584299CBF5D05346208A31D3870E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Shyam Sethuram <shyam.ioml@gmail.com>
Date: Sun, 4 Jun 2017 18:31:08 -0700
Message-ID: <CAEGVVtDA_QHzpT8eH5eDCF7_O8u41xAGJwkwcnKR9F_8UxqcKw@mail.gmail.com>
To: bruno.decraene@orange.com
Cc: "idr@ietf. org" <idr@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "John G. Scudder" <jgs@juniper.net>, "draft-decraene-idr-next-hop-capability@ietf.org" <draft-decraene-idr-next-hop-capability@ietf.org>
Content-Type: multipart/alternative; boundary="001a11457cc21ddc0505512c759f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/DFXLRMfNDBLqDX2oXgAofoO-X7A>
Subject: Re: [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=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, <bruno.decraene@orange.com>; wrote:

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

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

thanks--shyam



>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> thanks--shyam
>
>
>
> On Thu, May 18, 2017 at 9:32 AM, John G. Scudder <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
> 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.
>
>