Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11
bruno.decraene@orange.com Fri, 12 March 2021 14:20 UTC
Return-Path: <bruno.decraene@orange.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580EA3A08E4; Fri, 12 Mar 2021 06:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 yfpHVLv4LRfL; Fri, 12 Mar 2021 06:20:46 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (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 DA6F53A0C03; Fri, 12 Mar 2021 06:20:43 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 4DxnzG2FkKz7tlq; Fri, 12 Mar 2021 15:20:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1615558842; bh=n0UOmTrj51rXCoe40jJNFR8ELtMP/SnQ07cXq1NmYC4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ibTYQgP1Jes6a5Hnf3HOxdMS499RMixbCv8ijJyci2KBF7hYWjkPEhBuRoPZr/6DK zgsf3bXKnbPcqeimGF6YI6en+hygttjvwhh/Pr6UvcnbVHvCLdENgRtl6OYIs5VwhA jm8w77JHfzPeCiEUrN0l/ZM485AhDsQj3NWHvzBPiNXaQqTS49tx+yFEwWYu3JfAzR CXLiKHMIEZDD5rSzSX1SvtfJFGwdDPY31YmmxPVkHpKKdGawQBfLx4ow4E8mI8BqCX Aaoqdnfo6WBdx3bdSmRJZRNi7DwFwETkZr8lUzZrCIiwl6ESwYn/PFVB7x/Y94DoDg cvRwjpP0cKXOQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4DxnzG0Lh8z3wby; Fri, 12 Mar 2021 15:20:42 +0100 (CET)
From: bruno.decraene@orange.com
To: Peter Psenak <ppsenak@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>
CC: Christian Hopps <chopps@chopps.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, John Scudder <jgs@juniper.net>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>
Thread-Topic: AD Review of draft-ietf-lsr-isis-srv6-extensions-11
Thread-Index: AQHXF0nEPNeWJdPPz0KmR2rSJomMYKqAZd5Q
Date: Fri, 12 Mar 2021 14:20:40 +0000
Message-ID: <32253_1615558842_604B78BA_32253_89_12_53C29892C857584299CBF5D05346208A4CD0EB53@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <CAMMESswF4GiLTRAYeLfhkC4w9tsr2J5YaMNFSG=979Bh2tmULw@mail.gmail.com> <836ca254-1273-7339-4c7d-f92d5e17315f@cisco.com> <29270_1615545597_604B44FD_29270_84_4_53C29892C857584299CBF5D05346208A4CD0E4C0@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <b639b32b-0f4c-8550-9397-b5735ebaca5a@cisco.com>
In-Reply-To: <b639b32b-0f4c-8550-9397-b5735ebaca5a@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/DmLTa46J-1A42OeuKmbWFZT_c9w>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 14:20:47 -0000
Hi Peter, > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Friday, March 12, 2021 3:13 PM > > Hi Bruno, > > please see inline: > > On 12/03/2021 11:39, bruno.decraene@orange.com wrote: > > Peter, Alvaro > > > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > >> Sent: Thursday, March 11, 2021 11:47 AM > > > > [...] > > > >>> ... > >>> 221 4.3. Maximum H.Encaps MSD Type > >>> > >>> 223 The Maximum H.Encaps MSD Type specifies the maximum > number > >> of SIDs > >>> 224 that can be included as part of the "H.Encaps" behavior as > defined > >> in > >>> 225 [I-D.ietf-spring-srv6-network-programming]. > >>> > >>> [nit] s/included/pushed That is the terminology used in rfc8986. > >> > >> ##PP > >> fixed. > >> > >>> > >>> > >>> ... > >>> 229 If the advertised value is zero or no value is advertised > >>> 230 then the router can apply H.Encaps only by encapsulating > >>> 231 the incoming packet in another IPv6 header without SRH > >>> 232 the same way IPinIP encapsulation is performed. > >>> > >>> 234 If the advertised value is non-zero then the router > supports both > >>> 235 IPinIP and SRH encapsulation subject to the SID limitation > >>> 236 specified by the advertised value. > >>> > >>> [major] rfc8986 doesn't talk about IPinIP encapsulation, but is does say > this: > >>> > >>> The push of the SRH MAY be omitted when the SRv6 Policy only > contains > >>> one segment and there is no need to use any flag, tag or TLV. > >>> > >>> Suggestion (to replace the last two paragraphs)> > >>> If the advertised value is zero or no value is advertised then the > >>> headend can apply an SR Policy that only contains one segment, by > >>> omitting the SRH push. > >>> > >>> A non-zero SRH Max H.encaps MSD indicates that the headend can > push > >>> an SRH up to the advertised value. > >> > >> ##PP > >> done, but used "insert" instead of "push". > > > > In SRv6, "Insert" has been used with a different meaning (SRH insertion > without IP encapsulation) and hence is very connoted. So I would prefer if > we could avoid the term "insert", to avoid both misunderstanding and > ambiguities. > > > > I'm not sure how many/which :s/push/insert you are referring to as I'm > seen 3 "push". I'll assume you meant the 3 of them. I would suggest the > following change, but any other formulation would probably work for me. > > > > OLD: The push of the SRH MAY be omitted > > NEW: The SRH MAY be omitted > > > > OLD: by omitting the SRH push. > > NEW by omitting the SRH. > > > > OLD: the headend can push an SRH up to the advertised value. > > NEW: the headend can perform IP encapsulation with an SRH containing up > to MSD SIDs. > > (or may be: up to this number of SIDs) > > not sure which document/version do you look at, but I don't see any > occurrence of "push" or "insert" in the latest published version (11). I'm referring to the email (above) that you sent yesterday on the LSR mailing list in which you said " ##PP done, but used "insert" instead of "push"." It's not reflected in the latest published version which date from October 8, 2020 > The single "push" I added as a response to Alvaro's comment was at: > > > The Maximum H.Encaps MSD Type signals the maximum number of SIDs > that can be pushed as part of the "H.Encaps" behavior as defined in > [RFC8986]" > > Please let me know how do you prefer that to be modified. > > > > > > > > [...] > > > > > >> 245 SRH Max End D Type: 45 > >> > >> 247 If the advertised value is zero or no value is advertised > >> 248 then it is assumed that the router cannot apply > >> 249 "End.DX6" or "End.DT6" behaviors if the outer IPv6 header > >> 250 contains an SRH. > > > > Since I've started, I'll continue to nick pick. > > > > "assume" does not seem like the right term when talking about an explicit > signalling. > > I would suggest > > OLD: then it is assumed that the router cannot apply > > NEW: then the router cannot apply > > fixed them all. Thanks, --Bruno > Peter > > > > > > *3 (in §4.1, §4.2, §4.4) > > > > > > Thank you, > > --Bruno > > > > > __________________________________________________________ > __________________________________________________________ > _____ > > > > 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.
- [Lsr] AD Review of draft-ietf-lsr-isis-srv6-exten… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… bruno.decraene
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Acee Lindem (acee)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Les Ginsberg (ginsberg)
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Alvaro Retana
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Peter Psenak
- Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-e… Alvaro Retana