Re: [Idr] [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: idr@ietfa.amsl.com
Delivered-To: idr@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, 04 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/idr/KcU8-hjwSLJ2NRtwWRSAnVG2PH4>
Subject: Re: [Idr] [mpls] Working Group adoption call for draft-decraene-idr-next-hop-capability-03
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-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. > >
- [Idr] Working Group adoption call for draft-decra… John G. Scudder
- Re: [Idr] Working Group adoption call for draft-d… UTTARO, JAMES
- Re: [Idr] [mpls] Working Group adoption call for … Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Idr] [mpls] Working Group adoption call for … christian.jacquenet
- Re: [Idr] [mpls] Working Group adoption call for … John G. Scudder
- Re: [Idr] [mpls] Working Group adoption call for … bruno.decraene
- Re: [Idr] [mpls] Working Group adoption call for … Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [Idr] [mpls] Working Group adoption call for … Shyam Sethuram
- Re: [Idr] [mpls] Working Group adoption call for … bruno.decraene
- Re: [Idr] [mpls] Working Group adoption call for … Shyam Sethuram
- Re: [Idr] [mpls] Working Group adoption call for … bruno.decraene