Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Christian Hopps]

"Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> writes:

With this in mind, Tony (as I have commented to you privately) your
table needs to be revised as there are some TLVs to which
“multi-part” simply doesn’t apply.

Those are what I believe we should refer to as "implicit single-part TLVs", 
TLVS that it would never make sense to do multi-part for some reason. And we probably 
want to define what those reasons are. It isn't necessarily just the lack of keying info. 
An unordered, unkeyed list of things (e.g., protocols supported) has no keying info, but 
could be sent multi-part and still make sense.

I think the tricky types are the "implicit multi-part TLVs" i.e., the ones like 
Extended Reachability TLV, that were not defined to be sent multi-part but could 
conceivably be advertised that way (and apparently already are but some subset of 
implementations out there).

Tony I think you may have interpreted these differently?

Thanks,
Chris.

   Les

-----Original Message-----

From: Christian Hopps <cho...@chopps.org>

Sent: Thursday, October 6, 2022 9:34 AM

To: Peter Psenak (ppsenak) <ppse...@cisco.com>

Cc: Tony Li <tony...@tony.li>; Les Ginsberg (ginsberg)

<ginsb...@cisco.com>;

Christian Hopps <cho...@chopps.org>; Robert Raszuk

<rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org

Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-

01.txt

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.

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

signature.asc
Description: PGP signature

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