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

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:
> 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