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

Joel,

> Joel,
> 
> On 20/05/2021 15:59, Joel M. Halpern wrote:
>> 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,
> 
> 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.

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

> 
> thanks,
> Peter
> 
> 
> 
>> 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:
>>> Hi Erik,
>>>
>>> thanks for your comment, please see inline:
>>>
>>> On 19/05/2021 03:58, Erik Kline via Datatracker wrote:
>>>> 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.
>>>
>>>
>>> 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.
>>>
>>>
>>>>
>>>>      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?
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
> 
> 
> 