Re: [Lsr] Multi-part TLVs for extending sub-tlv space...

2022-10-09 Thread Les Ginsberg (ginsberg)
Chris -

Selected quotes from existing RFCs aren't going to resolve anything.
For example, I can point you to RFC 7981 which states:

"more than one IS-IS Router CAPABILITY TLV from the same
   source MAY be present."

But does not specify any special encoding rules for the multiple TLVs i.e., all 
TLVs are encoded in the same way. And we do have interoperable implementation 
for MP-TLVs for Router Capability TLV today.

Similarly, in RFC 8919 in Section 4.3 it is stated:

"Multiple TLVs for the same link MAY be advertised."

and again no special encoding rules are specified.

But, I understand you are still concerned and feel that "something additional" 
is needed when using MP-TLVs - at least in cases where existing RFCs have not 
explicitly mentioned MP-TLV support.
To move this discussion forward, please define the protocol extensions you 
believe are necessary i.e., please define your recommended solution.

Thanx.

Les

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Sunday, October 9, 2022 11:51 AM
> To: Christian Hopps 
> Cc: Les Ginsberg (ginsberg) ; Tony Li ;
> Peter Psenak (ppsenak) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] Multi-part TLVs for extending sub-tlv space...
> 
> 
> Christian Hopps  writes:
> 
> > Christian Hopps  writes:
> >
> >> Why did we explicitly define multi-part TLVs?
> >
> > I offer this as an answer to my own question:
> >
> > We have the standard (RFC5303) which defined sub-tlvs in IS-IS, and says
> this in "3. The Extended IS Reachability TLV"
> 
> That should have been RFC5305 of course...
> 
> >
> >"There is no defined mechanism for extending the sub-TLV space.
> > Thus, wasting sub-TLV space is discouraged."
> >
> > Thanks,
> > Chris.
> > [as wg-member]

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


Re: [Lsr] Multi-part TLVs for extending sub-tlv space...

2022-10-09 Thread Christian Hopps


Christian Hopps  writes:


Christian Hopps  writes:


Why did we explicitly define multi-part TLVs?


I offer this as an answer to my own question:

We have the standard (RFC5303) which defined sub-tlvs in IS-IS, and says this in "3. 
The Extended IS Reachability TLV"


That should have been RFC5305 of course...



   "There is no defined mechanism for extending the sub-TLV space.
Thus, wasting sub-TLV space is discouraged."

Thanks,
Chris.
[as wg-member]




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] Multi-part TLVs for extending sub-tlv space...

2022-10-09 Thread Christian Hopps



Christian Hopps  writes:


Why did we explicitly define multi-part TLVs?


I offer this as an answer to my own question:

We have the standard (RFC5303) which defined sub-tlvs in IS-IS, and says this in "3. 
The Extended IS Reachability TLV"

   "There is no defined mechanism for extending the sub-TLV space.
Thus, wasting sub-TLV space is discouraged."

Thanks,
Chris.
[as wg-member]

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


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

2022-10-09 Thread Aijun Wang
>From my understanding, to introduce the Multi-part TLV into the network, the
following two things should be done:
1) The capability negotiation. Unless all of nodes support such
capabilities, the advertisement of Multi-part TLV should not be initiated,
or else, lack of the correct parsing of Mult-part TLV by one of the nodes
will result in the inconsistence of LSDB, which may result in the forwarding
loop.
2) The indication of the Multi-part TLV is present, similar with the
fragment flag for IP packet encapsulation. Such indication can distinct the
Multi-part TLV from the repeated advertisements of the same TLV.

Is there any other difficult points to be solved?


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Sunday, October 9, 2022 8:49 AM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Tony Li ; Peter
Psenak (ppsenak) ; Robert Raszuk ;
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt


Christian Hopps  writes:
>>> I simply turned your question around and asked: should conforming
>>
>>> implementations be penalized?
>>
>> [LES:] Are you claiming that the absence of an explicit statement 
>> regarding support of MP for a given TLV  is equivalent to a 
>> prohibition against sending them (which fails basic logic)?
>
> Why did we explicitly define multi-part TLVs?
>
> I agree we appear to not making any progress here. Perhaps it would be
more productive to have a discussion in a different forum like an interim or
something similar.
>
> Thanks,
> Chris.
> [as wg-chair]

Gah, I meant "as wg-member"! However, the suggestion of a different forum
could probably come from the chair hat as well. :)

Thanks,
Chris.

___
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