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


Hi Acee,

> You realize the latest version still has the statement: 
> 
>If all routers in an area advertise the Multi-part TLV Capability a
>node MAY advertise multi-part TLVs to increase space for payload
>values, unless otherwise specified by the TLV.
>  
> At a minimum, the draft should specify a configuration parameter dictating 
> whether advertisement of the capability by all area IS-IS routers is required 
> for advertisement. With this new parameter, my preference would be to then 
> leave it to implementations as to the default value, i.e., beyond the scope 
> of the document.


Yes, I realize that the current draft is out of date.  The pending version of 
the draft relaxes this.

I cannot publish a new version of the draft until we have consent from all of 
the authors, which we have not achieved.

Tony

___
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-07 Thread Acee Lindem (acee)

Hi Tony,

From: Lsr  on behalf of Tony Li 
Date: Friday, October 7, 2022 at 11:21 AM
To: "Les Ginsberg (ginsberg)" 
Cc: Christian Hopps , "Peter Psenak (ppsenak)" 
, Robert Raszuk , Henk Smit 
, "lsr@ietf.org" 
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Les,

On Oct 7, 2022, at 8:16 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

What I am trying to highlight is that the existing implementations of MP-TLVs 
for the "implicit" cases should not be penalized for sending MP-TLVs that are 
encoded consistent with how MP-TLVs for the "explicit" cases have been done. 
They are actually doing the right thing.

If we are in agreement on that - great!

I have no wish to penalize anyone.

You realize the latest version still has the statement:

   If all routers in an area advertise the Multi-part TLV Capability a
   node MAY advertise multi-part TLVs to increase space for payload
   values, unless otherwise specified by the TLV.

At a minimum, the draft should specify a configuration parameter dictating 
whether advertisement of the capability by all area IS-IS routers is required 
for advertisement. With this new parameter, my preference would be to then 
leave it to implementations as to the default value, i.e., beyond the scope of 
the document.

Thanks,
Acee

T

___
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


Les,

> On Oct 7, 2022, at 8:16 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> What I am trying to highlight is that the existing implementations of MP-TLVs 
> for the "implicit" cases should not be penalized for sending MP-TLVs that are 
> encoded consistent with how MP-TLVs for the "explicit" cases have been done. 
> They are actually doing the right thing.
> 
> If we are in agreement on that - great!


I have no wish to penalize anyone.

T

___
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-07 Thread Les Ginsberg (ginsberg)

Tony -


> 
> Your summarization is incorrect.
> 
> The proposal is to advertise a advisory message that indicates that a node is
> ready to receive MP-TLVs. It prohibits nothing.

[LES:] That is what you are proposing - but others in the thread have proposed 
other ideas. For example, in an earlier post Chris stated:

>> Once we have this info I think a stronger case might be made for actually
>> having the router capability be used *operationally* (i.e., if you don't see 
>> the
>> capability advertised then that router in fact doesn't send multi-tlv tlvs 
>> and
>> they should be seen as replacements of each other),

What I am trying to highlight is that the existing implementations of MP-TLVs 
for the "implicit" cases should not be penalized for sending MP-TLVs that are 
encoded consistent with how MP-TLVs for the "explicit" cases have been done. 
They are actually doing the right thing.

If we are in agreement on that - great!

   Les

> 
> Tony
> 

___
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

> On Oct 6, 2022, at 1:56 PM, Christian Hopps  wrote:
> 
> Tony I think you may have interpreted these differently?

Ayup.  As stated, I am human.  I blew it.  Mea culpa.

I will rename the current columns and start over.  Contributors still welcome.

T

___
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



Les,


> On Oct 6, 2022, at 7:22 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Chris -
> 
> Not trying to convince you of anything - just want to step back and summarize 
> where we are.
> 
> MP-TLV support has been explicitly allowed in multiple cases - and in these 
> cases no additional signaling has been specified i.e., all TLVs in the "set" 
> are encoded the same way they would be if the there were only 1 TLV in the 
> set and there is no signaling of MP-TLV support required in order to send 
> MP-TLVs.
> 
> Due to new features/increased scale, we now have a need to send MP-TLVs for 
> some additional TLVs (notably Prefix Reachability and Neighbor TLVs). The 
> RFCs defining these TLVs did not explicitly specify the use of MP-TLVs - but 
> they also did not specify any prohibition against doing so.
> 
> Some implementations have chosen to apply the same MP-TLV model used for the 
> "explicit-MP-TLV allowed" cases to these new cases.
> 
> Two possible protocol changes for these new cases have been suggested in this 
> thread:
> 
> 1)Require some additional encoding in the MP-TLVs to identify the TLV as a 
> member of an MP-TLV set
> 
> This would mean that the encoding of MP-TLVs would be different depending on 
> the TLV type.
> I see no justification for this.
> 
> 2)Prohibit the sending of MP-TLVs unless all nodes advertise support
> 
> Even though the encoding used by these early implementations is correct, they 
> would then be penalized and declared illegal because they did not come to the 
> WG and "ask for permission".
> I find this approach at best very petty.
> 
> I share the concern about how a network might behave when not all nodes 
> support MP-TLVs for a given TLV, but this is best handled by having an 
> implementation knob to disable the sending of MP-TLVs - thus giving the 
> operator control.
> 


Your summarization is incorrect.

The proposal is to advertise a advisory message that indicates that a node is 
ready to receive MP-TLVs. It prohibits nothing.

Tony


___
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

Chris -

Not trying to convince you of anything - just want to step back and summarize 
where we are.

MP-TLV support has been explicitly allowed in multiple cases - and in these 
cases no additional signaling has been specified i.e., all TLVs in the "set" 
are encoded the same way they would be if the there were only 1 TLV in the set 
and there is no signaling of MP-TLV support required in order to send MP-TLVs.

Due to new features/increased scale, we now have a need to send MP-TLVs for 
some additional TLVs (notably Prefix Reachability and Neighbor TLVs). The RFCs 
defining these TLVs did not explicitly specify the use of MP-TLVs - but they 
also did not specify any prohibition against doing so.

Some implementations have chosen to apply the same MP-TLV model used for the 
"explicit-MP-TLV allowed" cases to these new cases.

Two possible protocol changes for these new cases have been suggested in this 
thread:

1)Require some additional encoding in the MP-TLVs to identify the TLV as a 
member of an MP-TLV set

This would mean that the encoding of MP-TLVs would be different depending on 
the TLV type.
I see no justification for this.

2)Prohibit the sending of MP-TLVs unless all nodes advertise support

Even though the encoding used by these early implementations is correct, they 
would then be penalized and declared illegal because they did not come to the 
WG and "ask for permission".
I find this approach at best very petty.

I share the concern about how a network might behave when not all nodes support 
MP-TLVs for a given TLV, but this is best handled by having an implementation 
knob to disable the sending of MP-TLVs - thus giving the operator control.

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Thursday, October 6, 2022 4:59 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> Sending multi-part TLVs where the TLV type was not defined or talked about
> in the standard as supporting MP TLV behavior is not "according to existing
> standards". The fact that conforming implementations can be confused by
> this new behavior should be proof enough of that. But, then we have the
> fact that we *were* explicit about defining MP TLV behavior for other TLV
> types in other standards.. We'll have to agree to disagree here I think.
> 
> An SE is a sales-engineer they are the engineers a vendor sends to the
> customer to, among other things, help sell and integrate the product the
> customer is buying with the customers network. They would be privy to, for
> example, internal implementation details of the product and thus be able to
> assure the customer things would "just work", regardless of what a standard
> says.
> 
> Thanks,
> Chris.
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Chris -
> >
> > Not sure what SE means but...one more significant point.
> >
> > Multiple implementations have successfully deployed MP-TLV without any
> protocol
> > extensions. We did not require a new sub-TLV, a new flag, a sequence
> number...we
> > simply send additional information encoded according to existing
> standards. This
> > isn't "luck" - it is following existing standards.
> >
> > For implementations which do not process MP-TLVs correctly - why does
> this happen?
> > On the receive side, they do not have the intelligence in their
> implementation to do a merge.
> > On the transmit side they do not have the intelligence to generate multiple
> TLVs.
> >
> > You can propose protocol extensions (such as you have done) - but it will
> not
> > change the need for implementations to enhance their receive/generation
> logic -
> > and it will not make it any easier for implementations to do so. What it 
> > will
> do
> > is to introduce(sic) an interoperability problem because you will be
> requiring
> > implementations to understand some new advertisement in order to
> send/receive
> > MP-TLVs successfully. This is what Peter's point is about i.e., we MUST NOT
> > break existing working MP-TLV implementations by requiring protocol
> extensions
> > in order to send MP-TLVs.
> >
> > As regards deployment controls, I have no problem with recommending
> that implementations provide ways to control the enablement of the
> sending of MP-TLVs.
> >
> >    Les
> >
> >> -Original Message-
> >> From: Christian Hopps 
> >> Sent: Thursday, October 6, 2022 3:28 PM
> >> To: Les Ginsberg (ginsberg) 
> >> Cc: Chris

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

Sending multi-part TLVs where the TLV type was not defined or talked about in the 
standard as supporting MP TLV behavior is not "according to existing 
standards". The fact that conforming implementations can be confused by this new 
behavior should be proof enough of that. But, then we have the fact that we *were* 
explicit about defining MP TLV behavior for other TLV types in other standards.. We'll 
have to agree to disagree here I think.

An SE is a sales-engineer they are the engineers a vendor sends to the customer to, among 
other things, help sell and integrate the product the customer is buying with the 
customers network. They would be privy to, for example, internal implementation details 
of the product and thus be able to assure the customer things would "just 
work", regardless of what a standard says.

Thanks,
Chris.

"Les Ginsberg (ginsberg)"  writes:

Chris -

Not sure what SE means but...one more significant point.

Multiple implementations have successfully deployed MP-TLV without any protocol
extensions. We did not require a new sub-TLV, a new flag, a sequence number...we
simply send additional information encoded according to existing standards. This
isn't "luck" - it is following existing standards.

For implementations which do not process MP-TLVs correctly - why does this 
happen?
On the receive side, they do not have the intelligence in their implementation 
to do a merge.
On the transmit side they do not have the intelligence to generate multiple 
TLVs.

You can propose protocol extensions (such as you have done) - but it will not
change the need for implementations to enhance their receive/generation logic -
and it will not make it any easier for implementations to do so. What it will do
is to introduce(sic) an interoperability problem because you will be requiring
implementations to understand some new advertisement in order to send/receive
MP-TLVs successfully. This is what Peter's point is about i.e., we MUST NOT
break existing working MP-TLV implementations by requiring protocol extensions
in order to send MP-TLVs.

As regards deployment controls, I have no problem with recommending that 
implementations provide ways to control the enablement of the sending of 
MP-TLVs.

   Les

-Original Message-
From: Christian Hopps 
Sent: Thursday, October 6, 2022 3:28 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Peter Psenak (ppsenak)
; Tony Li ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt

It sounds like you're talking about networks defined to work by SE not by
standards. I don't want to argue about this, so perhaps we can agree to
disagree.

Thanks,
Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:

> Chris -
>
>> -Original Message-
>> From: Christian Hopps 
>> Sent: Thursday, October 6, 2022 1:36 PM
>> To: Peter Psenak (ppsenak) 
>> Cc: Christian Hopps ; Tony Li ; Les
>> Ginsberg (ginsberg) ; Robert Raszuk
>> ; Henk Smit ; lsr@ietf.org
>> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
>> 01.txt
>>
>>
>> Peter Psenak  writes:
>>
>> > Chris,
>> >
>> > On 06/10/2022 18:34, Christian Hopps wrote:
>> >> Peter Psenak  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.
>>
>> Do you know all of the implementations, and all of those that don't? If we
>> could publish that list then we presumably could explore more simple
>> solutions. :)
>>
>> People keep talking about breaking deployed networks, but that assumes
>> there are functional networks with implicit MP-TLVs in them. I am not
sure I
>> accep

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

Chris -

Not sure what SE means but...one more significant point.

Multiple implementations have successfully deployed MP-TLV without any protocol 
extensions. We did not require a new sub-TLV, a new flag, a sequence 
number...we simply send additional information encoded according to existing 
standards. This isn't "luck" - it is following existing standards.

For implementations which do not process MP-TLVs correctly - why does this 
happen?
On the receive side, they do not have the intelligence in their implementation 
to do a merge.
On the transmit side they do not have the intelligence to generate multiple 
TLVs.

You can propose protocol extensions (such as you have done) - but it will not 
change the need for implementations to enhance their receive/generation logic - 
and it will not make it any easier for implementations to do so. What it will 
do is to introduce(sic) an interoperability problem because you will be 
requiring implementations to understand some new advertisement in order to 
send/receive MP-TLVs successfully. This is what Peter's point is about i.e., we 
MUST NOT break existing working MP-TLV implementations by requiring protocol 
extensions in order to send MP-TLVs.

As regards deployment controls, I have no problem with recommending that 
implementations provide ways to control the enablement of the sending of 
MP-TLVs. 

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Thursday, October 6, 2022 3:28 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> It sounds like you're talking about networks defined to work by SE not by
> standards. I don't want to argue about this, so perhaps we can agree to
> disagree.
> 
> Thanks,
> Chris.
> [as wg-member]
> 
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Chris -
> >
> >> -Original Message-
> >> From: Christian Hopps 
> >> Sent: Thursday, October 6, 2022 1:36 PM
> >> To: Peter Psenak (ppsenak) 
> >> Cc: Christian Hopps ; Tony Li ; Les
> >> Ginsberg (ginsberg) ; Robert Raszuk
> >> ; Henk Smit ; lsr@ietf.org
> >> Subject: Re: [Lsr] New Version Notification for 
> >> draft-pkaneria-lsr-multi-tlv-
> >> 01.txt
> >>
> >>
> >> Peter Psenak  writes:
> >>
> >> > Chris,
> >> >
> >> > On 06/10/2022 18:34, Christian Hopps wrote:
> >> >> Peter Psenak  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.
> >>
> >> Do you know all of the implementations, and all of those that don't? If we
> >> could publish that list then we presumably could explore more simple
> >> solutions. :)
> >>
> >> People keep talking about breaking deployed networks, but that assumes
> >> there are functional networks with implicit MP-TLVs in them. I am not
> sure I
> >> accept the assertion that these networks are truly functional.
> >>
> >> AFAICT these networks are *lucky* to be working. There's no document
> to
> >> point at, there's no bit to look at, there's literally nothing to help an
> operator
> >> or their routers know if all the routers correctly receive and process 
> >> these
> >> implicit MP-TLVs. These networks are one network change (even as small
> as
> >> an interface up or down event) awa

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

2022-10-06 Thread Robert Raszuk

Dear LSR WG,

> MP-TLVs (explicit or implicit) are not an extension of the protocol -
they are completely consistent
> with the base operation of the protocol. I have always viewed lack of
support for MP-TLVs as an
> implementation limitation - not a gap in the protocol.

I don't agree with this assertion. For many of us resending PDU with the
same key is an implicit update.

Is there any text in the base ISIS spec which would suggest otherwise ?

> you're talking about networks defined to work by SE not by standards

It seems like it. The problem with this is that it works well in static
single vendor networks where one can always blame operators for
"provisioning mistakes''.  We can do much better than that. I am with Tony,
Chris, Bruno here. It is cool that the IETF consensus does not have a
"liberum veto" (unanimity <https://en.wikipedia.org/wiki/Unanimity> voting
rule).

Thx,
Robert.

PS. And we all know how splitting the drafts will end up .. so no thank you
Peter & Les for this suggestion.


On Fri, Oct 7, 2022 at 12:20 AM Les Ginsberg (ginsberg) 
wrote:

> Chris -
>
> > -Original Message-
> > From: Christian Hopps 
> > Sent: Thursday, October 6, 2022 1:36 PM
> > To: Peter Psenak (ppsenak) 
> > Cc: Christian Hopps ; Tony Li ; Les
> > Ginsberg (ginsberg) ; Robert Raszuk
> > ; Henk Smit ; lsr@ietf.org
> > Subject: Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-
> > 01.txt
> >
> >
> > Peter Psenak  writes:
> >
> > > Chris,
> > >
> > > On 06/10/2022 18:34, Christian Hopps wrote:
> > >> Peter Psenak  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.
> >
> > Do you know all of the implementations, and all of those that don't? If
> we
> > could publish that list then we presumably could explore more simple
> > solutions. :)
> >
> > People keep talking about breaking deployed networks, but that assumes
> > there are functional networks with implicit MP-TLVs in them. I am not
> sure I
> > accept the assertion that these networks are truly functional.
> >
> > AFAICT these networks are *lucky* to be working. There's no document to
> > point at, there's no bit to look at, there's literally nothing to help
> an operator
> > or their routers know if all the routers correctly receive and process
> these
> > implicit MP-TLVs. These networks are one network change (even as small as
> > an interface up or down event) away from failing, or may even be failing
> > already but not yet in a noticeable way. This is the case regardless of
> what
> > type of bit or functionality this document provides.
>
> [LES:] I don't agree at all with your characterization.
>
> MP-TLVs (explicit or implicit) are not an extension of the protocol - they
> are completely consistent with the base operation of the protocol. I have
> always viewed lack of support for MP-TLVs as an implementation limitation -
> not a gap in the protocol.
> Until relatively recently, there was no need to send MP-TLVs for
> neighbors/prefixes and since it is far from trivial to implement MP-TLV
> support it is understandable why most(all?) implementations did not include
> such support initially.
> But this does not mean that the protocol itself lacks the support.
>
> Would it have been better if all RFCs were explicit about the possibility
> of MP-TLVs? Sure - but hindsight is always easier than foresight.
> And even in those cases where MP-TLV support was explicitly defined, this
> did not guarantee that all implementations had that supp

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

It sounds like you're talking about networks defined to work by SE not by 
standards. I don't want to argue about this, so perhaps we can agree to 
disagree.

Thanks,
Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:

Chris -

-Original Message-
From: Christian Hopps 
Sent: Thursday, October 6, 2022 1:36 PM
To: Peter Psenak (ppsenak) 
Cc: Christian Hopps ; Tony Li ; Les
Ginsberg (ginsberg) ; Robert Raszuk
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
01.txt

Peter Psenak  writes:

> Chris,
>
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak  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.

Do you know all of the implementations, and all of those that don't? If we
could publish that list then we presumably could explore more simple
solutions. :)

People keep talking about breaking deployed networks, but that assumes
there are functional networks with implicit MP-TLVs in them. I am not sure I
accept the assertion that these networks are truly functional.

AFAICT these networks are *lucky* to be working. There's no document to
point at, there's no bit to look at, there's literally nothing to help an 
operator
or their routers know if all the routers correctly receive and process these
implicit MP-TLVs. These networks are one network change (even as small as
an interface up or down event) away from failing, or may even be failing
already but not yet in a noticeable way. This is the case regardless of what
type of bit or functionality this document provides.

[LES:] I don't agree at all with your characterization.

MP-TLVs (explicit or implicit) are not an extension of the protocol - they are
completely consistent with the base operation of the protocol. I have always
viewed lack of support for MP-TLVs as an implementation limitation - not a gap
in the protocol.
Until relatively recently, there was no need to send MP-TLVs for
neighbors/prefixes and since it is far from trivial to implement MP-TLV support
it is understandable why most(all?) implementations did not include such support
initially.
But this does not mean that the protocol itself lacks the support.

Would it have been better if all RFCs were explicit about the possibility of 
MP-TLVs? Sure - but hindsight is always easier than foresight.
And even in those cases where MP-TLV support was explicitly defined, this did
not guarantee that all implementations had that support. Vendors make decisions
based on business as to how they spend their development budget and I think we
are both familiar with decisions to defer support for some aspects of the
protocol until a stronger business case arises.

Regarding existing networks, MP-TLVs are an aspect of scale and feature support.
If your deployment includes many flex-algos or a large number of TE attributes
or other features which add to the information needing to be advertised, then
MP-TLVs are required.
Implementations which do not support MP-TLVs cannot be deployed in such 
environments - and it isn’t because of interoperability issues - it is because 
they do not support the scale/features required.

As my employer has implementations which do support MP-TLVs, I can say that we
do not depend upon luck - but we do depend upon careful planning. We work with
our customers to ensure that the design of the network - including the
capabilities of the routers deployed - is considered.

   Les

So while looking for a solution here, I think less weight should be placed on
these "lucky networks". I'm not saying we should intentionally break them,
but they should also not count as "fully-functional" either.

Thanks,
Chris.
[as wg-member]

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

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

Chris -

> -Original Message-
> From: Christian Hopps 
> Sent: Thursday, October 6, 2022 1:36 PM
> To: Peter Psenak (ppsenak) 
> Cc: Christian Hopps ; Tony Li ; Les
> Ginsberg (ginsberg) ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> Peter Psenak  writes:
> 
> > Chris,
> >
> > On 06/10/2022 18:34, Christian Hopps wrote:
> >> Peter Psenak  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.
> 
> Do you know all of the implementations, and all of those that don't? If we
> could publish that list then we presumably could explore more simple
> solutions. :)
> 
> People keep talking about breaking deployed networks, but that assumes
> there are functional networks with implicit MP-TLVs in them. I am not sure I
> accept the assertion that these networks are truly functional.
> 
> AFAICT these networks are *lucky* to be working. There's no document to
> point at, there's no bit to look at, there's literally nothing to help an 
> operator
> or their routers know if all the routers correctly receive and process these
> implicit MP-TLVs. These networks are one network change (even as small as
> an interface up or down event) away from failing, or may even be failing
> already but not yet in a noticeable way. This is the case regardless of what
> type of bit or functionality this document provides.

[LES:] I don't agree at all with your characterization.

MP-TLVs (explicit or implicit) are not an extension of the protocol - they are 
completely consistent with the base operation of the protocol. I have always 
viewed lack of support for MP-TLVs as an implementation limitation - not a gap 
in the protocol.
Until relatively recently, there was no need to send MP-TLVs for 
neighbors/prefixes and since it is far from trivial to implement MP-TLV support 
it is understandable why most(all?) implementations did not include such 
support initially.
But this does not mean that the protocol itself lacks the support.

Would it have been better if all RFCs were explicit about the possibility of 
MP-TLVs? Sure - but hindsight is always easier than foresight.
And even in those cases where MP-TLV support was explicitly defined, this did 
not guarantee that all implementations had that support. Vendors make decisions 
based on business as to how they spend their development budget and I think we 
are both familiar with decisions to defer support for some aspects of the 
protocol until a stronger business case arises.

Regarding existing networks, MP-TLVs are an aspect of scale and feature 
support. If your deployment includes many flex-algos or a large number of TE 
attributes or other features which add to the information needing to be 
advertised, then MP-TLVs are required.
Implementations which do not support MP-TLVs cannot be deployed in such 
environments - and it isn’t because of interoperability issues - it is because 
they do not support the scale/features required.

As my employer has implementations which do support MP-TLVs, I can say that we 
do not depend upon luck - but we do depend upon careful planning. We work with 
our customers to ensure that the design of the network - including the 
capabilities of the routers deployed - is considered.

   Les

> 
> So while looking for a solution here, I think less weight should be placed on
> these "lucky networks". I'm not saying we should intentionally break them,
> but they should also not count as "fully-functional" either.
> 
> Thanks,
> Chris.
> [as wg-member]
> 
> 
> >
> > thanks,
> > Peter
> >> Thanks,
> >> Chris.
> >>
> >>> I find the discussion about advertising supported capabilities for
> management
> >>

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

Chris -

An example of what I refer to as "Do Not Apply" is "2   IIS Neighbors".
This is the old style (AKA narrow metric) neighbor advertisement which has a 
fixed format and does not support sub-TLVs. It is impossible to advertise 
information about the same neighbor in multiple TLVs (unless you just want to 
be redundant - which I would consider a bug outside of transient conditions 
where a TLV moves from one LSP to another). The discussion of "multi-part" 
simply has no meaning for this TLV.

Calling this "implicit single-part TLVs" isn’t as attractive to me. It would 
seem to require a definition of what a "single-part TLV" is - whereas saying 
"NA" just indicates "multi-part" isn't applicable and requires no further 
explanation.
But I won’t argue the point as long as we have a common understanding.

The significant issue at the moment is that such TLVs are currently marked as 
"Explicit multi-part TLV allowed" in the spreadsheet and this is wrong.

   Les

> -Original Message-
> From: Christian Hopps 
> Sent: Thursday, October 6, 2022 1:56 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; Peter Psenak (ppsenak)
> ; Tony Li ; Robert Raszuk
> ; Henk Smit ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> "Les Ginsberg (ginsberg)"  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 
> >
> >> Sent: Thursday, October 6, 2022 9:34 AM
> >
> >> To: Peter Psenak (ppsenak) 
> >
> >> Cc: Tony Li ; Les Ginsberg (ginsberg)
> > ;
> >
> >> Christian Hopps ; Robert Raszuk
> >
> >> ; Henk Smit ; lsr@ietf.org
> >
> >> Subject: Re: [Lsr] New Version Notification for
> > draft-pkaneria-lsr-multi-tlv-
> >
> >> 01.txt
> >
> >>
> >
> >>
> >
> >> Peter Psenak  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
> >
> >> >
> >
> >> >
> >
> >> >
> >
> >

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

"Les Ginsberg (ginsberg)"  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 

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

To: Peter Psenak (ppsenak) 

Cc: Tony Li ; Les Ginsberg (ginsberg)

;

Christian Hopps ; Robert Raszuk

; Henk Smit ; lsr@ietf.org

Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-

01.txt

Peter Psenak  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)

>>> 

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

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

Peter Psenak writes:

Chris,

On 06/10/2022 18:34, Christian Hopps wrote:

Peter Psenak 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.

Do you know all of the implementations, and all of those that don't? If we
could publish that list then we presumably could explore more simple solutions.
:)

People keep talking about breaking deployed networks, but that assumes there
are functional networks with implicit MP-TLVs in them. I am not sure I accept
the assertion that these networks are truly functional.

AFAICT these networks are *lucky* to be working. There's no document to point
at, there's no bit to look at, there's literally nothing to help an operator or
their routers know if all the routers correctly receive and process these
implicit MP-TLVs. These networks are one network change (even as small as an
interface up or down event) away from failing, or may even be failing already
but not yet in a noticeable way. This is the case regardless of what type of
bit or functionality this document provides.

So while looking for a solution here, I think less weight should be placed on these "lucky
networks". I'm not saying we should intentionally break them, but they should also not count
as "fully-functional" either.

Thanks,
Chris.
[as wg-member]

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

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

Sooo, Tony asked that feedback on the table be unicast for now (which is wise) 
- but I think there is one point that needs to be understood publicly - which 
has to do with what is the meaning of "MP-TLV".



As per 
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-01.html#section-3 
(emphasis added):



“If a router advertises multiple TLV tuples with the same Type code in an IS-IS 
IIH packet or in the set of LSPs for a level with the same key value, they are 
considered a multi-part TLV (MP-TLV).”



We are not talking here about cases where a particular TLV type (such as 135 
Extended IP reachability) is sent multiple times where each instance of the TLV 
advertises a disjoint set of prefixes. That clearly is supported by all 
implementations today and is NOT what is meant by “Multi-part”.

A Multi-part TLV (using the example of IP Extended Reachability) is where 
multiple TLVs are advertising information about the same prefix.



If anyone is confused about this or disagrees with this, please speak up now.



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.



   Les



> -Original Message-

> From: Christian Hopps 

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

> To: Peter Psenak (ppsenak) 

> Cc: Tony Li ; Les Ginsberg (ginsberg) ;

> Christian Hopps ; Robert Raszuk

> ; Henk Smit ; lsr@ietf.org

> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-

> 01.txt

>

>

> Peter Psenak mailto: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)

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

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

2022-10-06 Thread Tony Li


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  
> wrote:
> 
> Chris,
> 
> On 06/10/2022 18:34, Christian Hopps wrote:
>> Peter Psenak  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)
>  > 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

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

2022-10-06 Thread Peter Psenak


Chris,

On 06/10/2022 18:34, Christian Hopps wrote:


Peter Psenak  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)
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

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



Peter Psenak  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)
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





signature.asc
Description: PGP signature
___
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-06 Thread Tony Li

Hi Chris,

> On Oct 5, 2022, at 1:26 PM, Christian Hopps  wrote:
> 
> That is great news b/c it means we can fix those 3 unpublished TLV to be 
> explicit multi-part. After fixing those 3 we are in a much friendly place of 
> defining only future behavior/standard requirements without concern of 
> impacting current deployments.

Yes, those are easily ‘fixed’, if folks feel that those need fixing.

Please note that the real point of this draft is to allow us to treat TLVs that 
are in the “implicit single part TLV” column as being multi-part.

And the real bone of contention is whether or not we should have a router 
capability as a means of signaling readiness to accept those.

Tony

___
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-06 Thread Peter Psenak


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.


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

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

Les,

I agree - the scenario I presented is much bigger than this thread.

But in this thread what is being discussed is one little (arguably very
valuable) piece of it.

Many thx,
R.




On Thu, Oct 6, 2022 at 12:00 AM Les Ginsberg (ginsberg) 
wrote:

> I see – so you want a configuration model that says “Enable X when
> conditions Y and Z are met”.
>
>
>
> There are examples of this already e.g., conditional installation of
> static routes based on reachability/interface state… but they are typically
> quite modest in scope.
>
>
>
> Applying this to all of the potentially applicable configs would be quite
> complex and require lots of extensions to the configuration model supported.
>
> And it still risks oscillation…
>
>
>
> This is a big ask – and I think goes well beyond what has been discussed
> in this thread – so if you want to pursue this I think another thread/draft
> is called for.
>
> Certainly well beyond anything I am thinking about.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 2:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> >  where implementations decide when to apply configuration that has been
> accepted
>
>
>
> where implementations decide when to apply *conditional* configuration
> that has been accepted
>
>
>
> Thx,
> R.
>
>
>
> On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> This has nothing to do with centralized vs distributed.
>
>
>
> You are advocating a model where implementations decide when to apply
> configuration that has been accepted. This fundamentally changes the
> authority from the management tool (be it manual or automated) to the
> implementation.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 1:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> Hi Les,
>
>
>
> Yes you have correctly understood my last point.
>
>
>
> So your take it to always put a human to operate/run the network.
> Enable statically features and always manually map user traffic to such
> features.
>
>
>
> That's the legacy (old fashioned) network model. Yes it works today
> in a lot of networks, but is it to stay like this forever ?
>
>
>
> My view is that networks should operate by themselves (or as much
> autonomously as possible).
>
>
>
> We can do it via management plane - centralized model
>
> or
>
> We can do it in the network itself - distributed model.
>
>
>
> What are the network's overall transit capabilities should be dynamically
> signalled to applications too.
>
>
>
> It is surprising you are so much endorsing a centralized (oracle like)
> approach. I am even more surprised you are against using IGP to signal
> itself what it is capable of supporting to help today's operators.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>

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

I see – so you want a configuration model that says “Enable X when conditions Y 
and Z are met”.

There are examples of this already e.g., conditional installation of static 
routes based on reachability/interface state… but they are typically quite 
modest in scope.

Applying this to all of the potentially applicable configs would be quite 
complex and require lots of extensions to the configuration model supported.
And it still risks oscillation…

This is a big ask – and I think goes well beyond what has been discussed in 
this thread – so if you want to pursue this I think another thread/draft is 
called for.
Certainly well beyond anything I am thinking about.

   Les

From: Robert Raszuk 
Sent: Wednesday, October 5, 2022 2:41 PM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; Tony Li ; Christian Hopps 
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

>  where implementations decide when to apply configuration that has been 
> accepted

where implementations decide when to apply conditional configuration that has 
been accepted

Thx,
R.

On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

This has nothing to do with centralized vs distributed.

You are advocating a model where implementations decide when to apply 
configuration that has been accepted. This fundamentally changes the authority 
from the management tool (be it manual or automated) to the implementation.

   Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, October 5, 2022 1:41 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Tony Li 
mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Henk Smit 
mailto:henk.i...@xs4all.nl>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Hi Les,

Yes you have correctly understood my last point.

So your take it to always put a human to operate/run the network. Enable 
statically features and always manually map user traffic to such features.

That's the legacy (old fashioned) network model. Yes it works today in a lot of 
networks, but is it to stay like this forever ?

My view is that networks should operate by themselves (or as much autonomously 
as possible).

We can do it via management plane - centralized model
or
We can do it in the network itself - distributed model.

What are the network's overall transit capabilities should be dynamically 
signalled to applications too.

It is surprising you are so much endorsing a centralized (oracle like) 
approach. I am even more surprised you are against using IGP to signal itself 
what it is capable of supporting to help today's operators.

Best,
R.

On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

Not certain I completely understand you – but I “think” what you are saying is 
that we could allow configuration independent of what nodes in the network 
currently support, but suppress advertisement/enabling until all nodes 
advertise support.
Am I close??

If so, this is one of the aspects that adds complexity.
And it still does not result in a working network.
So, no thanks.

   Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, October 5, 2022 12:40 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Henk Smit 
mailto:henk.i...@xs4all.nl>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Just to add and expand to your point Les ...

The concept of "forward referencing" used in some OSes explicitly permit 
configuration of elements not even present on the box or in the system ahead of 
time. For example you can configure an interface which will be inserted later.

Same for any network wide feature.

However this means that activation of such network wide features can take place 
under dynamic conditions too. If "all nodes required" support feature X I can 
advertise it. (Let's assume that other nodes which do not require it will not 
crash).

That means that having such dynamic capability may be actually pretty helpful.

Thx,
R.

On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Bruno –

Thanx for commenting – I really want to hear from the operator community.

In regards to using “functionality supported” advertisements to either issue 
warnings or possibly block/disable configuration changes…I think this sounds 
better in

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

>  where implementations decide when to apply configuration that has been
accepted

where implementations decide when to apply *conditional* configuration that
has been accepted

Thx,
R.

On Wed, Oct 5, 2022 at 11:32 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> This has nothing to do with centralized vs distributed.
>
>
>
> You are advocating a model where implementations decide when to apply
> configuration that has been accepted. This fundamentally changes the
> authority from the management tool (be it manual or automated) to the
> implementation.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 1:41 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Tony Li ; Christian
> Hopps ; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> Hi Les,
>
>
>
> Yes you have correctly understood my last point.
>
>
>
> So your take it to always put a human to operate/run the network.
> Enable statically features and always manually map user traffic to such
> features.
>
>
>
> That's the legacy (old fashioned) network model. Yes it works today
> in a lot of networks, but is it to stay like this forever ?
>
>
>
> My view is that networks should operate by themselves (or as much
> autonomously as possible).
>
>
>
> We can do it via management plane - centralized model
>
> or
>
> We can do it in the network itself - distributed model.
>
>
>
> What are the network's overall transit capabilities should be dynamically
> signalled to applications too.
>
>
>
> It is surprising you are so much endorsing a centralized (oracle like)
> approach. I am even more surprised you are against using IGP to signal
> itself what it is capable of supporting to help today's operators.
>
>
>
> Best,
>
> R.
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>    Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>
>
>
> Same for any network wide feature.
>
>
>
> However this means that activation of such network wide features can take
> place under dynamic conditions too. If "all nodes required" support feature
> X I can advertise it. (Let's assume that other nodes which do not require
> it will not crash).
>
>
>
> That means that having such dynamic capability may be actually pretty
> helpful.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob

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

Robert –

This has nothing to do with centralized vs distributed.

You are advocating a model where implementations decide when to apply 
configuration that has been accepted. This fundamentally changes the authority 
from the management tool (be it manual or automated) to the implementation.

   Les

From: Robert Raszuk 
Sent: Wednesday, October 5, 2022 1:41 PM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; Tony Li ; Christian Hopps 
; Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Hi Les,

Yes you have correctly understood my last point.

So your take it to always put a human to operate/run the network. Enable 
statically features and always manually map user traffic to such features.

That's the legacy (old fashioned) network model. Yes it works today in a lot of 
networks, but is it to stay like this forever ?

My view is that networks should operate by themselves (or as much autonomously 
as possible).

We can do it via management plane - centralized model
or
We can do it in the network itself - distributed model.

What are the network's overall transit capabilities should be dynamically 
signalled to applications too.

It is surprising you are so much endorsing a centralized (oracle like) 
approach. I am even more surprised you are against using IGP to signal itself 
what it is capable of supporting to help today's operators.

Best,
R.




On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

Not certain I completely understand you – but I “think” what you are saying is 
that we could allow configuration independent of what nodes in the network 
currently support, but suppress advertisement/enabling until all nodes 
advertise support.
Am I close??

If so, this is one of the aspects that adds complexity.
And it still does not result in a working network.
So, no thanks.

   Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Wednesday, October 5, 2022 12:40 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; Les Ginsberg 
(ginsberg) mailto:ginsb...@cisco.com>>; Tony Li 
mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>; Henk Smit 
mailto:henk.i...@xs4all.nl>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt


Just to add and expand to your point Les ...

The concept of "forward referencing" used in some OSes explicitly permit 
configuration of elements not even present on the box or in the system ahead of 
time. For example you can configure an interface which will be inserted later.

Same for any network wide feature.

However this means that activation of such network wide features can take place 
under dynamic conditions too. If "all nodes required" support feature X I can 
advertise it. (Let's assume that other nodes which do not require it will not 
crash).

That means that having such dynamic capability may be actually pretty helpful.

Thx,
R.








On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Bruno –

Thanx for commenting – I really want to hear from the operator community.

In regards to using “functionality supported” advertisements to either issue 
warnings or possibly block/disable configuration changes…I think this sounds 
better in theory than it can be realized in practice.

If you block config when not all nodes advertise support for “feature X”, what 
do you do with existing config which was accepted at a time when all nodes that 
are up/reachable did advertise the needed support, but now a new node comes up 
(or becomes reachable) and it does NOT advertise the support?
What do you do on bootup when the saved config includes configuration that 
should not be accepted under the rules for “feature X”?
Do implementations have to provide a knob to control whether configs should be 
rejected or just a warning issued?
Do you think operators will now try to leverage the new “protection” they 
expect from implementations and feel free to relax testing on the assumption 
that a good implementation will prevent a “bad configuration” from being 
enabled?

And what are the candidates for such functionality?
In this thread we talk about MP-TLV support – but this is less than precise. 
What we are really talking about is MP-TLV support for specific TLVs. So this 
now requires per/TLV advertisement.
And what else might be a good candidate? What about individual sub-TLV support 
e.g., for the different link attributes? If a node advertises a link attribute 
that not all nodes support then various forms of TE/flex-algo may not work.
Do we then require each node to advertise every TLV it supports and every 
sub-TLV it supports?
What about flag bits within a given TLV/sub-TLV?

O

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



"Les Ginsberg (ginsberg)"  writes:



RFC3787 which was published 1 month prior to RFC3784 which RFC5305
replaced.

  "5.  Migration from Narrow Metrics to Wide . . ."

[LES:] Indeed - RFC 3787 - quite a useful document.
Note this section was based on input from actual implementations. So folks implemented 
migration strategies first, then it got "documented".

RFC 3784 was published in 2004 - but V0 of the draft which eventually became 
RFC 3784 was published in 1999 and there were implementations long before the 
RFC was published.


There was a transition path published along with the TLV. That's all that 
matters to make my point.


Part of what the authors of MP-TLV draft have discussed is adding a Deployment 
Considerations section to the draft. But the new version hasn't been published 
yet.


In any case, please look at Tony's spreadsheet b/c I think it changes the 
nature of the problem to be solved.

Thanks,
Chris.



   Les




signature.asc
Description: PGP signature
___
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

> 
> RFC3787 which was published 1 month prior to RFC3784 which RFC5305
> replaced.
> 
>   "5.  Migration from Narrow Metrics to Wide . . ."
[LES:] Indeed - RFC 3787 - quite a useful document.
Note this section was based on input from actual implementations. So folks 
implemented migration strategies first, then it got "documented".

RFC 3784 was published in 2004 - but V0 of the draft which eventually became 
RFC 3784 was published in 1999 and there were implementations long before the 
RFC was published.

Part of what the authors of MP-TLV draft have discussed is adding a Deployment 
Considerations section to the draft. But the new version hasn't been published 
yet.

   Les

___
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

Tony Li writes:

Hi all,

On Oct 3, 2022, at 8:37 AM, Christian Hopps wrote:

[As wg-member]

I think the draft should include a table of all top level TLVS as rows and for
columns we have

- "Implicit Single TLV Only" (e.g., no key info)
- "Implicit Multi-TLV Only"
- "Explicit Single TLV Only"
- "Explicit Multi-TLV-Allowed"

This draft then would *explicitly* cover the existing "implicit" cases and we
have the table to point at to be precise about what we are talking about.

I have completed this effort.

Wow, thanks for doing this!

This is very interesting and useful data. If I am reading it correctly, we have
no(*) published TLVs which might implicitly use multi-part TLV encoding.

And, we have only 3 that are not yet published in RFCs that fall into this
"implicitly multi-part TLV" category.

That is great news b/c it means we can fix those 3 unpublished TLV to be
explicit multi-part. After fixing those 3 we are in a much friendly place of
defining only future behavior/standard requirements without concern of
impacting current deployments.

Thanks again!
Chris.

(*) TRILL TLV has been published, but that is an entirely different protocol.

Rather than burden the draft with this, I have created a spreadsheet and am
sharing a link to the sheet:
https://docs.google.com/spreadsheets/d/1VWQHsJTq7JRUVdRVcRd_QYYyY_LiOX7H0ZKn8feRZo4/edit?usp=sharing

There are numerous proprietary TLVs that I cannot evaluate. I have ignored them.

I am human. I expect that I will have missed several things. If you have a
correction, please unicast me.

Regards,
Tony

signature.asc
Description: PGP signature
___
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

Hi Les,

Yes you have correctly understood my last point.

So your take it to always put a human to operate/run the network.
Enable statically features and always manually map user traffic to such
features.

That's the legacy (old fashioned) network model. Yes it works today
in a lot of networks, but is it to stay like this forever ?

My view is that networks should operate by themselves (or as much
autonomously as possible).

We can do it via management plane - centralized model
or
We can do it in the network itself - distributed model.

What are the network's overall transit capabilities should be dynamically
signalled to applications too.

It is surprising you are so much endorsing a centralized (oracle like)
approach. I am even more surprised you are against using IGP to signal
itself what it is capable of supporting to help today's operators.

Best,
R.




On Wed, Oct 5, 2022 at 10:24 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Not certain I completely understand you – but I “think” what you are
> saying is that we could allow configuration independent of what nodes in
> the network currently support, but suppress advertisement/enabling until
> all nodes advertise support.
>
> Am I close??
>
>
>
> If so, this is one of the aspects that adds complexity.
>
> And it still does not result in a working network.
>
> So, no thanks.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Wednesday, October 5, 2022 12:40 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* bruno.decra...@orange.com; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Tony Li ; Christian Hopps <
> cho...@chopps.org>; Henk Smit ; lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
>
>
> Just to add and expand to your point Les ...
>
>
>
> The concept of "forward referencing" used in some OSes explicitly permit
> configuration of elements not even present on the box or in the system
> ahead of time. For example you can configure an interface which will be
> inserted later.
>
>
>
> Same for any network wide feature.
>
>
>
> However this means that activation of such network wide features can take
> place under dynamic conditions too. If "all nodes required" support feature
> X I can advertise it. (Let's assume that other nodes which do not require
> it will not crash).
>
>
>
> That means that having such dynamic capability may be actually pretty
> helpful.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
> wrote:
>
> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob to control whether configs
> should be rejected or just a warning issued?
>
> Do you think operators will now try to leverage the new “protection” they
> expect from implementations and feel free to relax testing on the
> assumption that a good implementation will prevent a “bad configuration”
> from being enabled?
>
>
>
> And what are the candidates for such functionality?
>
> In this thread we talk about MP-TLV support – but this is less than
> precise. What we are really talking about is MP-TLV support for specific
> TLVs. So this now requires per/TLV advertisement.
>
> And what else might be a good candidate? What about individual sub-TLV
> support e.g., for the different link attributes? If a node advertises a
> link attribute that not all nodes support then various forms of
> TE/flex-algo may not work.
>
> Do we then require each node to advertise every TLV it supports and every
> sub-TLV it supports?
>
> What about flag bits within a given TLV/sub-TLV?
>
>
>
> One response to this is to say “we will limit this to ‘important’
> advertisements” – but how are we to agree on what is important and what
> isn’t? Do we have an operational definition of “important”?

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

Robert –

Not certain I completely understand you – but I “think” what you are saying is 
that we could allow configuration independent of what nodes in the network 
currently support, but suppress advertisement/enabling until all nodes 
advertise support.
Am I close??

If so, this is one of the aspects that adds complexity.
And it still does not result in a working network.
So, no thanks.

   Les

From: Robert Raszuk 
Sent: Wednesday, October 5, 2022 12:40 PM
To: Les Ginsberg (ginsberg) 
Cc: bruno.decra...@orange.com; Les Ginsberg (ginsberg) ; 
Tony Li ; Christian Hopps ; Henk Smit 
; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Just to add and expand to your point Les ...

The concept of "forward referencing" used in some OSes explicitly permit 
configuration of elements not even present on the box or in the system ahead of 
time. For example you can configure an interface which will be inserted later.

Same for any network wide feature.

However this means that activation of such network wide features can take place 
under dynamic conditions too. If "all nodes required" support feature X I can 
advertise it. (Let's assume that other nodes which do not require it will not 
crash).

That means that having such dynamic capability may be actually pretty helpful.

Thx,
R.

On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Bruno –

Thanx for commenting – I really want to hear from the operator community.

In regards to using “functionality supported” advertisements to either issue 
warnings or possibly block/disable configuration changes…I think this sounds 
better in theory than it can be realized in practice.

If you block config when not all nodes advertise support for “feature X”, what 
do you do with existing config which was accepted at a time when all nodes that 
are up/reachable did advertise the needed support, but now a new node comes up 
(or becomes reachable) and it does NOT advertise the support?
What do you do on bootup when the saved config includes configuration that 
should not be accepted under the rules for “feature X”?
Do implementations have to provide a knob to control whether configs should be 
rejected or just a warning issued?
Do you think operators will now try to leverage the new “protection” they 
expect from implementations and feel free to relax testing on the assumption 
that a good implementation will prevent a “bad configuration” from being 
enabled?

And what are the candidates for such functionality?
In this thread we talk about MP-TLV support – but this is less than precise. 
What we are really talking about is MP-TLV support for specific TLVs. So this 
now requires per/TLV advertisement.
And what else might be a good candidate? What about individual sub-TLV support 
e.g., for the different link attributes? If a node advertises a link attribute 
that not all nodes support then various forms of TE/flex-algo may not work.
Do we then require each node to advertise every TLV it supports and every 
sub-TLV it supports?
What about flag bits within a given TLV/sub-TLV?

One response to this is to say “we will limit this to ‘important’ 
advertisements” – but how are we to agree on what is important and what isn’t? 
Do we have an operational definition of “important”?

I think this quite easily leads to an explosion of advertisements and a great 
deal of complexity which returns very little.
If an operator configures something it is because they need that in order for 
the network to meet the requirements of the given deployment. 
Blocking/disabling config might prevent some problems – but it won’t make the 
network functional.

I am quite concerned that this is something that “sounds good” but in practice 
adds little value – yet places significant demands on implementations.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Wednesday, October 5, 2022 2:29 AM
To: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Tony 
Li mailto:tony...@tony.li>>; Christian Hopps 
mailto:cho...@chopps.org>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Henk Smit 
mailto:henk.i...@xs4all.nl>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

I’ve not followed everything in details so I’ve been reluctant to comment, but 
nonetheless please find below a diverse set of comments.

> From: Christian Hopps mailto:cho...@chopps.org>>
[…]

> AFAICT we now have implementations out there that are sending multiple TLVs 
> which are not documented to be sent that way, that historically were not 
> expected to be received that way, and then we have other implementations that 
> do not expect this new, convenient but rather loose interpretation of the 
&

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

"Les Ginsberg (ginsberg)"  writes:

Chris -

Please see inline.

[...]

> MP-TLVs are not sent just because an implementation supports them.
> They are sent because the current configuration requires them.

The SW also has the option to alert the operator that their configuration is
not supported, and to revise it, rather than play loose with standards.

The vendors who made these changes should have brought this to the IETF
as a draft that would have clear and deterministic transition mechanism (e.g.,
wide metrics had a clear transition plan documented in it's RFC).

[LES:] Hmmm...RFC 5305 says in the Introduction:

"Mechanisms and procedures to migrate to the new TLVs are not
   discussed in this document."

What are you looking at?

RFC3787 which was published 1 month prior to RFC3784 which RFC5305 replaced.

 "5.  Migration from Narrow Metrics to Wide . . ."

I'm suggesting that the most important thing to come now is to make clear
what operators need to do to have a deterministic functional network. It
doesn't have to be the way I suggested, but we have to get there somehow.

[LES:] If there was a way to do this I would be interested. Nothing proposed 
thus far does this.

What I proposed works, it is just not to your liking.

Thanks,
Chris.

___
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


Les,

> On Oct 5, 2022, at 1:14 PM, Les Ginsberg (ginsberg) 
>  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

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

Tony -

From: Tony Li  On Behalf Of Tony Li
Sent: Wednesday, October 5, 2022 7:57 AM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Robert Raszuk ; 
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

Hi Les,

Using the protocol to send what is best described as some subset of a PICS 
means that we propose to use the IGP flooding mechanism to send static 
information which the protocol itself cannot (and should not) use in its 
operation. This consumes space, bandwidth, gets periodically refreshed 
unnecessarily, and now a complete copy of the information from every node 
resides on every router in the network when it is only needed by an “NMS”. It 
would be hard to come up with a better example of “IGP isn’t a dump truck” than 
this.

If you can’t beat ‘em, join ‘em.

[LES:] Thanx for the honesty. 
Doesn’t make me like the idea though.

If there is a belief that we can severely limit the amount of information that 
is sent/node, I’d have to say that I am skeptical. Once we allow this into the 
protocol, I don’t see any basis on which to separate what is allowed and what 
is disallowed. It would not be unreasonable for an operator to say that 
everything that is a candidate to be mentioned in a PICS is a legitimate 
candidate for being advertised using this mechanism. Which means the amount of 
information is likely to become very large – especially once it becomes the de 
facto way of providing protocol management information.

The justification seems to be that we don’t have anything better – which 
represents a longstanding failure of the management plane. While I agree with 
you that management plane solutions are not adequate – not least because we 
can’t get the industry to converge on a single solution – this does not mean we 
should invest in the wrong solution.

We would be better served spending time and effort working on the right 
solution - as difficult as that may be.

If we despair of getting a management plane solution, my suggestion would be to 
use RFC 6823/6822 to define an IS-IS protocol management application that could 
support the advertisement of such information. This is technically 
straightforward to define/implement, easily extensible, and it separates the 
management information from the information used by the protocol.  And because 
a separate topology can be used for the “management instance”,  it would be 
possible to reduce the number of copies in the network.

A blue dump truck is not an architectural improvement over a red dump truck and 
definitely not the right solution.

[LES:] I agree – I don’t like the RFC6823/6822 solution – I want a management 
plane solution.
But it is better than carrying the information in the routing instance – for 
all the reasons both of us have mentioned over the years whenever someone 
proposes to use IGP flooding for information not used by the protocol itself.

What we need is a management plane mechanism that can be easily consulted, even 
by nodes not running the IGP.  Or nodes not running any IGP. We should NOT 
require storing the management data on every node. That’s silly.  Rather, we 
should have a set of distributed, synchronized servers that can be easily 
referenced and updated. We need an auto-discovery mechanism so that nodes can 
learn where these servers are. We need a common hierarchical data schema so 
that data is organized consistently. And we needed this in 1992. ;-)

Even if you agree with this, I am not willing to stall the current work the 
decades that it will take for the IETF to make progress on this.

[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?

   Les

Tony

___
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

Chris -

Please see inline.

> -Original Message-
> From: Christian Hopps 
> Sent: Wednesday, October 5, 2022 7:24 AM
> To: Les Ginsberg (ginsberg) 
> Cc: Christian Hopps ; Robert Raszuk
> ; Tony Li ; Henk Smit
> ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-
> 01.txt
> 
> 
> [as wg-member]
> 
> I don't think what I've written is being read correctly.
> 
> > If a node which supports MP-TLV were to introduce/withdraw MP-TLVs
> > based on the advertised state of support for MP-TLVs by all nodes in
> > the network,  this would introduce flooding storms on the
> > transitions. Not a good thing.
> 
> I didn't suggest this. My suggestion was that a router sending multiple-TLVs
> needs to advertise that it does so, and receivers would interpret what they
> received (is this second TLV a replacement or is it a concatenation?) based on
> that advertisement. The proposal is for a "capability" in this case and that
> could serve as this advertisement.
> 
> I believe you would argue against this as it might impact networks that just
> happen to be lucky and working right now.
>
[LES:] My argument is the presence/use of the "capability" does not result in a 
working network.
As I have stated multiple times, MP-TLVs are sent because the configuration 
requires it - not just because an implementation is capable of doing so.
Preventing advertisement of what is configured does not make the network 
healthy. It simply trades one problem for another.
 
> If things would have been done correctly (i.e., documented) we also would
> have had the option to add a sub-tlv to the TLVs in question that indicated
> they were part of a set rather than replacements.
> 
[LES:] So, this is a new proposal - not one that has been defined or even 
suggested anywhere to date.
And I don’t support it.
It deviates from how existing MP-TLV support that is already explicitly 
specified is done.
It is inefficient in that it requires modification of the original TLV simply 
to advertise additional information about the same object - which means 
additional LSPs will need to be regenerated/flooded/processed.
It would require a flag day (or knobs of some sort) because it would not work 
until all implementations supported the new sub-TLV.

> > MP-TLVs are not sent just because an implementation supports them.
> > They are sent because the current configuration requires them.
> 
> The SW also has the option to alert the operator that their configuration is
> not supported, and to revise it, rather than play loose with standards.
> 
> The vendors who made these changes should have brought this to the IETF
> as a draft that would have clear and deterministic transition mechanism (e.g.,
> wide metrics had a clear transition plan documented in it's RFC).
> 
[LES:] Hmmm...RFC 5305 says in the Introduction:

"Mechanisms and procedures to migrate to the new TLVs are not
   discussed in this document."

What are you looking at?

> I'm suggesting that the most important thing to come now is to make clear
> what operators need to do to have a deterministic functional network. It
> doesn't have to be the way I suggested, but we have to get there somehow.
>
[LES:] If there was a way to do this I would be interested. Nothing proposed 
thus far does this.

   Les
 
> Thanks,
> Chris.
> [as wg-member]
> 
> 
> "Les Ginsberg (ginsberg)"  writes:
> 
> > Chris -
> >
> >
> >
> > Inline.
> >
> >
> >
> >> -Original Message-
> >
> >> From: Christian Hopps 
> >
> >> Sent: Monday, October 3, 2022 5:52 PM
> >
> >> To: Les Ginsberg (ginsberg) 
> >
> >> Cc: Christian Hopps ; Robert Raszuk
> >
> >> ; Tony Li ; Henk Smit
> >
> >> ; lsr@ietf.org
> >
> >> Subject: Re: [Lsr] New Version Notification for
> > draft-pkaneria-lsr-multi-tlv-
> >
> >> 01.txt
> >
> >>
> >
> >>
> >
> >> [As wg-member] --- inline...
> >
> >>
> >
> >> "Les Ginsberg (ginsberg)"  writes:
> >
> >>
> >
> >> > Chris -
> >
> >> >
> >
> >> >> -Original Message-
> >
> >> >
> >
> >> >> From: Christian Hopps 
> >
> >> >> Sent: Monday, October 3, 2022 8:37 AM
> >
> >> >> To: Les Ginsberg (ginsberg) 
> >
> >> >> Cc: Robert Raszuk ; Tony Li  >>; Henk
> >
> >> Smit
> >
> >> >> ; lsr@ietf.org
> >
> >> >> Subject: Re: [Lsr] New Version

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


Hi Les,


> In this thread we talk about MP-TLV support – but this is less than precise. 
> What we are really talking about is MP-TLV support for specific TLVs. So this 
> now requires per/TLV advertisement.


No, it does not.  As you yourself verbally agreed, we are referring to the 
class of TLVs that Chris describes as ‘implicit’. They do not explicitly permit 
or reject MP-TLVs.  We need one bit of information to characterize this entire 
class.

Please stop misrepresenting what we are asking for. Please stop backpeddling on 
what you’ve already agreed to.


> One response to this is to say “we will limit this to ‘important’ 
> advertisements” – but how are we to agree on what is important and what 
> isn’t? Do we have an operational definition of “important”?


We might have to apply judgment and common sense.

Tony

___
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

Just to add and expand to your point Les ...

The concept of "forward referencing" used in some OSes explicitly permit
configuration of elements not even present on the box or in the system
ahead of time. For example you can configure an interface which will be
inserted later.

Same for any network wide feature.

However this means that activation of such network wide features can take
place under dynamic conditions too. If "all nodes required" support feature
X I can advertise it. (Let's assume that other nodes which do not require
it will not crash).

That means that having such dynamic capability may be actually pretty
helpful.

Thx,
R.








On Wed, Oct 5, 2022 at 9:33 PM Les Ginsberg (ginsberg) 
wrote:

> Bruno –
>
>
>
> Thanx for commenting – I really want to hear from the operator community.
>
>
>
> In regards to using “functionality supported” advertisements to either
> issue warnings or possibly block/disable configuration changes…I think this
> sounds better in theory than it can be realized in practice.
>
>
>
> If you block config when not all nodes advertise support for “feature X”,
> what do you do with existing config which was accepted at a time when all
> nodes that are up/reachable did advertise the needed support, but now a new
> node comes up (or becomes reachable) and it does NOT advertise the support?
>
> What do you do on bootup when the saved config includes configuration that
> should not be accepted under the rules for “feature X”?
>
> Do implementations have to provide a knob to control whether configs
> should be rejected or just a warning issued?
>
> Do you think operators will now try to leverage the new “protection” they
> expect from implementations and feel free to relax testing on the
> assumption that a good implementation will prevent a “bad configuration”
> from being enabled?
>
>
>
> And what are the candidates for such functionality?
>
> In this thread we talk about MP-TLV support – but this is less than
> precise. What we are really talking about is MP-TLV support for specific
> TLVs. So this now requires per/TLV advertisement.
>
> And what else might be a good candidate? What about individual sub-TLV
> support e.g., for the different link attributes? If a node advertises a
> link attribute that not all nodes support then various forms of
> TE/flex-algo may not work.
>
> Do we then require each node to advertise every TLV it supports and every
> sub-TLV it supports?
>
> What about flag bits within a given TLV/sub-TLV?
>
>
>
> One response to this is to say “we will limit this to ‘important’
> advertisements” – but how are we to agree on what is important and what
> isn’t? Do we have an operational definition of “important”?
>
>
>
> I think this quite easily leads to an explosion of advertisements and a
> great deal of complexity which returns very little.
>
> If an operator configures something it is because they need that in order
> for the network to meet the requirements of the given deployment.
> Blocking/disabling config might prevent some problems – but it won’t make
> the network functional.
>
>
>
> I am quite concerned that this is something that “sounds good” but in
> practice adds little value – yet places significant demands on
> implementations.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *
> bruno.decra...@orange.com
> *Sent:* Wednesday, October 5, 2022 2:29 AM
> *To:* Les Ginsberg (ginsberg) ; Tony
> Li ; Christian Hopps 
> *Cc:* Robert Raszuk ; Henk Smit ;
> lsr@ietf.org
> *Subject:* Re: [Lsr] New Version Notification for
> draft-pkaneria-lsr-multi-tlv-01.txt
>
>
>
> I’ve not followed everything in details so I’ve been reluctant to comment,
> but nonetheless please find below a diverse set of comments.
>
>
>
> > From: Christian Hopps 
>
> […]
>
> > AFAICT we now have implementations out there that are sending multiple
> TLVs which are not documented to be sent that way, that historically were
> not expected to be received that way, and then we have other
> implementations that do not expect this new, convenient but rather loose
> interpretation of the standards. Consider we have documents that explicitly
> state that a TLV can be sent multiple times, it would be completely normal
> for someone to then assume that when that isn't stated explicitly that
> multiple versions of those TLV will not be sent.
>
>
>
> > Thus the need for this document -- in some form.
>
>
>
> Thank you Chris.
>
> Definitely +1
>
>
>
> To clarify, are we talking about:
>
> - different nodes in the flooding domain having a different understanding
> of the LSDB content
>

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

Bruno -

Thanx for commenting - I really want to hear from the operator community.

In regards to using "functionality supported" advertisements to either issue 
warnings or possibly block/disable configuration changes...I think this sounds 
better in theory than it can be realized in practice.

If you block config when not all nodes advertise support for "feature X", what 
do you do with existing config which was accepted at a time when all nodes that 
are up/reachable did advertise the needed support, but now a new node comes up 
(or becomes reachable) and it does NOT advertise the support?
What do you do on bootup when the saved config includes configuration that 
should not be accepted under the rules for "feature X"?
Do implementations have to provide a knob to control whether configs should be 
rejected or just a warning issued?
Do you think operators will now try to leverage the new "protection" they 
expect from implementations and feel free to relax testing on the assumption 
that a good implementation will prevent a "bad configuration" from being 
enabled?

And what are the candidates for such functionality?
In this thread we talk about MP-TLV support - but this is less than precise. 
What we are really talking about is MP-TLV support for specific TLVs. So this 
now requires per/TLV advertisement.
And what else might be a good candidate? What about individual sub-TLV support 
e.g., for the different link attributes? If a node advertises a link attribute 
that not all nodes support then various forms of TE/flex-algo may not work.
Do we then require each node to advertise every TLV it supports and every 
sub-TLV it supports?
What about flag bits within a given TLV/sub-TLV?

One response to this is to say "we will limit this to 'important' 
advertisements" - but how are we to agree on what is important and what isn't? 
Do we have an operational definition of "important"?

I think this quite easily leads to an explosion of advertisements and a great 
deal of complexity which returns very little.
If an operator configures something it is because they need that in order for 
the network to meet the requirements of the given deployment. 
Blocking/disabling config might prevent some problems - but it won't make the 
network functional.

I am quite concerned that this is something that "sounds good" but in practice 
adds little value - yet places significant demands on implementations.

   Les


From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Wednesday, October 5, 2022 2:29 AM
To: Les Ginsberg (ginsberg) ; Tony Li 
; Christian Hopps 
Cc: Robert Raszuk ; Henk Smit ; 
lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-pkaneria-lsr-multi-tlv-01.txt

I've not followed everything in details so I've been reluctant to comment, but 
nonetheless please find below a diverse set of comments.


> From: Christian Hopps mailto:cho...@chopps.org>>
[...]

> AFAICT we now have implementations out there that are sending multiple TLVs 
> which are not documented to be sent that way, that historically were not 
> expected to be received that way, and then we have other implementations that 
> do not expect this new, convenient but rather loose interpretation of the 
> standards. Consider we have documents that explicitly state that a TLV can be 
> sent multiple times, it would be completely normal for someone to then assume 
> that when that isn't stated explicitly that multiple versions of those TLV 
> will not be sent.



> Thus the need for this document -- in some form.

Thank you Chris.
Definitely +1

To clarify, are we talking about:
- different nodes in the flooding domain having a different understanding of 
the LSDB content
- a (LS) protocol relying on all nodes in the flooding domain to have a 
consistent (view of the) LSDB (especially with FlexAlgo for which the number of 
(sub)TLV requiring a consistent view across the flooding domain has increased 
and may further increase)


And a standardization group defining specifications to allow for interop?

Sure, I'd be interested in an implementation report to at least learn about 
such (sub) TLV and those implementations.

[...]

> From: Lsr lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> On Behalf Of Les 
> Ginsberg (ginsberg)


> [LES:] This isn't a new problem for operators. There are many examples of 
> extensions to the protocol which have been introduced which result in a 
> broken network in cases of partial deployment. To list just a few:

>

>  - Wide metrics

> - Cryptographic authentication

> - Support for extended LSP lifetime (> 1200 seconds)



> The consequences of sending MP-TLVs when not all routers support them are no 
> more severe than the consequences of partial support for any of the above 
> features.

Agreed.
However, it's not because this is not a new

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


Hi Les,
 
> Using the protocol to send what is best described as some subset of a PICS 
> means that we propose to use the IGP flooding mechanism to send static 
> information which the protocol itself cannot (and should not) use in its 
> operation. This consumes space, bandwidth, gets periodically refreshed 
> unnecessarily, and now a complete copy of the information from every node 
> resides on every router in the network when it is only needed by an “NMS”. It 
> would be hard to come up with a better example of “IGP isn’t a dump truck” 
> than this.


If you can’t beat ‘em, join ‘em.


> If there is a belief that we can severely limit the amount of information 
> that is sent/node, I’d have to say that I am skeptical. Once we allow this 
> into the protocol, I don’t see any basis on which to separate what is allowed 
> and what is disallowed. It would not be unreasonable for an operator to say 
> that everything that is a candidate to be mentioned in a PICS is a legitimate 
> candidate for being advertised using this mechanism. Which means the amount 
> of information is likely to become very large – especially once it becomes 
> the de facto way of providing protocol management information.
>  
> The justification seems to be that we don’t have anything better – which 
> represents a longstanding failure of the management plane. While I agree with 
> you that management plane solutions are not adequate – not least because we 
> can’t get the industry to converge on a single solution – this does not mean 
> we should invest in the wrong solution.
>  
> We would be better served spending time and effort working on the right 
> solution - as difficult as that may be.
>  
> If we despair of getting a management plane solution, my suggestion would be 
> to use RFC 6823/6822 to define an IS-IS protocol management application that 
> could support the advertisement of such information. This is technically 
> straightforward to define/implement, easily extensible, and it separates the 
> management information from the information used by the protocol.  And 
> because a separate topology can be used for the “management instance”,  it 
> would be possible to reduce the number of copies in the network.


A blue dump truck is not an architectural improvement over a red dump truck and 
definitely not the right solution.

What we need is a management plane mechanism that can be easily consulted, even 
by nodes not running the IGP.  Or nodes not running any IGP. We should NOT 
require storing the management data on every node. That’s silly.  Rather, we 
should have a set of distributed, synchronized servers that can be easily 
referenced and updated. We need an auto-discovery mechanism so that nodes can 
learn where these servers are. We need a common hierarchical data schema so 
that data is organized consistently. And we needed this in 1992. ;-)

Even if you agree with this, I am not willing to stall the current work the 
decades that it will take for the IETF to make progress on this.

Tony

___
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



Hi all,

> On Oct 3, 2022, at 8:37 AM, Christian Hopps  wrote:
> 
> 
> [As wg-member]
> 
> I think the draft should include a table of all top level TLVS as rows and 
> for columns we have
> 
> - "Implicit Single TLV Only" (e.g., no key info)
> - "Implicit Multi-TLV Only"
> - "Explicit Single TLV Only"
> - "Explicit Multi-TLV-Allowed"
> 
> This draft then would *explicitly* cover the existing "implicit" cases and we 
> have the table to point at to be precise about what we are talking about.


I have completed this effort.

Rather than burden the draft with this, I have created a spreadsheet and am 
sharing a link to the sheet: 
https://docs.google.com/spreadsheets/d/1VWQHsJTq7JRUVdRVcRd_QYYyY_LiOX7H0ZKn8feRZo4/edit?usp=sharing

There are numerous proprietary TLVs that I cannot evaluate. I have ignored them.

I am human. I expect that I will have missed several things. If you have a 
correction, please unicast me.

Regards,
Tony

___
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

[as wg-member]

I don't think what I've written is being read correctly.

If a node which supports MP-TLV were to introduce/withdraw MP-TLVs
based on the advertised state of support for MP-TLVs by all nodes in
the network,  this would introduce flooding storms on the
transitions. Not a good thing.

I didn't suggest this. My suggestion was that a router sending multiple-TLVs needs to 
advertise that it does so, and receivers would interpret what they received (is this 
second TLV a replacement or is it a concatenation?) based on that advertisement. The 
proposal is for a "capability" in this case and that could serve as this 
advertisement.

I believe you would argue against this as it might impact networks that just 
happen to be lucky and working right now.

If things would have been done correctly (i.e., documented) we also would have 
had the option to add a sub-tlv to the TLVs in question that indicated they 
were part of a set rather than replacements.

MP-TLVs are not sent just because an implementation supports them.
They are sent because the current configuration requires them.

The SW also has the option to alert the operator that their configuration is 
not supported, and to revise it, rather than play loose with standards.

The vendors who made these changes should have brought this to the IETF as a 
draft that would have clear and deterministic transition mechanism (e.g., wide 
metrics had a clear transition plan documented in it's RFC).

I'm suggesting that the most important thing to come now is to make clear what 
operators need to do to have a deterministic functional network. It doesn't 
have to be the way I suggested, but we have to get there somehow.

Thanks,
Chris.
[as wg-member]

"Les Ginsberg (ginsberg)"  writes:

Chris -

Inline.

-Original Message-

From: Christian Hopps 

Sent: Monday, October 3, 2022 5:52 PM

To: Les Ginsberg (ginsberg) 

Cc: Christian Hopps ; Robert Raszuk

; Tony Li ; Henk Smit

; lsr@ietf.org

Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-

01.txt

[As wg-member] --- inline...

"Les Ginsberg (ginsberg)"  writes:

> Chris -

>

>> -Original Message-

>

>> From: Christian Hopps 

>> Sent: Monday, October 3, 2022 8:37 AM

>> To: Les Ginsberg (ginsberg) 

>> Cc: Robert Raszuk ; Tony Li 

Smit

>> ; lsr@ietf.org

>> Subject: Re: [Lsr] New Version Notification for

draft-pkaneria-lsr-multi-tlv-

01.txt

>

>> [As wg-member]

>>

>> I think the draft should include a table of all top level TLVS

as rows and for

>> columns we have

>>

>> - "Implicit Single TLV Only" (e.g., no key info)

>> - "Implicit Multi-TLV Only"

>> - "Explicit Single TLV Only"

>> - "Explicit Multi-TLV-Allowed"

>>

>> This draft then would *explicitly* cover the existing "implicit"

cases and

we

>> have the table to point at to be precise about what we are

talking about.

> [LES:] I am not overly enthused about this - but I can see its

> usefulness, so I don’t oppose it.

>

> Probably best realized as an additional column in the existing

IS-IS

> TLV Codepoints registry.

>

> But also realize that in some cases this extends to sub-TLVs (as

one

> example "16 Application-Specific Link Attributes").

>> Now about the capability... There's an argument about including

a router

>> capability and it seems to be that people have agreed that it

should *not*

>> have any operation impact on the protocol.

>> I think this is hasty. I would like to look at the above table

to see what

TLVs

>> we are *exactly* talking about here (the implicit multi-tlv

ones). People

have

>> said that implementations support multi-tlv use of these

implicit cases

(e.g.,

>> the draft talks about extended reachability).

>>

>> Really?

> [LES:] Yes - really. 

>> I could easily believe its not common. I think we should get

specific about

>> vendors and versions (and maybe specific TLVS?) if we are saying

this has

>> been deployed and is in use. I've written a few IS-IS

implementations and

I

>> don't think *any* of them supported multiple tlvs of, for

example,

extended

>> reachability (seeing 2 of the same keyed info would be seen as

one

replacing

>> the other, or a bug if in the same LSP segment).

> [LES:] All of us who have "been around for a while" have worked

on

> implementations that did not support MP-TLVs. Prior to new

features

> (SR, TE Metric Extensions (RFC 8570), flex-algo, more extensive

> deployments of IPv

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