[as wg-member]
I've finally gotten a chance to review this.. Sorry for taking so long.
(1) I may be outside rough consensus on wanting to mandate a upgrade path, which is
unfortunate. I think we could advertise an "MP-TLV accepted" capability and not
process implicit MP-TLVS locally unless everyone advertised that capability. The
push-back here seems to be it could break ill-defined but currently fragile-functioning
networks.
Putting that aside...
The document talks about what the operator should and should not do. The
routing capability at least allowed for easily reporting to the operator that
not all routers supported the MP-TLV when it was enabled on the local router.
Yes, b/c we aren't going to automatically change the decision process based on
this capability (1), it could be seen as management info only, which normally
is not advertised in the link-state; however, one could also consider it part
of the decision process b/c it invokes the deploy-human function to manually
repair the now possibly broken decision process.
If we don't have the "MP-TLV accepted" Router Capability then we should at least mandate
some query-able state on the local router to indicate if MP-TLV will be understood and processed
correctly (i.e., "accepted").
We should have a MUST that requires implementations to provide a configuration to
suppress MP-TLV advertisement, and maybe an additional "dont't accept" config
(i.e., use the default of treating repeated keys as replacements). The document in
directing operators relies on these being there but doesn't require them currently.
Thanks,
Chris.
[as wg-member]
Tony Li <[email protected]> writes:
Hi all,
This is an update on the multi-part TLV draft.
This irons out the nits in the previous version and removes the
capability advertisement.
Comments or questions?
Tony
Begin forwarded message:
From: [email protected]
Subject: New Version Notification for
draft-pkaneria-lsr-multi-tlv-02.txt
Date: November 30, 2022 at 10:49:51 AM PST
To: "Antoni Przygienda" <[email protected]>, "Chris Bowers" <
[email protected]>, "Les Ginsberg" <[email protected]>, "Parag
Kaneriya" <[email protected]>, "Shraddha Hegde" <
[email protected]>, "Tony Li" <[email protected]>, "Tony
Przygienda" <[email protected]>
A new version of I-D, draft-pkaneria-lsr-multi-tlv-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.
Name: draft-pkaneria-lsr-multi-tlv
Revision: 02
Title: Multi-part TLVs in IS-IS
Document date: 2022-11-30
Group: Individual Submission
Pages: 9
URL: https://www.ietf.org/archive/id/
draft-pkaneria-lsr-multi-tlv-02.txt
Status: https://datatracker.ietf.org/doc/
draft-pkaneria-lsr-multi-tlv/
Htmlized: https://datatracker.ietf.org/doc/html/
draft-pkaneria-lsr-multi-tlv
Diff: https://www.ietf.org/rfcdiff?url2=
draft-pkaneria-lsr-multi-tlv-02
Abstract:
New technologies are adding new information into IS-IS while
deployment scales are simultaneously increasing, causing the
contents
of many critical TLVs to exceed the currently supported limit
of 255
octets. Extensions exist that require significant IS-IS
changes that
could help address the problem, but a less drastic solution
would be
beneficial. This document codifies the common mechanism of
extending
the TLV content space through multiple TLVs.
The IETF Secretariat
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
