Hi Bruno,
please see inline (##PP):
On 24/01/2020 16:24, bruno.decra...@orange.com wrote:
Hi authors, WG,
I've re-read the draft. Please find below some minor comments and nits.
Best regards,
--Bruno
Minors:
======
" A node indicates that it has support for SRv6 by advertising a new
SRv6 Capabilities sub-TLV"
I'm not completely certain that "support for SRv6" is perfectly defined.
Do you have a reference? Otherwise may be "is an SRv6 Segment Endpoint
Node" would be better.
Cfhttps://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
##PP
I changed to "SR Segment Endpoint Node"
---
§4.3
"The Maximum H.Encaps MSD Type specifies the maximum number of SIDsthat
can be included as part of the "H.Encaps" behavior"
This is not crystal clear to me when the "reduced encapsulation" is
used. In such case we have:
a) the number of SID included (N)
b) the number of SID included in the SRH (N-1)
Could you clarify which one you are referring to?
I assume that this is "b" given the text:
"If the advertised value is zero then the router can apply H.Encaps only
by encapsulating the incoming packet in anotherIPv6 header without SRH
the same way IPinIP encapsulation is performed."
But to avoid interop issue, I'd prefer the spec to be non ambiguous.
(typically by saying "SIDs in a SRH" as indicated in §4.4
##PP
the Maximum H.Encaps MSD Type specifies the maximum number of segments
that a node can use as part of the encapsulation operation, regardless
of whether that is H.Encaps or H.Encaps.Red. If the node advertises N it
can either do H.Encaps with N SIDs in SRH or do H.Encaps.Red with (N-1)
in the SRH +1 in the IPv6 DA.
---
§4.2
"inthe top SRH in an SRH stack to which the router can apply "PSP"
orUSP" as defined in [I-D.ietf-spring-srv6-network-programming]flavors"
[I-D.ietf-spring-srv6-network-programming] does not define (anymore)
"SRH stack", nor "top SRH". Please remove those two terms.
##PP
Changed to:
"The Maximum End Pop MSD Type specifies the maximum number of SIDs in
the SRH to which the router can apply "PSP" or USP" behavior, as defined
in [I-D.ietf-spring-srv6-network-programming] flavors."
---
§4.4
"If the advertised value is zero or no value is advertised
then it is assumed that the router cannot apply
"End.DX6" or "End.DT6" behaviors if the extension
header right underneath the outer IPv6 header is an SRH."
There is no requirement for the SRH to be "right underneath the outer
IPv6 header".
##PP
Changed to:
"If the advertised value is zero or no value is advertised
then it is assumed that the router cannot apply
"End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an SRH."
Cfhttps://tools.ietf.org/html/rfc8200#section-4.1
Please clarify what is meant precisely. E.g.:
a) if there is an SRH
b) if there is a IPv6 routing header
c) if there isan IPv6 extension header
?
....
Given the wording in §4.2, I would suggest "a". However, the technical
question remains: are those MSD numbers affected by the presence of
another IPv6 extension header (before the SRH)?
##PP
no, the presence of another IPv6 extension header has no impact on the
MSDs we define here.
---
OLD: This is to prevent inconsistent forwarding entries on SRv6
capable/SRv6 incapable routers.
I think the below would be clearer
NEW: This is to prevent inconsistent forwarding entries between SRv6
capable and SRv6 incapable routers.
##PP
fixed as suggested.
----
§7.1
“
Type: 27 (Suggested value to be assigned by IANA)
Length: variable.
MTID: Multitopology Identifier as defined in [RFC5120
<https://tools.ietf.org/html/rfc5120>].
Note that the value 0 is legal.”
Personally I would find clearer to move the above text (describing the
SRv6 Locator TLV) just after the Figure of the SRv6 Locator TLV.
That would also allow the removal of “Locator entry:” since as a result
the text and figures for the local entry would also be grouped together.
##PP
done.
----
§7.1
“Loc-Size: 1 octet. Number of bits in the Locator field.”
I think that this is the number of bits of the SRv6 Locator, rather than
the number of bits of the field.
Proposed NEW: Loc-Size: 1 octet. Number of bits in the SRv6 Locator.
##PP
done
“The Locator is encoded in the minimal number ofoctets for the given
number of bits.”
Do we want to define the trailing bits? E.g. MUST be sent as zero and
ignored when received.
##PP
done
----
§8.1 (idem for §8.2)
I may be missing something…
“All End.X SIDs MUST be a subnet of a Locator with matching topology
and algorithm which is advertised by the same node in an SRv6 Locator
TLV. »
OK.
So what’s the point of advertising a field ‘algorithm’ in the SRv6 End.X
SID sub-TLV? The 128-bits SID allows identifying the Locator, which
already advertise an algorithm.
Advertising again the algorithm with the End.X SID waste space and is an
opportunity for inconsistency hence additional error handling
rules/implementations.
##PP
Having an algo field advertised with the END.X/LAN END.x SIDs:
1. Makes it easier for implementation to find the algo specific END.X
SID without making the longest prefix match on all locators advertised
by the node to find the algo to which the SID belongs.
2. Contrary to what you said, it makes it possible to verify that the
algorithm associated with the END.X SID matches that of the covering
Locator.
----
§8.2
“System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined
in [ISO10589 <https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-04#ref-ISO10589>]. »
The field seems of fixed length (6 octets) while the encoded System ID
seems to be of a variable length. If so, wouldn’t it be useful to
indicate how a System ID of a length shorter than 6 octets is encoded?
(in most or least significant octets?).
##PP
Les has responded to the above.
----
§9
A priori the sum of all 4 sizes must be 128 bits. Could you specify the
error handling when this is not the case? (a choice could be to ignore
this Sub-Sub-TLV; but given the error handling specified for another
error, you seem to prefer to ignore the whole parent TLV.
##PP
the sum may not need to be 128, some fields may be advertised as 0 -
e.g. not all SIDs have arguments.
----
§9
“ISIS SRv6 SID Structure Sub-Sub-TLV MUST NOT appear more than once in
its parent sub-TLV.If it appears more than once in its parent TLV,
the parent TLV MUST be ignored by the receiver.”
In the first sentence, ‘parent” refers to the sub-TLV.
In the second sentence, ‘parent” refers to the TLV.
I assume that the second sentence should also refers to the parent
‘sub-TLV’ but I’d prefer this be clarified in the text.
##PP
fixed.
----
§12.1.1 defines a new IANA registry "sub-sub-TLVs for SRv6 End SID sub-TLV"
§12.5 defines a new IANA registry “Sub-Sub-TLVs for SID Sub-TLVs”
Just checking whether both are needed/intended especially as the second
references section 7.2. (SRv6 End SID sub-TLV)
##PP
this was a duplication, I have removed the part from the section 12.1.1.
Nits:
======
Idnitsreports 1 error & 1 warning that seem valid :
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-lsr-isis-srv6-extensions-04.txt
---
Page header is " draft-bashandy-isis-srv6-extensions". Probably a better
name could be found for the RFC. E.g. IS-IS extensions for SRv6.
##PP
fixed
---
Proposed
OLD:a combination of SID's
NEW: a combination of SIDs
---
OLD: is received in both in a
NEW: is received in both a
--
OLD: the this draft
NEW: this draft
##PP
fixed all of the above.
thanks,
Peter
-----Original Message-----
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
This begins a 2 week WG Last Call, ending after Feb 4, 2020, for
draft-ietf-lsr-isis-srv6-extensions
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
Authors please indicate if you aware of any other IPR beyond what is posted:
https://datatracker.ietf.org/ipr/3796/
Thanks,
Chris & Acee.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_________________________________________________________________________________________________________________________
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr