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-bounces@ietf.org] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: lsr@ietf.org
Cc: lsr-ads@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.