Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

<bruno.decraene@orange.com> Fri, 24 January 2020 17:18 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F39C120A8C; Fri, 24 Jan 2020 09:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.402
X-Spam-Level: **
X-Spam-Status: No, score=2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4OS-bEomnqX; Fri, 24 Jan 2020 09:18:42 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3DA120B43; Fri, 24 Jan 2020 09:18:36 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4845T65Zwdz8sqf; Fri, 24 Jan 2020 18:18:34 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4845T63q26zCqkt; Fri, 24 Jan 2020 18:18:34 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0468.000; Fri, 24 Jan 2020 18:18:34 +0100
From: bruno.decraene@orange.com
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: "lsr-ads@ietf.org" <lsr-ads@ietf.org>, Christian Hopps <chopps@chopps.org>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Thread-Index: AQHV0LlFf9QDmDN0/k2d67nGNpYiI6f582KAgAARzyCAAASfkA==
Date: Fri, 24 Jan 2020 17:18:33 +0000
Message-ID: <8350_1579886314_5E2B26EA_8350_27_1_53C29892C857584299CBF5D05346208A48D6AAB9@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <122B138F-AA4F-4C7C-969C-755DF15F5744@chopps.org> <21857_1579879490_5E2B0C42_21857_341_1_53C29892C857584299CBF5D05346208A48D6A5CF@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MWHPR11MB1616620DC9BB708C770009F0C10E0@MWHPR11MB1616.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1616620DC9BB708C770009F0C10E0@MWHPR11MB1616.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48D6AAB9OPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ktY1lG24TA50gHohsrtSg_v2lQ4>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2020 17:18:45 -0000

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Friday, January 24, 2020 5:39 PM
To: DECRAENE Bruno TGI/OLN; lsr@ietf.org
Cc: lsr-ads@ietf.org; Christian Hopps; Acee Lindem (acee)
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

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.
[Bruno] Just to clarify, I was asking for consistency between the length of the field ('6 octets') and the lengths of its content ('  "ID Length" as defined in [ISO10589] ').

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.

[Bruno] Looks better as this is consistent. I feel that it could be even better as I still see two options:

-          a) If the length of the System ID is fixed to 6, I think that this needs to be indicated in the draft (rather than "as defined in [ISO10589]" which allows for a variable length).

-          b) If the length of the System ID is variable "as defined in [ISO10589]", then I don't see how the receiver can know this length and successfully parse the sub-TLV, except may be by looking at another field in the LSP

Looking at RFC 5305, it seems to define/hard code a length of 6 for the ID, which is aligned with option "a" and what is much probably meant in this draft. https://tools.ietf.org/html/rfc5305#section-3
(That been said RFC 5306 (i.e. next RFC) , which you co-author, seems to allow for a variable length....)


Hence I would rather propose  "System-ID: 6 octets of IS-IS System-ID" as per option "a". But I'm also fine with option "b" if you want.

--Bruno
I think there is no need to spend time discussing lengths other than 6.
Would you agree?


   Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: Friday, January 24, 2020 7:25 AM
To: lsr@ietf.org
Cc: lsr-ads@ietf.org; Christian Hopps <chopps@chopps.org>; Acee Lindem (acee) <acee@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-bounces@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-ads@ietf.org<mailto: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<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.

_________________________________________________________________________________________________________________________

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.