Bruno -
Regarding
<snip>
§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in
[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?).
<end snip>
It is well known that - although ISO 10589 supports a system-id length between
1-8 octets - in practice the length 6 is always used. And of course all nodes
have to agree to use the same length.
The comparable text from RFC 8667 Section 2.2.2 says:
"Neighbor System-ID: IS-IS System-ID of length "ID Length" as
defined in [ISO10589]."
I suggest that the text in this draft be modified to match this - and the ASCII
art text changes "6 octets" to "ID Length octets" - again matching RFC 8667.
I think there is no need to spend time discussing lengths other than 6.
Would you agree?
Les
From: Lsr <lsr-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org; Christian Hopps <cho...@chopps.org>; Acee Lindem (acee)
<a...@cisco.com>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
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.
Cf
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-3
---
§4.3
"The Maximum H.Encaps MSD Type specifies the maximum number of SIDs that 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 another IPv6 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
---
§4.2
"in the top SRH in an SRH stack to which the router can apply "PSP" or USP"
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.
---
§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".
Cf https://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 is an 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)?
---
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.
----
§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.
----
§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.
"The Locator is encoded in the minimal number of octets 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.
----
§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.
----
§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?).
----
§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.
----
§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.
----
§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)
Nits:
======
Idnits reports 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.
---
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
-----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<mailto:lsr@ietf.org>
Cc: lsr-...@ietf.org<mailto: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<mailto: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
