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) <[email protected]>
Sent: Sunday, November 5, 2023 10:30 PM
To: Huaimo Chen <[email protected]>; [email protected]
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 <[email protected]<mailto:[email protected]>> On Behalf Of
Huaimo Chen
Sent: Sunday, November 5, 2023 11:34 AM
To: [email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
