Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11

Peter Psenak <> Fri, 12 March 2021 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05F503A0C01; Fri, 12 Mar 2021 06:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aKucHo23WTkM; Fri, 12 Mar 2021 06:12:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A36A83A105C; Fri, 12 Mar 2021 06:12:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4775; q=dns/txt; s=iport; t=1615558372; x=1616767972; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sGF8kA6+j0tT0Jf9TOm9QjiNjWB8gY5MJMuVWtdFF3I=; b=btlbsDAew+0p20CKRdG3J3HoeapGWyWouDnJDwUwYMh/CcphwTJ3j0CC cHdW1zrgm+I7ELwa+JeLqrK2ceq/mmitN6lFgeBxgy45sxagCANJMeA3n tVjmmNPghZlvGxy05I2YDWfFCtzEfFRlo8lfsHOTwf/bTerKyrABZSRNW I=;
IronPort-HdrOrdr: A9a23:5GyC6KNp+Fw+McBcT4j155DYdL4zR+YMi2QD/UoZc3BoW+afkN 2jm+le8BfyhioYVn1Io6HmBICrR3TA+ZlppbQLNbC5UwX8/EeuJodu7YztqgeQfRHW3OhbyK tmbuxCGMT9ZGIK6frSzQGkH78boOWv37uvgY7loUtFbQYvUK146hc8NwDzKDwSeCBjJb4UUK WR/dBGoT3IQwV0Uu2eCmMeV+bO4/3n/aiGXTc8CxQq6BaDgFqTgdaQLzGi0hgTSD9Jy7s5mF KrryXC+q6hv/unoyW360bv6f1t9efJ9sFOH4ilhMQTN1zX+2WVTbUkfaGetzYop+zqz1AmnL D30m8dFvU2zW/NdWeophao4S3c6XIF7n/vzkLwuwqbnfDE
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,243,1610409600"; d="scan'208";a="31703886"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 14:12:45 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id 12CEChkY007443; Fri, 12 Mar 2021 14:12:45 GMT
To:, Alvaro Retana <>
Cc: Christian Hopps <>, "" <>, "" <>, John Scudder <>, "" <>
References: <> <> <29270_1615545597_604B44FD_29270_84_4_53C29892C857584299CBF5D05346208A4CD0E4C0@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Peter Psenak <>
Message-ID: <>
Date: Fri, 12 Mar 2021 15:12:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <29270_1615545597_604B44FD_29270_84_4_53C29892C857584299CBF5D05346208A4CD0E4C0@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lsr] AD Review of draft-ietf-lsr-isis-srv6-extensions-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Mar 2021 14:12:54 -0000

Hi Bruno,

please see inline:

On 12/03/2021 11:39, wrote:
> Peter, Alvaro
>> From: Peter Psenak []
>> 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).

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

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.

> *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.