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

From: Christian Hopps <[email-masked]>
Date: Tue, 21 Jan 2020 19:14:53 -0500

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.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 22 Jan 2020 10:14:59 +0100

Hi Chris,

On 22/01/2020 01:14, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for draft-ietf-lsr-isis-srv6-extensions >

I'm not aware of any other IPRs beyond what is posted.

thanks,
Peter
> 
> Thanks,
> Chris & Acee.
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
> 
>

---

From: <[email-masked]>
Date: Wed, 22 Jan 2020 09:31:32 +0000

Chris,

I'm not aware of non-disclosed IPR.

Regards,
--Bruno
-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: [email-masked]
Cc: [email-masked]; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris & Acee.

_________________________________________________________________________________________________________________________

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Jan 2020 13:09:00 +0000

Speaking as WG member, 

I have reviewed revisions of this draft and support publication.

Thanks,
Acee

On 1/21/20, 7:15 PM, "Christian Hopps" <[email-masked]> wrote:

    

    Thanks,
    Chris & Acee.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 23 Jan 2020 17:57:06 +0000

Dear chairs and the WG,

I have reviewed the draft (now and during its progression) and believe it is ready for publication.

Thanks

Regards … Zafar

From: Lsr <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Date: Tuesday, January 21, 2020 at 7:15 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Christian Hopps <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris & Acee.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 23 Jan 2020 22:59:00 +0000

Support progressing this document. 

On 1/21/20, 4:17 PM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,
    Chris & Acee.

---

From: "Paul Wells (pauwells)" <[email-masked]>
Date: Fri, 24 Jan 2020 00:40:26 +0000

Support. Not aware of any undisclosed IPR.

Paul

---

From: Huzhibo <[email-masked]>
Date: Fri, 24 Jan 2020 00:43:43 +0000

Zhibo

--------------------------------------------------
胡志波 Hu Zhibo
Mobile: +86-18618192287<tel:+86-18618192287>
Email: [email-masked]<mailto:[email-masked]>

发件人：Christian Hopps <[email-masked]>
收件人：lsr <[email-masked]>
抄 送：lsr-ads <[email-masked]>;Christian Hopps <[email-masked]>;Acee Lindem (acee) <[email-masked]>
时 间：2020-01-22 08:15:23
主 题：[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris & Acee.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 24 Jan 2020 04:14:56 +0000

Support. As a contributor, I am not aware of any undisclosed IPR related to this draft.

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Paul Wells (pauwells)
Sent: 24 January 2020 06:10
To: [email-masked]; [email-masked]
Cc: [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Paul

---

From: "Clarence Filsfils (cfilsfil)" <[email-masked]>
Date: Fri, 24 Jan 2020 11:45:10 +0000

I am not aware of any undisclosed IPR related to this draft.

Cheers,
Clarence

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Wednesday, January 22, 2020 01:15
> To: [email-masked]
> Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem
> (acee) <[email-masked]>

---

From: stefano previdi <[email-masked]>
Date: Fri, 24 Jan 2020 14:46:31 +0100

As contributor, I do support the draft and I’m not aware of any undisclosed IPR.

Thanks.
s.

> On Jan 22, 2020, at 1:14 AM, Christian Hopps <[email-masked]> wrote:
>

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 24 Jan 2020 14:40:30 +0000

Support.

Best Regards,
Huaimo

>  https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-srv6-extensions%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727&amp;sdata=d%2BFN9%2BxhMfAP06%2FelMEoIYbn3dnKfNcCOKkspuI8DBU%3D&amp;reserved=0
>
>  https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3796%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727&amp;sdata=TiWrbHt636eWDWePu6ZKi6g5r447kqdh71kh7GYSOPA%3D&amp;reserved=0
>
> Thanks,
> Chris & Acee.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727&amp;sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3D&amp;reserved=0

_______________________________________________
Lsr mailing list
[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727&amp;sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3D&amp;reserved=0

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 24 Jan 2020 15:14:04 +0000

support.

From:Christian Hopps <[email-masked]>
To:lsr <[email-masked]>
Cc:lsr-ads <[email-masked]>;Christian Hopps <[email-masked]>;Acee Lindem (acee) <[email-masked]>
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris & Acee.

---

From: <[email-masked]>
Date: Fri, 24 Jan 2020 15:24:49 +0000

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:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: [email-masked]
Cc: [email-masked]; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,

Chris & Acee.

Lsr mailing list

[email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 Jan 2020 16:39:12 +0000

Bruno -

Regarding

<snip>
§8.2
"System-ID: 6 octets of IS-IS System-ID of length "ID Length" as defined in [ISO10589]. »

<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 <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, January 24, 2020 7:25 AM
To: [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Hi authors, WG,

Best regards,

--Bruno

Minors:

======

---

§4.3

---

§4.2

---

§4.4

a) if there is an SRH

?

....

---

----

§7.1

"

     Length: variable.

----

§7.1

----

§8.1 (idem for §8.2)

OK.

----

§8.2

----

§9

----

§9

----

Nits:

======

---

---

Proposed

---

--

OLD: the this draft

NEW: this draft

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,

Chris & Acee.

Lsr mailing list

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 Jan 2020 16:54:24 +0000

I support progressing this draft.

   Les

> Sent: Tuesday, January 21, 2020 4:15 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Fri, 24 Jan 2020 17:18:33 +0000

Les,

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

Bruno -

Regarding

<snip>
§8.2

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] ').

[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

   Les

Hi authors, WG,

Best regards,

--Bruno

Minors:

======

---

§4.3

---

§4.2

---

§4.4

a) if there is an SRH

?

....

---

----

§7.1

"

     Length: variable.

----

§7.1

----

§8.1 (idem for §8.2)

OK.

----

§8.2

----

§9

----

§9

----

Nits:

======

---

---

Proposed

---

--

OLD: the this draft

NEW: this draft

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,

Chris & Acee.

Lsr mailing list

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 Jan 2020 17:38:31 +0000

Bruno -

ISO 10589 defines/advertises a system ID length which can be 1-8 octets.
ISO 10589 also requires that every router in the domain use the same ID length:

7.3.15.1 Action on receipt of a link state PDU
...
4)            If the ID Length field of the PDU is not equal to the value of the IS's routeingDomainIDLength, the PDU shall be discarded and an iDFieldLengthMismatch event generated.

As previously stated, from a practical standpoint, existing implementations only support a length of 6 - which is why RFC 5305 definition "works". But if there was ever a need to support an ID length other than 6, the TLV definition defined in RFC 5305 would still work - it would just have to be reinterpreted to use the ID length defined for the domain.

In most specifications, we try to use ID Length so this issue is more explicitly addressed and I think that is the more preferred method. So I do not agree that we should use "6 explicitly".

If you want to pursue a clarification regarding RFC 5305 in this regard you may - though I hope we could agree this isn't a high priority issue.

   Les

From: [email-masked] <[email-masked]>
Sent: Friday, January 24, 2020 9:19 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Les,

To: DECRAENE Bruno TGI/OLN; [email-masked]<mailto:[email-masked]>

Bruno -

Regarding

<snip>
§8.2

  *   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

--Bruno

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, January 24, 2020 7:25 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Hi authors, WG,

Best regards,

--Bruno

Minors:

======

---

§4.3

---

§4.2

---

§4.4

a) if there is an SRH

?

....

---

----

§7.1

"

     Length: variable.

----

§7.1

----

§8.1 (idem for §8.2)

OK.

----

§8.2

----

§9

----

§9

----

Nits:

======

---

---

Proposed

---

--

OLD: the this draft

NEW: this draft

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, January 22, 2020 1:15 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Christian Hopps; Acee Lindem (acee)
Subject: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,

Chris & Acee.

Lsr mailing list

Thank you.

Thank you.

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 24 Jan 2020 21:55:57 +0000

Support.

Thanks,
Yingzhen

From: Lsr <[email-masked]> on behalf of "Xiejingrong (Jingrong)" <[email-masked]>
Date: Friday, January 24, 2020 at 7:14 AM
To: Christian Hopps <[email-masked]>, lsr <[email-masked]>
Cc: lsr-ads <[email-masked]>, Christian Hopps <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions
Resent-From: <[email-masked]>

support.

  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-srv6-extensions%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947270304&sdata=4WygaZUoZRSYWVjsXhlRVI8LxDEYQnubLQmPrgjRPfA%3D&reserved=0>

  https://datatracker.ietf.org/ipr/3796/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3796%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947280299&sdata=qpxYJquhg7NjpZxMZyYcDizQwoKSnstbjjBPXrXWhb0%3D&reserved=0>

Thanks,
Chris & Acee.
_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce16a34ad6ccd4bfe2e8408d7a0e02761%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637154756947280299&sdata=gsSqx7MWTUWuTmQ0tG3YeJEZg2olB5dR7RcfguwsupE%3D&reserved=0>

---

From: Lizhenbin <[email-masked]>
Date: Sun, 26 Jan 2020 09:30:43 +0000

I support the last call. There have been multiple implementations and deployment. The solution is stable and the draft is well written.

Best Regards,
Zhenbin (Robin)

--------------------------------------------------
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: [email-masked]<mailto:[email-masked]>

Thanks,
Chris & Acee.

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 27 Jan 2020 12:32:45 +0000

Support.

Thanks,
Shunwan

From:Christian Hopps <[email-masked]<mailto:[email-masked]>>
To:lsr <[email-masked]<mailto:[email-masked]>>
Cc:lsr-ads <[email-masked]<mailto:[email-masked]>>;Christian Hopps <[email-masked]<mailto:[email-masked]>>;Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Date:2020-01-22 08:15:24
Subject:[Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris & Acee.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 Jan 2020 13:43:14 +0100

Hi Bruno,

please see inline (##PP):

On 24/01/2020 16:24, [email-masked] wrote:
> 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"
> 
> "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
> 

##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
> 
> 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.

> capable and SRv6 incapable routers.

##PP
fixed as suggested.

> “
> 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.”
> 

##PP
done

> 
> “The Locator is encoded in the minimal number ofoctets for the given 
> number of bits.”
> 

##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
> 
> 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.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
> 

##PP
fixed all of the above.

thanks,
Peter

---

From: <[email-masked]>
Date: Tue, 28 Jan 2020 17:05:41 +0000

Hi Peter,

Thank you.
Looks good.

Just one follow up

> e.g. not all SIDs have arguments.

You are correct.
Let me rephrase:

A priori the sum of all 4 sizes must be lower or equal 128 bits.
Could you specify the error handling when this is not the case?
Especially since there seem to be two possible responses:
a) ignore this Sub-Sub-TLV
b) ignore the whole parent TLV (as specified for another error condition)

Thank you
--Bruno

> From: Peter Psenak [mailto:[email-masked]] 
> Sent: Monday, January 27, 2020 1:43 PM

---

From: Peter Psenak <[email-masked]>
Date: Tue, 28 Jan 2020 19:32:15 +0100

Hi Bruno,

> b) ignore the whole parent TLV (as specified for another error condition)

I would go for (b) and ignore the parent sub-TLV.
Will update accordingly.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 29 Jan 2020 07:39:02 +0000

> I would go for (b) and ignore the parent sub-TLV.

Thank you Peter.

--Bruno

---

From: Chris Bowers <[email-masked]>
Date: Wed, 29 Jan 2020 10:25:09 -0600

I would like to proposed the following text to make section 6 more clear.

Thanks,
Chris

====================

 (existing text)

6.  Advertising Anycast Property

   Both prefixes and SRv6 Locators may be configured as anycast and as

   such the same value can be advertised by multiple routers.  It is

   useful for other routers to know that the advertisement is for an

   anycast identifier.

   A new flag in "Bit Values for Prefix Attribute Flags Sub-TLV"

   registry [RFC7794] is defined to advertise the anycast property:

       Bit #: 4 (Suggested - to be assigned by IANA)

       Name: Anycast Flag (A-flag)

       When the prefix/SRv6 locator is configured as anycast, the A-flag

       SHOULD be set. Otherwise, this flag MUST be clear.

   The A-flag MUST be preserved when leaked between levels.

   The A-flag and the N-flag MUST NOT both be set.

==== start insert new text =======

   Certain use cases require prefixes/locators that uniquely belong to a
node.

   Since prefixes/locators which are not /128 should not have the N bit set,

   this node local uniqueness is decided based on A bit for non-/128
prefixes.

   When a prefix/locator is categorized as anycast, it does not uniquely
belong

   to a node and cannot be used for such use cases.  The rules below
specify

   how to determine whether or not a prefix/locator should be treated as
anycast

   in various situations.

   [RFC7794] contains the following restriction on the interpretation
of the N-flag.

   "If the flag is set and the prefix length is NOT a host prefix

    (/32 for IPV4, /128 for IPv6), then the flag MUST be ignored."

   The current document does NOT modify this restriction on the
interpretation of

   the N-flag imposed by [RFC7794].

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

   if both N-flag and A-flag are set, the receiving router MUST treat the

   prefix advertisement as anycast.

   For a prefix/SRv6 Locator advertisement with a /128 prefix/locator,

   if the N-flag and A-flag are NOT set, the receiving routers

   MUST treat the prefix advertisement as anycast.  This rule ensures the

   correct interpretation of a prefix advertisement originated by

   a router that is not SRv6 capable and originates a legacy

   Prefix Attribute Flags Sub-TLV based on [RFC7794] alone.

   For a prefix/SRv6 Locator advertisement with a prefix/locator that

   is NOT /128, the N-flag must be ignored, so the setting of the

   A-flag determines the anycast treatment of the prefix advertisement.

   The Prefix Attribute Flags Sub-TLV can be carried in the SRv6 Locator TLV

   as well as the Prefix Reachability TLVs.  When a router originates

   both the Prefix Reachability TLV and the SRv6 Locator TLV for a given

   prefix, and the router is originating the Prefix Attribute Flags Sub-TLV

   in one of the TLVs, the router SHOULD advertise identical versions of the

   Prefix Attribute Flags Sub-TLV in both TLVs.

   If a router receives one Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV and another in the SRv6 Locator TLV, the
router should

   use the prefix attribute flags received in the Prefix Reachability TLV.

   If a router receives a Prefix Attribute Flags Sub-TLV in the

   Prefix Reachability TLV but not in the SRv6 Locator TLV, the router should

   use the prefix attribute flags received in the Prefix Reachability TLV.

   If a router receives a Prefix Attribute Flags Sub-TLV in the

   SRv6 Locator TLV but not in the Prefix Reachability TLV,

   the router should use the prefix attribute flags received in the
SRv6 Locator TLV.

==== end insert new text =========

   The same prefix/SRv6 Locator can be advertised by multiple routers.

   If at least one of them sets the A-Flag in its advertisement, the

   prefix/SRv6 Locator SHOULD be considered as anycast.

===================

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Jan 2020 20:52:14 +0000

Chris –

I will let the authors of isis-srv6-extensions reply to the bulk of your suggestion.
But as an author of RFC 7794, I do have some concerns.

Please see inline.

From: Lsr <[email-masked]> On Behalf Of Chris Bowers
Sent: Wednesday, January 29, 2020 8:25 AM
To: [email-masked]
Cc: [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris
====================
 (existing text)

   Certain use cases require prefixes/locators that uniquely belong to a node.
   Since prefixes/locators which are not /128 should not have the N bit set,
   this node local uniqueness is decided based on A bit for non-/128 prefixes.
   When a prefix/locator is categorized as anycast, it does not uniquely belong
   to a node and cannot be used for such use cases.  The rules below specify
   how to determine whether or not a prefix/locator should be treated as anycast
   in various situations.

   [RFC7794] contains the following restriction on the interpretation of the N-flag.

   The current document does NOT modify this restriction on the interpretation of

[Les:] I am not sure why you feel the above two paragraphs are necessary. In general, I find the idea that I have to say “I am not changing that other specification” disturbing.
It suggests that the document should list everything else which it isn’t changing.
Perhaps you feel that there is something in the current text which suggests that the meaning of the N flag when associated with a non-host prefix has been changed by this document? If so, please point out that text.

[Les:] This suggestion confuses me – and seems incorrect.
You imply by this that there are only two possibilities for a host address:
1)It is a node address or
2)It is an anycast address

But it is also possible that the prefix is a unicast address but the originator does not intend for the address to be used as a node address.
Your text disallows that possibility.

I get that prior to the definition of the A-bit there is no way to tell by looking at a prefix advertisement alone whether the address is anycast (hence the desire to define the A-bit).
But it does not then follow that if A-bit and N-bit are both NOT set that this is equivalent to having A-bit set.

   Les

   Prefix Reachability TLV and another in the SRv6 Locator TLV, the router should

   the router should use the prefix attribute flags received in the SRv6 Locator TLV.

===================

On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
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/<https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/>

Thanks,
Chris & Acee.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 30 Jan 2020 11:02:14 +0100

Hi Chris,

please see inline (##PP)

> I would like to proposed the following text to make section 6 more clear.

##PP
above does not seem correct. Above seems to imply that for non-/128 
prefix, A-bit is replacement of N-bit.

A-bit applies to both /128 and non-/128 prefixes equally.

Current draft clearly states what to do when both N a A bits are set.

> 
>     When a prefix/locator iscategorized as anycast, it does not uniquely 
> belong
> 
>      (/32 for IPV4, /128 forIPv6), then the flag MUST be ignored."
> 

##PP
I don't think above text is needed. And I don't think above is 
completely correct, as we define a new case in which the N-bit should be 
ignored (when A-bit is set).

>     prefix advertisement as anycast.

##PP
we have following text in the draft already:

"If both N-flag and A-flag are set in the prefix/SRv6 Locator
    advertisement, the receiving routers MUST ignore the N-flag."

>     MUST treat the prefix advertisement as anycast.  

##PP
I don't think above statement is correct. Why a node cannot advertise a 
/128 prefix which is not an anycast one and does not have a N-bit set?

> This rule ensures the

##PP
A-flag does that regardless of the length of the prefix.

>     Prefix Attribute Flags Sub-TLV in both TLVs.

##PP
Above seems a good suggestion. Will add it.

>     use the prefix attribute flags received in the Prefix Reachability TLV.

##PP
above contradicts what you suggest in the previous paragraph, where you 
suggest we need to advertise with both prefix and locator, and here you 
suggest we ignore what we received in the locator.

Are you talking about the case where the content of the Prefix Attribute 
Flags Sub-TLV is different in prefix vs locator?
>     use the prefix attribute flags received in the Prefix Reachability TLV.

##PP
do we really need this? If the originator does the right thing, then we 
don't have the problem. Cross referencing data between different TLVs 
complicates the implementations.

>     the router should use the prefix attribute flags received in the SRv6 Locator TLV.

##PP
same as above.

thanks,
Peter

>     https://datatracker.ietf..org/doc/draft-ietf-lsr-isis-srv6-extensions/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/>
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Chris Bowers <[email-masked]>
Date: Fri, 31 Jan 2020 14:10:41 -0600

Peter and Les,

It seems to me that for the Node Flag in RFC7794 and the proposed Anycast Flag

in draft-ietf-lsr-isis-srv6-extensions-04, we are ultimately concerned with

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined
in RFC8402,

the Segment Routing Architecture document.

If this is the case, then the following text from RFC8402 is very relevant.

============

3.2.  IGP-Node Segment (Node-SID)

   An IGP Node-SID MUST NOT be associated with a prefix that is owned by

   more than one router within the same routing domain.

3.3.  IGP-Anycast Segment (Anycast-SID)

   ....

   An IGP-Anycast segment MUST NOT reference a particular node.

   ....

============

This text can be interpreted in two different ways.

Interpretation I)

A prefix-SID can have the following three possible states.

Ia) Node-SID

Ib) Anycast-SID

Ic) neither Node-SID nor Anycast-SID

Interpretation II)

A prefix-SID can have the following two possible states.

IIa) Node-SID

IIb) Anycast-SID

If Interpretation I) is correct, then I think that the current encodings in

draft-ietf-lsr-isis-srv6-extensions-04 do not allow us

to unambiguously identify a Node-SID for a non-/128

prefix/locator.  For example, the End-SIDs within a /64 locator with the
A-flag set could

either be Ia) a Node-SID  or Ic) neither Node-SID nor Anycast-SID.

I think a reasonable solution would be to remove the restriction

on the N-flag to allow it to be used for non-/128 prefixes/locators.  This

would allow the three possible prefix-SIDs states to be easily represented.

If Interpretation II) is correct, then I think that the current encodings
in

draft-ietf-lsr-isis-srv6-extensions-04 need clarification with respect to

how to interpret a /128 prefix/locator advertisement with N=0, A=0. We

have to decide between interpreting the End-SIDs within the locator

as either Node-SIDs or Anycast-SIDs, since there is no third option.

I think that interpreting the End-SIDs as Anycast-SIDs in the N=0, A=0

case is preferable because it preserves backwards compatibility.

Thanks,

Chris

On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak <[email-masked]> wrote:

> >     https://datatracker.ietf.
> .org/doc/draft-ietf-lsr-isis-srv6-extensions/
> >     <
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/>
> >

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 31 Jan 2020 21:41:16 +0000

Chris –

One of the early mistakes that was made when defining SR-MPLS was defining the N-flag (and R-flag) in the Prefix-SID sub-TLV.
We quickly realized that these flags had meaning and use cases for the prefix – not simply for the SID.

RFC 7794 was then written and these flags were associated with a prefix (NOT a SID) – both for IPv4 and IPv6.

We also added in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1.1

“The Prefix Attribute Flags sub-TLV [RFC7794<https://www.rfc-editor.org/rfc/rfc8667.html#RFC7794>] also defines the N-Flag and R-Flag and with the same semantics of the equivalent flags defined in this document. Whenever the Prefix Attribute Flags sub-TLV is present for a given prefix, the values of the N-Flag and R-Flag advertised in that sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be ignored.”

to address backwards compatibility with early SR-MPLS IS-IS implementations.
In a perfect world the N/R flags would not exist in the Prefix-SID advertisement.

We do not want to make the same mistake again.

The A-flag is a property of a prefix – and (as per draft-ietf-lsr-isis-srv6-extensions) also a Locator.

It is a mistake to think that these flags are associated with a SID.

Does this help?

   Les

From: Lsr <[email-masked]> On Behalf Of Chris Bowers
Sent: Friday, January 31, 2020 12:11 PM
To: Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; Christian Hopps <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-isis-srv6-extensions

Peter and Les,

how to identify IGP-Node Segments and IGP-Anycast Segments, as defined in RFC8402,

============

   ....

   .....

Interpretation I)

Interpretation II)

prefix/locator.  For example, the End-SIDs within a /64 locator with the A-flag set could

If Interpretation II) is correct, then I think that the current encodings in

Thanks,
Chris

On Thu, Jan 30, 2020 at 4:02 AM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

please see inline (##PP)

##PP

##PP

##PP

>     MUST treat the prefix advertisement as anycast..

##PP

##PP

##PP

##PP

##PP

##PP
same as above.

thanks,
Peter

>     prefix/SRv6 Locator SHOULD be considered as anycast..
>
>
>
> ===================
>
>
> On Tue, Jan 21, 2020 at 6:15 PM Christian Hopps <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>