Subject: [Lsr] Erik Kline's Discuss on draft-ietf-lsr-isis-srv6-extensions-14: (with DISCUSS)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 18 May 2021 18:58:31 -0700

Erik Kline has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 9 ]

* I share the concerns of several of the others here about SRv6 SIDs being
  claimed to be IPv6 addresses but kinda not really being IPv6 addresses
  if their internal structure is exposed outside of the given SR router.

  If "[i]t's usage is outside of the scope of this document", can this be
  removed for now, and maybe take up the issue at some point in the future
  by which time a motivating use case might have presented itself?

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 May 2021 13:49:56 +0200

Hi Erik,

thanks for your comment, please see inline:

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

SRv6 SIDs are indeed IPv6 addresses. RFC8986 introduced the SRv6 SID 
structure. It also goes into allocation of SIDs where it describes the 
carving out of the Block for SRv6 SIDs in the domain, followed by the 
allocation of SRv6 Locators to the nodes in the domain. Then the node 
allocates the function part when instantiating the SID - and all of this 
is signaled via control plane protocols. This is all exposed and know to 
the operator who determines the addressing scheme.

>    by which time a motivating use case might have presented itself?

The use-cases have not been described in this document since they were 
out of the scope of the ISIS protocol operations. Some of the use-cases 
discussed have been :

- automation and verification of blocks/locators and setup of filtering 
for them at SR domain boundaries

- validation of SRv6 SIDs being instantiated and advertised via IGP; 
these can be learnt by apps/controllers via BGP-LS and then monitored 
for conformance to the addressing rules set by the operator.

- verification and even determination of summary routes to be used for 
covering the SRv6 Locators and SIDs.

There may be other use-cases that may be operator or vendor specific. 
The use-cases are not within the scope of ISIS protocol extensions and 
are either operational or implementation specific – hence we said it was 
out of the scope of this document.

If you feel adding these to the document may help to clear your 
concerns, I can certainly add them.

thanks,
Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 May 2021 09:59:45 -0400

I have been watching this debate, and I am left with the impression that 
the information being defined in section 9 of this draft is simply not 
useful for routing.   It confuses operational information with routing 
information.  Given taht the information has to come from somewhere 
outside the router anyway, iand that it is not going to be consumed by 
the routers who receive the advertisements, why is it here?

Yours,
Joel

On 5/20/2021 7:49 AM, Peter Psenak wrote:
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 May 2021 16:10:23 +0200

Joel,

On 20/05/2021 15:59, Joel M. Halpern wrote:
> outside the router anyway, 

the information comes from the router, that is where the SRv6 SID is 
allocated.

Similar to a prefix that is configured on the router and is advertised 
together with some additional attributes (e.g. tag). These attributes 
may or may not be used for routing.

thanks,
Peter

> iand that it is not going to be consumed by

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 May 2021 16:54:17 +0200

Joel,

> may or may not be used for routing.

here's the quote from the rfc5130 that defined the ISIS admin tag TLVs:

    "The methods for which their use is employed is beyond the scope of
     this document and left to the implementer and/or operator."

I just want to point out that there are already examples where IGPs 
carry attribute (e.g. for a prefix), which usage is not specified in the 
ISIS specification and is left for the implementer and/or operator - 
means it's not necessarily used for routing. SID Structure would not be 
the first one.

thanks,
Peter

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 20 May 2021 10:59:23 -0400

None of the cases you described are used for routing.

And advertising information for which we do not know the use seems a bad 
idea.

The abstraction that lets us talk about func bits and arg bits is nice. 
  But in fact, the operational structures do not depend upon that.
I really think removing section 9 would improve the document and operations.

Yours,
Joel

On 5/20/2021 10:10 AM, Peter Psenak wrote:
>>>> Please refer to 
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 May 2021 15:57:23 -0700

> And advertising information for which we do not know the use seems a bad 

At least, not something that we should feel strongly obligated to put in a
Standards-Track specification.

> The abstraction that lets us talk about func bits and arg bits is nice. 

It is certainly convenient, and probably even worth having written down.

>   But in fact, the operational structures do not depend upon that.

I am inclined to agree.  Pulling in a quote from upthread: "the information
comes from the router, that is where the SRv6 SID is allocated."  The SID
being *allocated by* the router that "owns" the IPv6 block is key to how I
came to reconcile myself with RFC 8986.  The router can allocate and put
structure in its own allocations if it wants to, so long as the protocol
itself doesn't require it, and things mostly remain fine.

It's also mostly fine if the router (or other entity) allocating the SID
values and putting structure on them wants to go and tell somebody else
what it did and how.

However, if we go and define in a standards-track document the way to tell
somebody else how it was done, and the mechanism to do so enforces a
particular structure on the allocation, that becomes problematic for me.  I
think a lot of my unease with this mechanism would go away if it was not
described or implied that this is the only way to have structure to a SID
and the option was open for the router to allocate its SIDs (and
communicate about them) in some other way.

(That said, I still think it would be better done in a different document
than this one.)

-Ben

---

From: Peter Psenak <[email-masked]>
Date: Sun, 23 May 2021 21:20:16 +0200

Hi Ben,

please see inline:

> values and putting structure on them wants to go and tell somebody else

above is exactly what the SID Structure TLV was defined for.

> particular structure on the allocation, that becomes problematic for me.

I don't see where the ISIS SRv6 draft enforces any particular structure 
on the SID allocation.

All that the draft does is that it provides a mechanism to advertise the 
SID structure, if the SID was allocated using the structure defined in 
RFC 8986. On top of that, the SID Structure TLV is optional, please see 
the first sentence of section 9.

So there is absolutely no enforcement in this draft in terms of the 
structure of the SID allocation.

   > I think a lot of my unease with this mechanism would go away if it 
was not
> communicate about them) in some other way.

the draft does not say anything about this being the only way to have 
structure associated with the SID. It defines the TLV for the only 
structure that RFC 8986 defined. That's all.

thanks,
Peter