Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

From: Chris Bowers <[email-masked]>
Date: Mon, 2 Mar 2020 12:09:29 -0600

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain
from a single block is optional.

However, assuming for the moment that a network operator has chosen to
allocate all SRv6 locators used in a domain from a single block, so that
there is a well-defined value of B and N across a domain, what is the use
of having a router advertise its own understanding of these two values?
And what is a receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM <[email-masked]> wrote:

> Hi Ketan,
>
>
>
> Thanks fort the follow up.
>
> Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:[email-masked]]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* [email-masked]; SPRING WG List;
> draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak)
> *Subject:* RE: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Hi Bruno,
>
>
>
> I believe the description and usage of Locator is very well described and
> covered in the net-pgm draft as also the corresponding IGP extensions. Is
> the question is more about the “block” part of it (what is not in the block
> part is in the node part as per the text in the net-pgm draft)?
>
>
>
> The “block” is again not a new thing. Please check the following:
>
> Under
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
> … look for “block”
>
> https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6
>
>
>
> [Bruno]
>
> To clarify, my question was not specific to “block” but related to the
> usage, by the receiver, of the following piece of information:
>
>
>
>       LB Length: SRv6 SID Locator Block length
>
>       LN Length: SRv6 SID Locator Node length
>
>       Fun. Length: SRv6 SID Function length
>
>       Arg. Length: SRv6 SID Arguments length
>
>
>
>
>
> So perhaps I don’t get Chris’s point and would wait for him to clarify.
>
> [Bruno] I’ll leave this to Chris.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *
> [email-masked]
> *Sent:* 28 February 2020 14:34
> *To:* Ketan Talaulikar (ketant) <ketant=[email-masked]>;
> Chris Bowers <[email-masked]>
> *Cc:* [email-masked]; SPRING WG List <[email-masked]>;
> draft-ietf-spring-srv6-network-programming <
> [email-masked]>; Peter Psenak
> (ppsenak) <[email-masked]>
> *Subject:* Re: [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> Hi Ketan,
>
>
>
>
>
>
>
> *From:* Lsr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* Friday, February 28, 2020 6:30 AM
>
>
>
> Hi Chris,
>
>
>
> I agree with Peter and I would suggest to drop LSR since this is not a
> protocol specific thing.
>
>
>
> I believe the text in draft-ietf-spring-srv6-network-programming clears
> says what locator block and locator node are. What more details do you
> think are required?
>
>
>
> [Bruno] Speaking as an individual, the draft could possibly clarify the
> usage of these information/fields by the receiver. Possibly using the same
> name/term (e.g. SRv6 SID Locator Block length) to ease the references
> between both drafts.
>
>
>
> Thanks,
>
> --Bruno
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Chris Bowers
> *Sent:* 27 February 2020 22:46
> *To:* [email-masked]; SPRING WG List <[email-masked]>
> *Cc:* Peter Psenak (ppsenak) <[email-masked]>
> *Subject:* [Lsr] clarification of locator block and locator node in
> draft-ietf-spring-srv6-network-programming and
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
> SPRING and LSR WGs,
>
>
>
> I think that we need a much more detailed description of the locator block
> and locator node in either draft-ietf-spring-srv6-network-programming or
> draft-ietf-lsr-isis-srv6-extensions.  See original email below.
>
>
>
> Thanks,
>
> Chris
>
>
>
> On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak <[email-masked]> wrote:
>
> Hi Chris,
>
> On 27/02/2020 17:54, Chris Bowers wrote:
> > LSR WG,
> >
> > Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the  SRv6
> > SID Structure Sub-Sub-TLV. In particular, it defines encoding for the
> > locator block length and the locator node length.  The text refers to
> > [I-D.ietf-spring-srv6-network-programming] for the definition of these
> > concepts.
> >
> > As far as I can tell, the only reference to locator block and locator
> > node in draft-ietf-spring-srv6-network-programming-10 is section 3.1
> > which has the following text:
> >
> >     A locator may be represented as B:N where B is the SRv6 SID block
> >     (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
> >     identifier of the parent node instantiating the SID..
> >
> > I think that we need a much more detailed description of the locator
> > block and locator node.
>
> sure, but that would be in the
> draft-ietf-spring-srv6-network-programming-10, not in
> draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol
> specific constructs.
>
> thanks,
> Peter
>
> >
> > Thanks,
> >
> > Chris
> >
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 4 Mar 2020 06:36:04 +0000

Hi Chris,

You are right in that there is no assumption that all SRv6 locators in a domain are allocated from the same block. Therefore knowing the blocks used in the domain is useful.

The IGP drafts covers the advertisement of the B and N parts of the locally configured locator on the node via IGPs. On the receiver side, the IGP may not really do much with this information, however it enables propagation of this information from all nodes in the network to be advertised out via BGP-LS (or other mechanisms) as part of the topology feed. Once this is part of the topology feed, it enables use-cases on controllers to perform network wide validation of the SRv6 SID block provisioning and can also help in automation of the security aspects described in https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5

Thanks,
Ketan

From: Chris Bowers <[email-masked]>
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <ketant=[email-masked]>; [email-masked]; SPRING WG List <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Ketan,

Based on current documents, allocating all SRv6 locators used in a domain from a single block is optional.

However, assuming for the moment that a network operator has chosen to allocate all SRv6 locators used in a domain from a single block, so that there is a well-defined value of B and N across a domain, what is the use of having a router advertise its own understanding of these two values?  And what is a receiver supposed to do with this information?

Thanks,
Chris

On Fri, Feb 28, 2020 at 8:23 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

From: Ketan Talaulikar (ketant) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 28, 2020 11:11 AM
To: DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
Cc: [email-masked]<mailto:[email-masked]>; SPRING WG List; draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak)
Subject: RE: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Hi Bruno,

I believe the description and usage of Locator is very well described and covered in the net-pgm draft as also the corresponding IGP extensions. Is the question is more about the “block” part of it (what is not in the block part is in the node part as per the text in the net-pgm draft)?

The “block” is again not a new thing. Please check the following:
Under https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 … look for “block”
https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6

[Bruno]
To clarify, my question was not specific to “block” but related to the usage, by the receiver, of the following piece of information:

Thanks,
Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>; Chris Bowers <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Hi Ketan,

From: Lsr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, February 28, 2020 6:30 AM

Hi Chris,

I agree with Peter and I would suggest to drop LSR since this is not a protocol specific thing.

I believe the text in draft-ietf-spring-srv6-network-programming clears says what locator block and locator node are. What more details do you think are required?

[Bruno] Speaking as an individual, the draft could possibly clarify the usage of these information/fields by the receiver. Possibly using the same name/term (e.g. SRv6 SID Locator Block length) to ease the references between both drafts.

Thanks,
--Bruno

Thanks,
Ketan

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Chris Bowers
Sent: 27 February 2020 22:46
To: [email-masked]<mailto:[email-masked]>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
Cc: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs,

I think that we need a much more detailed description of the locator block and locator node in either draft-ietf-spring-srv6-network-programming or draft-ietf-lsr-isis-srv6-extensions.  See original email below.

Thanks,
Chris

On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

thanks,
Peter

Thank you.

Thank you.

---

From: Chris Bowers <[email-masked]>
Date: Thu, 5 Mar 2020 10:23:29 -0600

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Chris,
>
>
>
> You are right in that there is no assumption that all SRv6 locators in a
> domain are allocated from the same block. Therefore knowing the blocks used
> in the domain is useful.
>

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying
that in the scenario where all SRv6 locators in a domain are not allocated
from the same block, you would expect different routers in the same domain
to advertise different values of B and N?  For example, assume we have a
network where all SRv6 locators in a domain are not allocated from the same
block.  Router A advertises an SRv6 Locator TLV with locator = 2000::/64,
and an SRv6 End SID sub-TLV with some endpoint behavior.  Router B
advertises an SRv6 Locator TLV with locator = 3000::/64, and an SRv6 End
SID sub-TLV with some endpoint behavior. What should routers A and B
advertise as the values of B and N in their SRv6 SID Structure Sub-Sub-TLVs
?

>
>
> The IGP drafts covers the advertisement of the B and N parts of the
> locally configured locator on the node via IGPs. On the receiver side, the
> IGP may not really do much with this information, however it enables
> propagation of this information from all nodes in the network to be
> advertised out via BGP-LS (or other mechanisms) as part of the topology
> feed. Once this is part of the topology feed, it enables use-cases on
> controllers to perform network wide validation of the SRv6 SID block
> provisioning and can also help in automation of the security aspects
> described in
[CB] If an ISIS speaker is not expected to do anything with B and N, then I
think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify
this.  I have a similar observation about Fun. Length and Arg. Length in
the SRv6 SID Structure Sub-Sub-TLV .  As far as I can tell, none of the
endpoint behaviors that are currently specified to be carried in ISIS End,
End.X, and LAN End.X SIDs sub-TLVs uses an Argument, so there is never a
case where an SRv6 SID Structure Sub-Sub-TLV should have a non-zero value
for Arg. Length. What should an ISIS speaker do if it receives a non-zero
value of the Arg. Length for an endpoint behavior that doesn't use an
argument?  Are there any use cases envisioned where an ISIS speaker needs
to know the Arg. Length ?

Thanks,
>
> Ketan
>
>
>
> *From:* Chris Bowers <[email-masked]>
> *Sent:* 02 March 2020 23:39
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* Ketan Talaulikar (ketant) <ketant=[email-masked]>;
> [email-masked]; SPRING WG List <[email-masked]>;
> (ppsenak) <[email-masked]>; Bruno Decraene <[email-masked]>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 11:01:56 +0000

Hi Chris,

Dropping the draft-ietf-spring-srv6-network-programming authors since we are now back to discussing the ISIS extensions.

Please check inline below.

From: Chris Bowers <[email-masked]>
Sent: 05 March 2020 21:53
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; SPRING WG List <[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Ketan,

See inline [CB].

On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

[CB] Since you refer to "blocks" (plural) in this sentence, are you saying that in the scenario where all SRv6 locators in a domain are not allocated from the same block, you would expect different routers in the same domain to advertise different values of B and N?
[KT] While personally I believe it would not be the usual case, it is left to the operator.

For example, assume we have a network where all SRv6 locators in a domain are not allocated from the same block.  Router A advertises an SRv6 Locator TLV with locator = 2000::/64, and an SRv6 End SID sub-TLV with some endpoint behavior.  Router B advertises an SRv6 Locator TLV with locator = 3000::/64, and an SRv6 End SID sub-TLV with some endpoint behavior. What should routers A and B advertise as the values of B and N in their SRv6 SID Structure Sub-Sub-TLVs ?
[KT] It is difficult for me to figure out what the block and node parts are with such an addressing.

[CB] If an ISIS speaker is not expected to do anything with B and N, then I think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify this.  I have a similar observation about Fun. Length and Arg. Length in the SRv6 SID Structure Sub-Sub-TLV .  As far as I can tell, none of the endpoint behaviors that are currently specified to be carried in ISIS End, End.X, and LAN End.X SIDs sub-TLVs uses an Argument, so there is never a case where an SRv6 SID Structure Sub-Sub-TLV should have a non-zero value for Arg. Length. What should an ISIS speaker do if it receives a non-zero value of the Arg. Length for an endpoint behavior that doesn't use an argument?  Are there any use cases envisioned where an ISIS speaker needs to know the Arg. Length ?
[KT] The behaviors currently listed in the draft do not have an argument nor is the use of B and N required for them. We cannot preclude a future use-case or extension where such behaviors introduced are also applicable to ISIS. So IMHO ruling such aspects out might not be the right thing to do from a protocol extensibility perspective.

Thanks,
Ketan

Thanks,
Ketan

From: Chris Bowers <[email-masked]<mailto:[email-masked]>>
Sent: 02 March 2020 23:39
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Ketan,

Thanks,
Chris

Hi Bruno,

[Bruno]

Thanks,
Ketan

To: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>>; Chris Bowers <[email-masked]<mailto:[email-masked]>>

Hi Ketan,

Hi Chris,

Thanks,
--Bruno

Thanks,
Ketan

SPRING and LSR WGs,

Thanks,
Chris

On 27/02/2020 17:54, Chris Bowers wrote:
>     identifier of the parent node instantiating the SID...
>

thanks,
Peter

Thank you.

Thank you.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 12 Mar 2020 07:33:56 -0400

> [KT] The behaviors currently listed in the draft do not have an argument nor is the use of B and N required for them. We cannot preclude a future use-case or extension where such behaviors introduc…

No opinion here on this sub-sub-TLV; however, it has been stated elsewhere that this document will be re-spun for each new behavior that is to be carried in IS-IS (not my personal preference, fwiw...).

Thanks,
Chris.
[as WG member]

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 11:42:53 +0000

Hi Chris,

I've been following that thread 😊

IMHO it would depend on the nature of extension and seems not something that I would speculate about.

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: 12 March 2020 17:04
To: [email-masked]
Cc: Chris Bowers <[email-masked]>; [email-masked]; Peter Psenak (ppsenak) <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [Lsr] [spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Thanks,
Chris.
[as WG member]

---

From: Chris Bowers <[email-masked]>
Date: Thu, 12 Mar 2020 09:58:38 -0500

Peter,

I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from
draft-ietf-lsr-isis-srv6-extensions.  I think that we should leave the
ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID
Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those sub-TLVs.

I don't think that the current text describing the SRv6 SID Structure
Sub-Sub-TLV would result in interoperable implementations.  Based on the
discussion with Ketan below, it appears that use cases for ISIS speakers
receiving advertised values of LB Length, LN Length, Fun. Length, and Arg.
Length are not currently well-defined.    So I think it makes sense to
defer the definition of the SRv6 SID Structure Sub-Sub-TLV to a future
document.

Thanks,
Chris

On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Chris,
>
>
>
> Dropping the draft-ietf-spring-srv6-network-programming authors since we
> are now back to discussing the ISIS extensions.
>
>
>
> *Sent:* 05 March 2020 21:53
> *Cc:* Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; SPRING
> WG List <[email-masked]>; draft-ietf-spring-srv6-network-programming <
> On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant) <
> [email-masked]> wrote:
>
> Hi Chris,
>
>
>
> to advertise different values of B and N?
>
> *[KT] While personally I believe it would not be the usual case, it is
> left to the operator.*
>
>
>
> For example, assume we have a network where all SRv6 locators in a domain
> are not allocated from the same block.  Router A advertises an SRv6 Locator
> TLV with locator = 2000::/64, and an SRv6 End SID sub-TLV with some
> endpoint behavior.  Router B advertises an SRv6 Locator TLV with locator =
> 3000::/64, and an SRv6 End SID sub-TLV with some endpoint behavior. What
> should routers A and B advertise as the values of B and N in their SRv6 SID
> Structure Sub-Sub-TLVs ?
>
> *[KT] It is difficult for me to figure out what the block and node parts
> are with such an addressing.*
>
>
>
>
>
> [CB] If an ISIS speaker is not expected to do anything with B and N, then
> I think the text in draft-ietf-lsr-isis-srv6-extensions needs to clarify
> *[KT] The behaviors currently listed in the draft do not have an argument
> nor is the use of B and N required for them. We cannot preclude a future
> use-case or extension where such behaviors introduced are also applicable
> to ISIS. So IMHO ruling such aspects out might not be the right thing to do
> from a protocol extensibility perspective.*
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *Cc:* Ketan Talaulikar (ketant) <ketant=[email-masked]
> <[email-masked]>>; [email-masked]; SPRING WG List <
> [email-masked]>; draft-ietf-spring-srv6-network-programming <
> *To:* Ketan Talaulikar (ketant) <ketant=[email-masked]
> <[email-masked]>>; Chris Bowers <[email-masked]>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 12 Mar 2020 15:24:56 +0000

Hi Chris,

I am repeating the use-case described previously:
The IGP drafts covers the advertisement of the B and N parts of the locally configured locator on the node via IGPs. On the receiver side, the IGP may not really do much with this information, however it enables propagation of this information from all nodes in the network to be advertised out via BGP-LS (or other mechanisms) as part of the topology feed. Once this is part of the topology feed, it enables use-cases on controllers to perform network wide validation of the SRv6 SID block provisioning and can also help in automation of the security aspects described in https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5
We do carry information in the IGPs for propagation as part of the topology information for enabling use-cases outside the router (e.g. via BGP-LS). We do not need to preclude a use-case for it in IGPs themselves in the future.

Thanks,
Ketan

From: Chris Bowers <[email-masked]>
Sent: 12 March 2020 20:29
To: Peter Psenak (ppsenak) <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>
Cc: [email-masked]; SPRING WG List <[email-masked]>; Bruno Decraene <[email-masked]>
Subject: Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Peter,

I think that the SRv6 SID Structure Sub-Sub-TLV should be removed from draft-ietf-lsr-isis-srv6-extensions.  I think that we should leave the ability to include sub-sub-TLVs in the SRv6 End SID Sub-TLV, End.X SID Sub-TLV, and LAN End.X SID Sub-TLV in the encodings for those sub-TLVs.

I don't think that the current text describing the SRv6 SID Structure Sub-Sub-TLV would result in interoperable implementations.  Based on the discussion with Ketan below, it appears that use cases for ISIS speakers receiving advertised values of LB Length, LN Length, Fun. Length, and Arg. Length are not currently well-defined.    So I think it makes sense to defer the definition of the SRv6 SID Structure Sub-Sub-TLV to a future document.

Thanks,
Chris

On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

Cc: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Bruno Decraene <[email-masked]<mailto:[email-masked]>>

Ketan,

See inline [CB].

Thanks,
Ketan

Thanks,
Ketan

Ketan,

Thanks,
Chris

Hi Bruno,

[Bruno]

Thanks,
Ketan

Hi Ketan,

Hi Chris,

Thanks,
--Bruno

Thanks,
Ketan

SPRING and LSR WGs,

Thanks,
Chris

thanks,
Peter

Thank you.

Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Mar 2020 11:02:13 +0100

Hi Chris,

> Sub-Sub-TLV would result in interoperable implementations.  Based on the

SRv6 base spec defines SID B, L, A, F.

SRv6 protocol specs are advertising these values with the SRv6 SID, they 
don't use them. The usage is outside of the scope of the protocol 
drafts. What exactly is the problem?

thanks,
Peter

> receiving advertised values of LB Length, LN Length, Fun. Length, and 
> Arg. Length are not currently well-defined.    So I think it makes sense 
> to defer the definition of the SRv6 SID Structure Sub-Sub-TLV to a 
> future document.
> 
> Thanks,
> Chris
> 
> On Thu, Mar 12, 2020 at 6:02 AM Ketan Talaulikar (ketant) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Chris,____
> 
>     __ __
> 
>     Dropping the draft-ietf-spring-srv6-network-programming authors
>     since we are now back to discussing the ISIS extensions.____
> 
>     __ __
> 
>     Please check inline below.____
> 
>     __ __
> 
>     *From:*Chris Bowers <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Ketan Talaulikar (ketant) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Ketan Talaulikar (ketant) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>;
>     SPRING WG List <[email-masked] <mailto:[email-masked]>>;
>     draft-ietf-spring-srv6-network-programming
>     <[email-masked]
>     <mailto:[email-masked]>>; Peter
>     Psenak (ppsenak) <[email-masked] <mailto:[email-masked]>>;
>     Bruno Decraene <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [Lsr] clarification of locator block and locator node
>     in draft-ietf-spring-srv6-network-programming and
>     draft-ietf-lsr-isis-srv6-extensions____
> 
>     __ __
> 
>     Ketan,____
> 
>     __ __
> 
>     See inline [CB].____
> 
>     __ __
> 
>     On Wed, Mar 4, 2020 at 12:36 AM Ketan Talaulikar (ketant)
>     <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         Hi Chris,____
> 
>         ____
> 
>         You are right in that there is no assumption that all SRv6
>         locators in a domain are allocated from the same block.
>         Therefore knowing the blocks used in the domain is useful.____
> 
>     ____
> 
>     [CB] Since you refer to "blocks" (plural) in this sentence, are you
>     saying that in the scenario where all SRv6 locators in a domain are
>     not allocated from the same block, you would expect different
>     routers in the same domain to advertise different values of B and N?
>     ____
> 
>     */[KT] While personally I believe it would not be the usual case, it
>     is left to the operator.____/*
> 
>     */__ __/*
> 
>     For example, assume we have a network where all SRv6 locators in a
>     domain are not allocated from the same block.  Router A advertises
>     an SRv6 Locator TLV with locator = 2000::/64, and an SRv6 End SID
>     sub-TLV with some endpoint behavior. Router B advertises an SRv6
>     Locator TLV with locator = 3000::/64, and an SRv6 End SID sub-TLV
>     with some endpoint behavior. What should routers A and B advertise
>     as the values of B and N in their SRv6 SID Structure Sub-Sub-TLVs ?____
> 
>     */[KT] It is difficult for me to figure out what the block and node
>     parts are with such an addressing./*____
> 
>     ____
> 
>         ____
> 
>         The IGP drafts covers the advertisement of the B and N parts of
>         the locally configured locator on the node via IGPs. On the
>         receiver side, the IGP may not really do much with this
>         information, however it enables propagation of this information
>         from all nodes in the network to be advertised out via BGP-LS
>         (or other mechanisms) as part of the topology feed. Once this is
>         part of the topology feed, it enables use-cases on controllers
>         to perform network wide validation of the SRv6 SID block
>         provisioning and can also help in automation of the security
>         aspects described in
>         https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5____
> 
>         ____
> 
>     [CB] If an ISIS speaker is not expected to do anything with B and N,
>     then I think the text in draft-ietf-lsr-isis-srv6-extensions needs
>     to clarify this.  I have a similar observation about Fun. Length and
>     Arg. Length in the SRv6 SID Structure Sub-Sub-TLV .  As far as I can
>     tell, none of the endpoint behaviors that are currently specified to
>     be carried in ISIS End, End.X, and LAN End.X SIDs sub-TLVs uses an
>     Argument, so there is never a case where an SRv6 SID Structure
>     Sub-Sub-TLV should have a non-zero value for Arg. Length. What
>     should an ISIS speaker do if it receives a non-zero value of the
>     Arg. Length for an endpoint behavior that doesn't use an argument? 
>     Are there any use cases envisioned where an ISIS speaker needs to
>     know the Arg. Length ? ____
> 
>     */[KT] The behaviors currently listed in the draft do not have an
>     argument nor is the use of B and N required for them. We cannot
>     preclude a future use-case or extension where such behaviors
>     introduced are also applicable to ISIS. So IMHO ruling such aspects
>     out might not be the right thing to do from a protocol extensibility
>     perspective.____/*
> 
>     */__ __/*
> 
>     */Thanks,____/*
> 
>     */Ketan/*____
> 
>     __ __
> 
>         Thanks,____
> 
>         Ketan____
> 
>         ____
> 
>         *From:*Chris Bowers <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Ketan Talaulikar (ketant) <[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>; SPRING WG List <[email-masked]
>         <mailto:[email-masked]>>;
>         draft-ietf-spring-srv6-network-programming
>         <[email-masked]
>         <mailto:[email-masked]>>;
>         Peter Psenak (ppsenak) <[email-masked]
>         <mailto:[email-masked]>>; Bruno Decraene
>         <[email-masked] <mailto:[email-masked]>>
>         *Subject:* Re: [Lsr] clarification of locator block and locator
>         node in draft-ietf-spring-srv6-network-programming and
>         draft-ietf-lsr-isis-srv6-extensions____
> 
>         ____
> 
>         Ketan,____
> 
>         ____
> 
>         Based on current documents, allocating all SRv6 locators used in
>         a domain from a single block is optional.____
> 
>         ____
> 
>         However, assuming for the moment that a network operator has
>         chosen to allocate all SRv6 locators used in a domain from a
>         single block, so that there is a well-defined value of B and N
>         across a domain, what is the use of having a router advertise
>         its own understanding of these two values?  And what is a
>         receiver supposed to do with this information?____
> 
>         ____
> 
>         Thanks,____
> 
>         Chris____
> 
>         ____
> 
>         On Fri, Feb 28, 2020 at 8:23 AM <[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
>             Hi Ketan,____
> 
>             ____
> 
>             Thanks fort the follow up.____
> 
>             Clarification inline [Bruno]____
> 
>             ____
> 
>             *From**:*Ketan Talaulikar (ketant) [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Cc:* [email-masked] <mailto:[email-masked]>; SPRING WG List;
>             *Subject:* RE: [Lsr] clarification of locator block and
>             locator node in draft-ietf-spring-srv6-network-programming
>             and draft-ietf-lsr-isis-srv6-extensions____
> 
>             ____
> 
>             Hi Bruno,____
> 
>             ____
> 
>             I believe the description and usage of Locator is very well
>             described and covered in the net-pgm draft as also the
>             corresponding IGP extensions. Is the question is more about
>             the “block” part of it (what is not in the block part is in
>             the node part as per the text in the net-pgm draft)?____
> 
>             ____
> 
>             The “block” is again not a new thing. Please check the
>             following:____
> 
>             Under
>             … look for “block”____
>             https://tools.ietf.org/html/rfc8402#section-2 … look under
>             SRGB for SRv6____
> 
>             ____
> 
>             [Bruno]____
> 
>             To clarify, my question was not specific to “block” but
>             related to the usage, by the receiver, of the following
>             piece of information:____
> 
>             ____
> 
>                    LB Length: SRv6 SID Locator Block length____
> 
>                    LN Length: SRv6 SID Locator Node length____
> 
>                    Fun. Length: SRv6 SID Function length____
> 
>                    Arg. Length: SRv6 SID Arguments length____
> 
>             ____
> 
>             ____
> 
>             So perhaps I don’t get Chris’s point and would wait for him
>             to clarify.____
> 
>             [Bruno] I’ll leave this to Chris.____
> 
>             ____
> 
>             Thanks,____
> 
>             Ketan____
> 
>             ____
> 
>             *From:*Lsr <[email-masked]
>             <mailto:[email-masked]>> *On Behalf Of
>             [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked]>>; Chris Bowers
>             <[email-masked] <mailto:[email-masked]>>
>             *Cc:* [email-masked] <mailto:[email-masked]>; SPRING WG List
>             <[email-masked] <mailto:[email-masked]>>;
>             draft-ietf-spring-srv6-network-programming
>             <[email-masked]
>             <mailto:[email-masked]>>;
>             Peter Psenak (ppsenak) <[email-masked]
>             <mailto:[email-masked]>>
>             *Subject:* Re: [Lsr] clarification of locator block and
>             locator node in draft-ietf-spring-srv6-network-programming
>             and draft-ietf-lsr-isis-srv6-extensions____
> 
>             ____
> 
>             Hi Ketan,____
> 
>             ____
> 
>             ____
> 
>             ____
> 
>             *From:*Lsr [mailto:[email-masked]] *On Behalf Of
>             *Ketan Talaulikar (ketant)
>             *Sent:* Friday, February 28, 2020 6:30 AM____
> 
>             ____
> 
>             Hi Chris,____
> 
>             ____
> 
>             I agree with Peter and I would suggest to drop LSR since
>             this is not a protocol specific thing.____
> 
>             ____
> 
>             I believe the text in
>             draft-ietf-spring-srv6-network-programming clears says what
>             locator block and locator node are. What more details do you
>             think are required?____
> 
>             ____
> 
>             [Bruno] Speaking as an individual, the draft could possibly
>             clarify the usage of these information/fields by the
>             receiver. Possibly using the same name/term (e.g. SRv6 SID
>             Locator Block length) to ease the references between both
>             drafts.____
> 
>             ____
> 
>             Thanks,____
> 
>             --Bruno____
> 
>             ____
> 
>             Thanks,____
> 
>             Ketan____
> 
>             ____
> 
>             *From:*Lsr <[email-masked]
>             <mailto:[email-masked]>> *On Behalf Of *Chris Bowers
>             *To:* [email-masked] <mailto:[email-masked]>; SPRING WG List
>             <[email-masked] <mailto:[email-masked]>>
>             *Cc:* Peter Psenak (ppsenak) <[email-masked]
>             <mailto:[email-masked]>>
>             *Subject:* [Lsr] clarification of locator block and locator
>             node in draft-ietf-spring-srv6-network-programming and
>             draft-ietf-lsr-isis-srv6-extensions____
> 
>             ____
> 
>             SPRING and LSR WGs,____
> 
>             ____
> 
>             I think that we need a much more detailed description of the
>             locator block and locator node in either
>             draft-ietf-spring-srv6-network-programming or
>             draft-ietf-lsr-isis-srv6-extensions.  See original email
>             below.____
> 
>             ____
> 
>             Thanks,____
> 
>             Chris____
> 
>             ____
> 
>             On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak
>             <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>                 Hi Chris,
> 
>                  > ____
>             _____________________________________________________________________________________________________________________________
> 
>             ____
> 
>             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.____
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 13 Mar 2020 11:05:05 +0100

> No opinion here on this sub-sub-TLV; however, it has been stated elsewhere that this document will be re-spun for each new behavior that is to be carried in IS-IS (not my personal preference, fwiw.…

"it has been stated elsewhere that this document will be re-spun for 
each new behavior"

I don't believe above was the outcome. Instead, a new document will be 
needed for any new behavior.

thanks,
Peter

---

From: Chris Bowers <[email-masked]>
Date: Mon, 23 Mar 2020 11:39:44 -0500

Peter,

The proposed SRv6 SID Structure Sub-Sub-TLV has several problems.

1) As discussed in item#3 below, it is not clear that flooding LB Length,
LN Length, Fun. Length, and Arg. Length to all ISIS speakers is really the
right approach.  However, if the WG determines that it is the right
approach, the current encodings of this information in the proposed SRv6
SID Structure Sub-Sub-TLV are problematic.  As discussed earlier in this
thread, a network operator may choose to not allocate all locators from a
single block, so LB Length and LN Length may not be well-defined.  The
current encoding of the SRv6 SID Structure Sub-Sub-TLV makes it difficult
to represent this situation.  The simple thing to do for nodes that don't
have a well-defined value of LB Length and LN Length would be to not
advertise a value for LB Length and LN Length.  However, since the
currently proposed SRv6 SID Structure Sub-Sub-TLV combines LB Length, LN
Length, Fun. Length, and Arg. Length into a single sub-sub-TLV, if a node
wants to advertise values for Fun. Length and Arg. Length, it also has to
advertise values for LB Length and LN Length.  It seems like a better
approach would be to have different sub-sub-TLVs, one for  LB Length and LN
Length, and a separate one for Fun. Length and Arg. Length to be able to
better represent this situation.

2) Now consider the situation where a network operator chooses to allocate
all locators from a single block, so that LB Length and LN Length are
well-defined across the network.  A given node should presumably advertise
its own understanding of LB Length and LN Length.   A given node's
understanding of LB Length and LN Length is a property of the node.  It is
not a property of a given End SID.  The currently proposed SRv6 SID
Structure Sub-Sub-TLV however is carried within each End SID Sub-TLV.  With
the currently proposed encoding, presumably an implementation is expected
to send the exact same values of LB Length and LN Length for all of the End
SIDs that it advertises.  Not only is this inefficient, but it creates the
need for logic to decide what to do when different End SIDs advertised by
the same node carry different values of LB Length and LN Length in their
sub-sub-TLVs.  It seems like a better approach would be for a given node to
advertise its understanding of the value of LB Length and LN Length in a
sub-TLV of the Router Capability TLV.

3) At this point, the only use case that has been proposed for flooding the
LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS speakers is
to make it more convenient for BGP-LS to get those values to an external
controller as part of a topology feed from any ISIS node.  No use case has
been proposed for ISIS speakers themselves to make use of the information.
It seems like a more scalable approach would be to use BGP-LS sessions to
collect the information from the subset of nodes that actually produce the
relevant information.  So far there are no End SIDs defined that are
advertised in ISIS that have a non-zero Arg. Length.  If an End SID with
non-zero Arg. Length were to be proposed in the future as needing to be
flooded to all ISIS nodes, it seems likely that the new End SID would also
be advertised using the BGP IP/VPN/EVPN control plane.   So it seems like a
viable alternative for this hypothetical future End SID would be to have
the subset of nodes that have non-zero Arg. Length values communicate to an
external controller via  BGP sessions. I think the WG needs a more detailed
discussion of a concrete use case in order to determine whether flooding LB
Length, LN Length, Fun. Length, and Arg. Length to all ISIS speakers is
really the right approach.

Given the lack of a compelling use case for flooding LB Length, LN Length,
Fun. Length, and Arg. Length to all ISIS speakers and the problems with the
currently proposed encodings for doing that, I think that the SRv6 SID
Structure Sub-Sub-TLV should be removed from
draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB Length, LN
Length, Fun. Length, and Arg. Length to all ISIS speakers can be defined in
a future document.

Thanks,
Chris

On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak <[email-masked]> wrote:

> >             [email-masked] <mailto:[email-masked]
> >
> >             <mailto:[email-masked]
> >>;

---

From: Peter Psenak <[email-masked]>
Date: Wed, 25 Mar 2020 15:48:58 +0100

Chris,

please see inline:

On 23/03/2020 17:39, Chris Bowers wrote:
> 1) As discussed in item#3 below, it is not clear that flooding LB 
> really the right approach.  However, if the WG determines that it is the 
> right approach, the current encodings of this information in the 
> proposed SRv6 SID Structure Sub-Sub-TLV are problematic.  As discussed 
> earlier in this thread, a network operator may choose to not allocate 
> all locators from a single block, so LB Length and LN Length may not be 
> well-defined.  

I'm not sure what do you mean by not "well defined". For every SID you 
need to know the LOC (B+N) part. If you guarantee that it is the same on 
all nodes, you know it from the local config, otherwise, you advertise 
it with a SID.

> The current encoding of the SRv6 SID Structure 
> Sub-Sub-TLV makes it difficult to represent this situation.  The simple 
> thing to do for nodes that don't have a well-defined value of LB Length 
> and LN Length would be to not advertise a value for LB Length and LN 
> Length.  However, since the currently proposed SRv6 SID Structure 
> Sub-Sub-TLV combines LB Length, LN Length, Fun. Length, and Arg. Length 
> into a single sub-sub-TLV, if a node wants to advertise values for Fun. 
> Length and Arg. Length, it also has to advertise values for LB Length 
> and LN Length.  It seems like a better approach would be to have 
> different sub-sub-TLVs, one for  LB Length and LN Length, and a separate 
> one for Fun. Length and Arg. Length to be able to better represent this 
> situation.

I'm afraid you are missing an important point.

SRv6 SID is defined as LOC:FUNCT:ARG, where LOC is represented as B:N. 
To be able to find out where the func and arg are located, you need to 
know the LOC length, e.g. Block and Node length. Advertising just Func 
and Arg length does not help.

> 
> 2) Now consider the situation where a network operator chooses to 
> allocate all locators from a single block, so that LB Length and LN 
> Length are well-defined across the network.  A given node should 
> presumably advertise its own understanding of LB Length and LN Length.   
> A given node's understanding of LB Length and LN Length is a property of 
> the node.  It is not a property of a given End SID.  The currently 
> proposed SRv6 SID Structure Sub-Sub-TLV however is carried within each 
> End SID Sub-TLV.  With the currently proposed encoding, presumably an 
> implementation is expected to send the exact same values of LB Length 
> and LN Length for all of the End SIDs that it advertises.  Not only is 
> this inefficient, but it creates the need for logic to decide what to do 
> when different End SIDs advertised by the same node carry different 
> values of LB Length and LN Length in their sub-sub-TLVs.  It seems like 
> a better approach would be for a given node to advertise its 
> understanding of the value of LB Length and LN Length in a sub-TLV of 
> the Router Capability TLV.

When we design the encoding, we have to define it such, that it supports 
all possible use cases. We can not design the encoding that works for 
single use case (allocate all locators from a single block) and does not 
work for others - different block from different node, multiple blocks 
on a single node (e.g. border node), which are all valid.

> 
> 3) At this point, the only use case that has been proposed for flooding 
> the LB Length, LN Length, Fun. Length, and Arg. Length to all ISIS 
> speakers is to make it more convenient for BGP-LS to get those values to 
> an external controller as part of a topology feed from any ISIS node.  
> No use case has been proposed for ISIS speakers themselves to make use 
> of the information.  It seems like a more scalable approach would be to 
> use BGP-LS sessions to collect the information from the subset of nodes 
> that actually produce the relevant information.  So far there are no End 
> SIDs defined that are advertised in ISIS that have a non-zero Arg. 
> Length.  If an End SID with non-zero Arg. Length were to be proposed in 
> the future as needing to be flooded to all ISIS nodes, it seems likely 
> that the new End SID would also be advertised using the BGP IP/VPN/EVPN 
> control plane.   So it seems like a viable alternative for this 
> hypothetical future End SID would be to have the subset of nodes that 
> have non-zero Arg. Length values communicate to an external controller 
> via  BGP sessions. I think the WG needs a more detailed discussion of a 
> concrete use case in order to determine whether flooding LB Length, LN 
> Length, Fun. Length, and Arg. Length to all ISIS speakers is really the 
> right approach.

there are networks, where BGP is not deployed on all nodes, only on a 
few nodes that re-distribute the information to BGP-LS. In such case we 
need the IGP to distribute this data.

Argument that "it seems likely that the new End SID would also be 
advertised using the BGP IP/VPN/EVPN" is a wishful thinking that we can 
not based our encoding on.

> 
> Given the lack of a compelling use case for flooding LB Length, LN 
> Length, Fun. Length, and Arg. Length to all ISIS speakers and the 
> problems with the currently proposed encodings for doing that, I think 
> that the SRv6 SID Structure Sub-Sub-TLV should be removed from 
> draft-ietf-lsr-isis-srv6-extensions. A mechanism for flooding LB Length, 
> LN Length, Fun. Length, and Arg. Length to all ISIS speakers can be 
> defined in a future document.

The security use case has already been pointed out earlier in this thread:

Given the arguments I mentioned above, I respectfully disagree with the 
removal of the SID Structure Sub-Sub-TLV from the ISIS SRv6 draft.

thanks,
Peter

> 
> Thanks,
> Chris
> 
> On Fri, Mar 13, 2020 at 5:02 AM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Chris,
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Hi Chris,____
>      >
>      >     __ __
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      >     SPRING WG List <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>; Peter
>      >     Psenak (ppsenak) <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     locator node
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>      >
>      >         Hi Chris,____
>      >
>      >         ____
>      >
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>>; [email-masked]
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG
>     List <[email-masked] <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >       
>     <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >         <mailto:[email-masked] <mailto:[email-masked]>>>;
>     Bruno Decraene
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     locator
>      >         On Fri, Feb 28, 2020 at 8:23 AM
>     <[email-masked] <mailto:[email-masked]>
>      >         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:____
>      >
>      >             Hi Ketan,____
>      >
>      >             ____
>      >
>      >             *From**:*Ketan Talaulikar (ketant)
>     [mailto:[email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>]
>      >             *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List;
>      >             locator node in
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>> *On Behalf Of
>      >             [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Chris Bowers
>      >             <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List
>      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >           
>     <mailto:[email-masked]>>>;
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             locator node in
>      >             *From:*Lsr [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>> *On Behalf Of *Chris Bowers
>      >             *To:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>; SPRING WG List
>      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked] <mailto:[email-masked]>>>
>      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>      >
>      >                 Hi Chris,
>      >
>      >                  > LSR WG,
>      >                  >
>      >                  > Section 9 of
>     draft-ietf-lsr-isis-srv6-extensions-05
>      >                 defines the  SRv6
>      >                  > SID Structure Sub-Sub-TLV. In particular, it
>     defines
>      >                 encoding for the
>      >                  > locator block length and the locator node length.
>      >                 The text refers to
>      >                  > [I-D.ietf-spring-srv6-network-programming] for the
>      >                 definition of these
>      >                  > concepts.
>      >                  >
>      >                  > As far as I can tell, the only reference to
>     locator
>      >                 block and locator
>      >                  > node in
>     draft-ietf-spring-srv6-network-programming-10
>      >                 is section 3.1
>      >                  > which has the following text:
>      >                  >
>      >                  >     A locator may be represented as B:N where B is
>      >                 the SRv6 SID block
>      >                  >     (IPv6 subnet allocated for SRv6 SIDs by the
>      >                 operator) and N is the
>      >                  >     identifier of the parent node
>     instantiating the
>      >                 SID...
>      >                  >
>      >                  > I think that we need a much more detailed
>     description
>      >                 of the locator
>      >                  > block and locator node.
>      >
>      >                 draft-ietf-lsr-isis-srv6-extensions, as these are
>     not a
>      >                 protocol
>      >                 specific constructs.
>      >
>      >                 thanks,
>      >                 Peter
>      >
>      >                  >
>      >                  > Thanks,
>      >                  >
>      >                  > Chris
>      >                  > ____
>      >
>      >