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

[Peter Psenak <[e-mail]>]

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.

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
> 
>