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> Thu, 16 February 2017 16:50 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 B98E012960B; Thu, 16 Feb 2017 08:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qm5qUPDe4ouD; Thu, 16 Feb 2017 08:50:08 -0800 (PST)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79C21294FA; Thu, 16 Feb 2017 08:50:07 -0800 (PST)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 9BF2860633; Thu, 16 Feb 2017 17:50:06 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 6DC00180055; Thu, 16 Feb 2017 17:50:06 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0319.002; Thu, 16 Feb 2017 17:50:06 +0100
From: <bruno.decraene@orange.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [spring] IDR WG 2 week WG LC on draft-ietf-idr-bgpls-segment-routing-epe - (2/15/2017 to 3/1/2017)
Thread-Index: AdKH5ALnHgVYM3zURr+F4Gs1EKSVZgAj0X2g
Date: Thu, 16 Feb 2017 16:50:05 +0000
Message-ID: <10484_1487263806_58A5D83E_10484_6197_1_53C29892C857584299CBF5D05346208A1ED67062@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com>
In-Reply-To: <00f901d287e4$16ecb2f0$44c618d0$@ndzh.com>
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: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED67062OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NfB8KTqY8F8tPzuuDVyDD8I-828>
Cc: "spring@ietf.org" <spring@ietf.org>
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: Thu, 16 Feb 2017 16:50:09 -0000

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.