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

[Peter Psenak <[e-mail]>]

Hi Bruno,

please see inline:

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

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