[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)" <ginsb...@cisco.com> writes:

Chris -



Inline.



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

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

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

To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>

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

<rob...@raszuk.net>; Tony Li <tony...@tony.li>; Henk Smit

<henk.i...@xs4all.nl>; lsr@ietf.org

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

01.txt





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



"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> writes:



> Chris -

>

>> -----Original Message-----

>

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

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

>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>

>> Cc: Robert Raszuk <rob...@raszuk.net>; Tony Li <tony...@tony.li
; Henk

Smit

>> <henk.i...@xs4all.nl>; 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 IPv6, etc.) there wasn't a need - at least for

> Neighbor/Prefix advertisements.

>

> But deployment requirements have evolved. We absolutely have
cases

> today where a single TLV is insufficient space-wise for both
neighbor

> and prefix advertisements and there are multiple implementations

> which already support this.

>

> If the WG wants to pursue an Implementation Report on this, I
have no

> objection.

>

> BTW, the need for this should not surprise you. Discussion of
this

> problem dates back at least to 2004: https://datatracker.ietf.org
/doc

> /html/draft-shen-isis-extended-tlv-00



The need is not a surprise to me, no.



>> 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), and the
argument

>> about it's inclusion goes away as it's then required.



> [LES:] I don't agree with this argument - but I think the
discussion

> triggered by posts from Gunter and Henk has already covered this
well

> from both points of view, so I won’t repeat here.



That discussion had to do with whether to include a bit that is for

management purposes only. What I am seeing here is a need for an

operationally relevant bit (i.e., determines how the protocol
functions).





[LES:] In the discussions thus far (both on the list and discussions
I have had with folks off the list) no one has suggested that the
advertisement of MP-TLV support be used to determine what a given
implementation sends on the wire. And there is good reason for that.

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.



Also (pardon the repetition - I have stated this before), such
behavior would not result in a working network.

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

If an implementation suppresses MP-TLVs because it sees one or more
nodes in the network isn’t advertising support, some of the
information required to be advertised based on current configuration
won't be advertised - which means the network isn’t working.



There is no good way to utilize the advertisement to control what is
sent/not sent.



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.





[LES:] Well, implementations faced with deployment requirements where
more than 255 bytes are required to be sent for a given IS Neighbor
or a given prefix had to do “something” – and it was clear that
MP-TLVs are the natural extension of the protocol.

We did this with full awareness that if not all nodes in the network
supported MP-TLVs for these TLVs the network would not work
correctly. As with many aspects of scale, operators have to determine
that the nodes they deploy can support the scale required in their
deployment before they introduce the associated configuration.

And based on customer cases I have worked on over the years, I know
that operators would not be happy if we withdrew advertisements
because a new node came up and did not have the necessary support.
Instead of having only the new node be compromised, you would degrade
the support of configured features in the entire network. Clearly a
very undesirable consequence.



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



Having all routers work from the same link-state database is basic

requirement to the correct functioning of the decision process.



Are we just lucky that things haven't really broken yet? How can an
operator

even know what they've got deployed? Before this document there's

nothing to even refer to to document the possible different
behaviors.



If people want to argue that no operationally significant bit is
needed then

how can an operator be expected to get this right? What is the
exact process

they should follow to have interoperating routers?



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



Operators absolutely have to know the capabilities of the routers in
their network. But that is precisely what the management plane is
for. That is what PICS documents are for. That is what vendor
documentation is for.



Folks may well complain that management tools are not as good as they
need to be, but trying to compensate for this by adding management
information into the protocol itself isn’t a good solution.



   Les





Thanks,

Chris.

[as wg-member]



>    Les



>> Thanks,

>> Chris.

>> [as wg-member]



Attachment: signature.asc
Description: PGP signature

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

Reply via email to