Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

<bruno.decraene@orange.com> Tue, 10 December 2019 17:41 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3812098B; Tue, 10 Dec 2019 09:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 i6XgVxBbgfqs; Tue, 10 Dec 2019 09:41:15 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.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 2184C120999; Tue, 10 Dec 2019 09:41:14 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 47XS5z60lFz2yQ6; Tue, 10 Dec 2019 18:41:11 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 47XS5z4vCkzCqkT; Tue, 10 Dec 2019 18:41:11 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0468.000; Tue, 10 Dec 2019 18:41:11 +0100
From: bruno.decraene@orange.com
To: draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
CC: "6man@ietf.org" <6man@ietf.org>, 'SPRING WG List' <spring@ietf.org>
Thread-Topic: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AdWrjZKMyJw/FcG0Qj29O28HuDn7+wD8DNgg
Date: Tue, 10 Dec 2019 17:41:11 +0000
Message-ID: <23508_1575999671_5DEFD8B7_23508_75_6_53C29892C857584299CBF5D05346208A48D24FC3@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48D24FC3OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/y0iUfXMUzSB2CKcbIGeyQqoFgZk>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 17:41:18 -0000

Hi Pablo, authors

"4.13.  End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps"
is clear that an IPv6 encapsulation is performed. e.g with the below text
"  S14.   Push a new IPv6 header with its own SRH containing B"

However, I find that "4.14.  End.B6.Encaps.Red: [...] with reduced SRH" is a little less clear on that. E.g.,

"This is an optimization of the End.B6.Encaps behavior."
Looks good.


"   The new SRH is created as described in Section 4.1.1 of [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>]."
Is not that specific. Could you please explicitly add that an IPv6 outer header is added ?


"  End.B6.Encaps.RED  [...] with reduced SRH insertion SRv6 instantiation of a Binding SID"
Does not looks good.
Please remove any reference to "SRH insertion". "IPv6 encapsulation with an SRH header" would be preferred.


"     4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps  20
     4.14<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.14>. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . .  21<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-21> >

May be
OLD: End.B6.Encaps.Red: [...] with reduced SRH
NEW: End.B6.Encaps.Red: End.B6.Encaps with reduced SRH

(this does fit in a single line)

Thank you,
Best regards,
--Bruno




From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, December 5, 2019 6:15 PM
To: 'SPRING WG List'
Cc: 6man@ietf.org; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming


Hello SPRING,



This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].



Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.



You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.



If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)



Thank you,

Bruno



[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05




_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.