Re: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-05.txt

<bruno.decraene@orange.com> Fri, 16 June 2017 13:44 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 C5BC81294E2 for <idr@ietfa.amsl.com>; Fri, 16 Jun 2017 06:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 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, T_KAM_HTML_FONT_INVALID=0.01, 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 kVs2ASrG0TN9 for <idr@ietfa.amsl.com>; Fri, 16 Jun 2017 06:44:39 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D86B126C0F for <idr@ietf.org>; Fri, 16 Jun 2017 06:44:39 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id B05401C016D; Fri, 16 Jun 2017 15:44:37 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 88A9A160078; Fri, 16 Jun 2017 15:44:37 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0339.000; Fri, 16 Jun 2017 15:44:37 +0200
From: bruno.decraene@orange.com
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>, Susan Hares <shares@ndzh.com>
CC: idr wg <idr@ietf.org>
Thread-Topic: I-D Action: draft-ietf-idr-bgp-prefix-sid-05.txt
Thread-Index: AQHSubxBjeliABb8XUKQwfepd4WDEKIn1ceg
Date: Fri, 16 Jun 2017 13:44:36 +0000
Message-ID: <6066_1497620677_5943E0C5_6066_346_1_53C29892C857584299CBF5D05346208A47786DD4@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <149268187426.22262.7793747029960844423@ietfa.amsl.com> <7F80FC76-81D7-46AF-9662-633FB769CDF8@cisco.com>
In-Reply-To: <7F80FC76-81D7-46AF-9662-633FB769CDF8@cisco.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.5]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47786DD4OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TG3AnojzT1_Tp7tjNOoh5q02PBY>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-05.txt
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: Fri, 16 Jun 2017 13:44:42 -0000

Hi Stefano,



Thanks for the updated version.

-05 address my comments.



1 possible nit.

In §3.3, IMHO the (primary) goal is that the SRGB TLV must not be changed. Then that it should not be removed.

I believe that the following change would better reflect the goal.



OLD:

   The Originator SRGB TLV contains the SRGB of the node originating the

   prefix to which the BGP Prefix-SID is attached and MUST be kept in

   the Prefix-SID Attribute unchanged during the propagation of the BGP

   update.



NEW:

   The Originator SRGB TLV contains the SRGB of the node originating the

   prefix to which the BGP Prefix-SID is attached and MUST be kept unchanged in

   the Prefix-SID Attribute during the propagation of the BGP

   update.



---

Possibly, what was really meant is “MUST NOT be changed”



Please feel free to silently drop this comment.



Regards,

--Bruno



> -----Original Message-----

> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stefano Previdi (sprevidi)

> Sent: Thursday, April 20, 2017 11:56 AM

> To: idr wg

> Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-prefix-sid-05.txt

>

 > This is the updated version after comments from many reviews in IDR and SPRING.

>

 > Note that section 3.2. "IPv6 SID” proposes now a new format for the IPv6 SID. It shouldn’t be

> a problem since I don’t know any ipv6 implementations yet.

>

 > Thanks.

> s.

>

 > > On Apr 20, 2017, at 11:51 AM, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:

> >

> >

> > A New Internet-Draft is available from the on-line Internet-Drafts directories.

> > This draft is a work item of the Inter-Domain Routing of the IETF.

> >

> >        Title           : Segment Routing Prefix SID extensions for BGP

> >        Authors         : Stefano Previdi

> >                          Clarence Filsfils

> >                          Acee Lindem

> >                          Arjun Sreekantiah

> >                          Hannes Gredler

> >        Filename        : draft-ietf-idr-bgp-prefix-sid-05.txt

> >        Pages           : 16

> >        Date            : 2017-04-20

> >

> > Abstract:

> >   Segment Routing (SR) architecture allows a node to steer a packet

> >   flow through any topological path and service chain by leveraging

> >   source routing.  The ingress node prepends a SR header to a packet

> >   containing a set of segment identifiers (SID).  Each SID represents a

> >   topological or a service-based instruction.  Per-flow state is

> >   maintained only at the ingress node of the SR domain.

> >

> >   This document describes the BGP extension for announcing BGP Prefix

> >   Segment Identifier (BGP Prefix-SID) information.

> >

> >

> >

> > The IETF datatracker status page for this draft is:

> > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

> >

> > There are also htmlized versions available at:

> > https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-05

> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-prefix-sid-05

> >

> > A diff from the previous version is available at:

> > https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-05

> >

> >

> > Please note that it may take a couple of minutes from the time of submission

> > until the htmlized version and diff are available at tools.ietf.org.

> >

> > Internet-Drafts are also available by anonymous FTP at:

> > ftp://ftp.ietf.org/internet-drafts/

> >

> > _______________________________________________

> > I-D-Announce mailing list

> > I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>

> > https://www.ietf.org/mailman/listinfo/i-d-announce

> > Internet-Draft directories: http://www.ietf.org/shadow.html

> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>

 > _______________________________________________

> Idr mailing list

> Idr@ietf.org<mailto: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.