Hi Bruno,
please see inline:
On 12/03/2021 11:39, [email protected] wrote:
Peter, Alvaro
From: Peter Psenak [mailto:[email protected]]
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
