Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)

<bruno.decraene@orange.com> Tue, 14 March 2017 08:57 UTC

Return-Path: <bruno.decraene@orange.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 94EBD129469; Tue, 14 Mar 2017 01:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 9egJVvRq2tyS; Tue, 14 Mar 2017 01:57:44 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC3E129441; Tue, 14 Mar 2017 01:57:44 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 3F4724036C; Tue, 14 Mar 2017 09:57:43 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id EEFB31A0087; Tue, 14 Mar 2017 09:57:42 +0100 (CET)
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.0319.002; Tue, 14 Mar 2017 09:57:42 +0100
From: <bruno.decraene@orange.com>
To: "John G. Scudder" <jgs@juniper.net>, Stefano Previdi <sprevidi@cisco.com>
Thread-Topic: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)
Thread-Index: AQHSnDvzGI7wSSizeEyT+I67EhY6v6GUBGLg
Date: Tue, 14 Mar 2017 08:57:41 +0000
Message-ID: <4289_1489481863_58C7B087_4289_4597_1_53C29892C857584299CBF5D05346208A31C63CDC@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com> <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup> <C1DBB996-CD5F-4297-AB15-D2B85EFAB13F@juniper.net> <C565EB30-F554-4006-B947-23E77832B5ED@cisco.com> <41D02020-B0F5-478C-8FFE-5EEE93D29E06@juniper.net>
In-Reply-To: <41D02020-B0F5-478C-8FFE-5EEE93D29E06@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/W4gppZNsesTO43k3HFYUTD8ciek>
Cc: "idr@ietf.org" <idr@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" <draft-ietf-idr-bgpls-segment-routing-epe@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 14 Mar 2017 08:57:46 -0000

> From: John G. Scudder [mailto:jgs@juniper.net]  > Sent: Monday, March 13, 2017 9:54 PM
> 
 > Thanks, Stefano.
 > 
 > Bruno, at your convenience can you confirm that you're satisfied with the resolution?

-11 addresses my comments.

Thank you John, Stefano.

> Looks
 > OK to me even though the changes don't precisely adhere to your suggestions ("Link NLRI
 > uses the Protocol-ID value" instead of "Link NLRI uses the BGP Protocol-ID value"). 

Indeed.
I still think that not indicating the Protocol-ID to use (either by its name "BGP" or its value "7")  is sub-optimal (or not useful), however, this text in section 6.1 is illustrative only. The normative text in §4 does state both the name and the code point. So this is good enough for me.

On a side note "(to be assigned by IANA)" seems wrong as the value has been assigned http://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml  (And fixing this would also address the point above.)

--Bruno

> The
 > rfcdiff is https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-11.txt
 > 
 > --John
 > 
 > > On Mar 13, 2017, at 6:31 AM, Stefano Previdi (sprevidi) <sprevidi@cisco.com> wrote:
 > >
 > > John, Bruno,
 > >
 > > sorry for having missed that. I’ll resubmit right now. I integrated all comments. Regarding
 > the missing "section 3.1" (referring to the isis draft), I replaced text with the reference to
 > draft-ietf-idr-bgp-ls-segment-routing-ext which defines the bgp-ls tlv for advertising the
 > SRGB. I gave this as an example. I also moved draft-ietf-spring-segment-routing into the
 > normative references section.
 > >
 > > Thanks.
 > >
 > > s.
 > >
 > >
 > >> On Mar 10, 2017, at 8:52 PM, John G.Scudder <jgs@juniper.net> wrote:
 > >>
 > >> Hi Authors,
 > >>
 > >> I see that yesterday's -10 revision doesn't address Bruno's comments, below. Can you
 > please either update the document if you accept Bruno's suggestions, or otherwise discuss
 > them on the list? We can't declare the WGLC to be satisfactorily finished until this is
 > resolved.
 > >>
 > >> Thanks,
 > >>
 > >> --John
 > >>
 > >>> On Feb 16, 2017, at 11:50 AM, bruno.decraene@orange.com wrote:
 > >>>
 > >>> Hi,
 > >>>
 > >>> I’ve read the draft, please find below some minor comments:
 > >>>
 > >>> ---
 > >>> §4.3
 > >>> "      *  A 4 octet index defining the offset in the SID/Label space advertised by this
 > router using the encodings defined in  Section 3.1."
 > >>>
 > >>> - Following the recent addition of the SRLB Label Space, I'd rather have the text
 > explicitly refers to name of that Label space. e.g.
 > >>> OLD: SID/Label space
 > >>> NEW: SRGB
 > >>>
 > >>> - Which (SRGB) advertisement? I'm assuming the IGP one, but I guess someone may
 > imagine using the BGP "Originator SRGB TLV". Then what if the node runs multiple IGP with
 > different SRGB configured?
 > >>>
 > >>> - Note that this document has no "Section 3.1". The text seems borrowed from the IS-IS
 > SR draft, hence may be adding the name of this draft would just solve the point. (with a
 > normative reference to this IS-IS draft)
 > >>>
 > >>> ---
 > >>> OLD: The Link NLRI uses the new Protocol-ID value (to be assigned by IANA)
 > >>> proposed NEW: The Link NLRI uses the BGP Protocol-ID (TBD1)
 > >>>
 > >>> (“new” may become unspecific 2 years from now)
 > >>>
 > >>> ---
 > >>> One could probably argue that [I-D.ietf-spring-segment-routing] should be a normative
 > reference.
 > >>>
 > >>> Thanks,
 > >>> Regards,
 > >>> --Bruno
 > >>>
 > >>>
 > >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Susan Hares
 > >>> Sent: Thursday, February 16, 2017 12:35 AM
 > >>> To: idr@ietf.org
 > >>> Cc: 'Alvaro Retana (aretana)'; spring@ietf.org
 > >>> Subject: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe -
 > (2/15/2017 to 3/1/2017)
 > >>>
 > >>> This begins a 2 week IDR WG last call on draft-ietf-idr-bgpls-segment-routing-epe from
 > (2/15 to 3/1/2017)    There are two implementations describe on the wiki at:
 > >>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgpls-segment-routing-epe%20
 > >>>
 > >>> The two implementation are from  Cisco IOS-XR release 6.0.2 and Cisco Nexus Switch
 > N9000/N3000 platforms running NX-OS 7.0(3)I1(1) or greater.   The authors will indicate on
 > the list and in the wiki the following information :
 > >>>
 > >>> 1)      Were these implementations separate implementations?
 > >>> 2)      What were the results of the interoperability tests?
 > >>>
 > >>> This work is linked to the draft-ietf-spring-segment-routing-central-epe work in the
 > SPRING WG. Based on the two drafts, the WG should might consider:
 > >>> 1)      Is there need for this work in deployments in networks/
 > >>> 2)      Is this technically ready for publication?
 > >>> 3)      Does it fit with the spring informational draft?
 > >>>
 > >>> For the ease of reference the web references are below:
 > >>> https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/
 > >>> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-central-epe/
 > >>>
 > >>> Sue Hares
 > >>>
 > ______________________________________________________________________
 > ___________________________________________________
 > >>>
 > >>> 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 mailing list
 > >>> Idr@ietf.org
 > >>> https://www.ietf.org/mailman/listinfo/idr
 > >>
 > >


_________________________________________________________________________________________________________________________

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.