Huaimo –
I am still not convinced you have understood the problem. Let me make one more
attempt.
Node A is currently advertising 255 bytes of information about a link.
A configuration change is made on that node requiring it to also advertise
unidirectional link delay (sub-TLV 33). This link attribute is used by a
flex-algo already deployed in the network.
All nodes in the network support the use of link delay by flex algo.
But all nodes do NOT support receiving more than 255 bytes about a given link.
There is no backwards compatible way to address this requirement.
If you send more than 255 bytes (whether by a second TLV or by BIG-TLV) some
nodes in the network will not correctly process it and operation of the
flex-algo which requires that information will be compromised.
If you don’t send the additional information, again – operation of the
flex-algo which requires that information will be compromised because now all
the nodes do not have the delay advertisement associated with that link.
There is no middle ground where only the nodes which support sending/receiving
of more than 255 bytes use the additional information and the affected
flex-algo still works.
Reading your response a second time, it suggests to me that you think
advertising some new “capability” will allow you to safely deploy advertising
more than 255 bytes.
I “think” the idea you propose (though I had difficulty parsing your text –
particularly since your draft does not even suggest this – so maybe this isn’t
what you are trying to say) is that a new capability advertisement could be
used to indicate whether a node supports sending/receiving more than 255
bytes/object. Nodes could then send more than 255 bytes/object if they need to
do so, but would be restricted from actually using advertisements in the
BIG-TLV unless all nodes in the network indicate they support this capability.
Is this what you are trying to say?
If so, this doesn’t provide “backwards compatibility”. The +255 advertisements
still can’t be used unless all nodes explicitly indicate support. I am
speculating that you are arguing this addresses “unpredictability”.
But, for this to be useful we have look at the larger issues. The need for
advertising more than 255 bytes/object arises because of the configuration of
features on routers in the network. It is not done simply because an
implementation has the capability of doing it.
If we advertise more than 255 bytes/object, but only use the first 255 bytes
(based on the state of capability advertised in the network), for this to be
useful we would need to introduce a set of criteria to determine what
attributes get advertised in the “first 255 bytes” and which ones are placed in
the subsequent set of advertisements. This could allow (to take a simple
example) the attributes needed for flex-algo 128 to be advertised in the “first
TLV”, but the attributes needed for flex-algo 129 to be advertised in the
“second TLV”. Theoretically this could allow flex-algo 128 to work – but
compromise the functionality of flex-algo 129.
But such a scheme is extremely complex – as well as dynamic. Priorities could
change as features are configured/deconfigured. And, of course, the priorities
would need to be set consistently on all nodes in the network – which begs for
an entirely new signaling of “feature priorities” by nodes. This would place
new requirements on LSP generation – where the advertisement of a given piece
of information would no longer depend solely on where space in a TLV/LSP is
available, but also on this new prioritization. And the Decision process would
be constrained in new ways – it would be required to ignore valid information
received from reachable nodes based on the state of +255 byte/object support.
And at least some of the features configured still would not work – so the
state of the network is not what was intended. All of this complexity does not
result in a working network.
I don’t find this idea practical or desirable.
(Apologies if I misinterpreted your proposal – but it was the only
interpretation that made sense to me. 😊 )
Les
From: Huaimo Chen <huaimo.c...@futurewei.com>
Sent: Sunday, November 5, 2023 3:06 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org
Subject: RE: draft-chen-lsr-isis-big-tlv
Hi Les,
Thank you very much for your responses.
draft-chen-lsr-isis-big-tlv resolves the issue: unpredictable behavior with
partial deployment, which are stated in both IETF 117 and IETF 118 slides. I
explained this in detail in my previous email.
For the existing Sub-TLVs in a TLV > 255, the solution in
draft-chen-lsr-isis-big-tlv is also backwards compatible. For a piece of new
information in existing Sub-TLVs, when adding this new information into a TLV
makes the TLV > 255, this new information in existing Sub-TLVs can be put into
a container TLV. If all the nodes need to have the same new information for
using the new information, every node needs to check if all the nodes support
the capability which is distributed by the nodes supporting it. If all nodes
support it, every node uses the new information. If it is not required that all
the nodes must have the same new information for using the new information, the
nodes supporting the capability can use the new information, the nodes not
supporting the capability ignore the new information.
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Sent: Sunday, November 5, 2023 10:30 PM
To: Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>;
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: RE: draft-chen-lsr-isis-big-tlv
Huaimo –
Thanx for bringing this up. Resolving this before the meeting hopefully will
save us time during the meeting.
“Backwards compatibility” is possible in situations where new advertisements
are being introduced and the legacy nodes either:
* Don’t need to process the new advertisements or
* There are existing advertisements (in a different format) that contain
the same information
Neither is the case here.
The problem being discussed is how to handle cases where the deployment
requires more than 255 bytes of existing (sic) advertisements about a
particular object.
For example, there are cases today where the total amount of information about
a link (link endpoint identifiers, bandwidth, delay, affinity, adjacency-sids,
etc.) exceeds 255 bytes. This is not because new sub-TLVs are being introduced
– it is because the sum total of the existing sub-TLVs required in a given
deployment exceeds 255 bytes.
All nodes in the network have to understand and process all of the sub-TLVs
being advertised. There is no subset which is sufficient for “legacy nodes” and
there is no existing way to advertise more than 255 bytes in a single TLV.
This problem therefore cannot be addressed in a backwards compatible way.
The solution defined in draft-pkaneria-lsr-multi-tlv is consistent with
existing behavior explicitly defined for some TLVs (see
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-introduction
).
Could the problem be addressed by “Big-TLV”? Yes – but there are multiple
reasons why this is not a good choice:
1)It introduces inconsistency – some TLVs would use multiple native TLVs to
deal with the issue (as per existing RFCs) – and some TLVs would use a native
TLV plus Big-TLV. As there is no advantage to Big-TLV this simply adds
ambiguity with no benefits.
2)There are multiple existing implementations which have already been
successfully deployed and proven interoperable using the solution discussed in
draft-pkaneria-lsr-multi-tlv. Declaring that solution as invalid would set the
industry back and require all implementations to start from scratch since no
implementation today supports Big-TLV.
3)As BIG-TLV is a generic container TLV, it is inherently less efficient as it
consumes bytes in the encapsulation.
Your main argument for Big-TLV has been the mistaken claim that it is
“backwards-compatible”. Hopefully you now understand that this is not the case
and we need not debate this further.
Les
From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of
Huaimo Chen
Sent: Sunday, November 5, 2023 11:34 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] draft-chen-lsr-isis-big-tlv
Hi Les,
In last IETF, you presented/stated that Backwards compatibility is not
possible. This seems not true. The solution proposed in
draft-chen-lsr-isis-big-tlv is backwards compatible. Can you give your
definition of backwards compatibility?
In this IETF and last IETF, the slides states that With partial deployment
behavior is unpredictable. This seems resolved by draft-chen-lsr-isis-big-tlv.
A container TLV is used by a node to contain a piece of new information. The
nodes that do not support the capability of container TLV will ignore container
TLVs. This will resolve unpredictable behavior with partial deployment.
Best Regards,
Huaimo
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
