Hi,
I prefer the term 'incremental deployment', i.e., everything works if you
upgrade the network one node at a time.
Irregardless, I think Les and others have done a good job of explaining why the
subject draft is the best way forward for any number of reasons and I support
its adoption. As
Huaimo -
You don't provide an operational definition of how to determine whether "all
nodes need to have the same new information", but it is easy to come up with
cases where this is needed.
Parag described one below and I have previously described one related to Flex
Algo.
I have yet to see
Huaimo –
THis discussion seems to be getting less and less meaningful – but I will
respond.
Regarding IID-TLV, thanx for pointing out that this is another case where the
use of MP has been explicitly stated.
Regarding RFC 5311 and TLV 22/23, the reason that TLV 23 was defined is because
The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Area Proxy for IS-IS'
as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
Legacy node gets half information result in the inconsistent view of network
(for example TED [traffic engineering database] inconsistency lead to many
network related issue.) hence legacy node getting half information is not
backward consistent.
Juniper Business Use Only
From: Huaimo Chen
Hi Hannes,
Thanks for pointing this out:
> On Dec 7, 2023, at 4:38 AM, Hannes Gredler
> wrote:
>
> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I
> am not aware
> of any questions from implementators around ambiguity.
I checked RFCs 8665 and 8666, and they
Hi Les,
Your definition of backwards compatibility means that protocol extensions
can be advertised and safely used in the presence of legacy nodes (which do not
understand the new advertisements).
Protocol extensions for Big-TLV include a new TLV (called container TLV) and a
new Sub-TLV
Hi Tony,
Thank you for your reply.
My responses are inline below with [HC2].
Best Regards,
Huaimo
Huaimo, first, I fail to see how 8202 has anything to do with this discussion.
[HC2]: RFC 8202 defines Instance Identifier TLV (IID-TLV for short), which has
TLV type 7. When IID-TLV > 255 (i.e.,
The following errata report has been verified for RFC8667,
"IS-IS Extensions for Segment Routing".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7722
--
Status: Verified
Type: Editorial