Gentlebeings,

The spreadsheet is NOT documenting implementations.  It’s documenting what I 
could find in the relevant specifications.

Tony


> On Oct 6, 2022, at 9:51 AM, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> 
> wrote:
> 
> Chris,
> 
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak <ppse...@cisco.com> writes:
>>> Tony, Les,
>>> 
>>> I believe we can all agree that we do not want to change the behavior of
>>> existing implementations that support MP-TLVs based on the advertisements 
>>> of the
>>> MP-capability from other routers - it would break existing networks. Even 
>>> the
>>> text in the MP-TLV draft does not suggest that to be the case.
>> Are people not looking at the spreadsheet Tony put together?
>> Which implicit multi-part TLVs are these "existing implementations" 
>> advertising that keep getting referred to? Please let's work with real data 
>> -- the spreadsheet shows a grand total of *0* TLVs that could fall in this 
>> category.
> 
> then the spreadsheet is incorrect.
> 
> I know of implementation that can send and receive Multi part TLVs for 
> IPv4/IPv6 (MT) IP Reach, (MT) Extended IS reachability and IS-IS Router 
> CAPABILITY TLV to start with.
> 
> thanks,
> Peter
>> Thanks,
>> Chris.
>>> I find the discussion about advertising supported capabilities for 
>>> management
>>> purposes in IGPs interesting, but not specific, nor directly related to the
>>> MP-TLV draft. Keeping the two separate would make a lot of sense.
>>> 
>>> 
>>> my 2c,
>>> Peter
>>> 
>>> 
>>> 
>>> On 05/10/2022 22:18, Tony Li wrote:
>>>> Les,
>>>> 
>>>>> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg)
>>>>> <ginsberg=40cisco....@dmarc.ietf.org
>>>>> <mailto:ginsberg=40cisco....@dmarc.ietf.org>> wrote:
>>>>> 
>>>>> */[LES:] It is clear that we have different opinions on this – and there 
>>>>> are
>>>>> multiple folks on both sides of this discussion./*
>>>>> */What I would hope we can agree on is to separate the discussion of 
>>>>> adding
>>>>> advertisement of “feature supported” from the MP-TLV draft by writing a
>>>>> separate draft on this proposal./*
>>>>> */This would allow the two pieces of work to progress independently – as 
>>>>> they
>>>>> should./*
>>>>> *//*
>>>>> */This makes sense to me since the proposal to advertise feature support 
>>>>> is
>>>>> clearly not limited to MP-TLV and has no bearing on how MP-TLVs are
>>>>> encoded./*
>>>>> *//*
>>>>> */Can we agree on this?/*
>>>> Sorry, I’m not on board with this.  The two functions would end up
>>>> disconnected, all the way to the field.
>>>> T
>>>> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to