Hi Tom,
On 9/28/22, 5:41 AM, "tom petch" <daedulus@xxxxxxxxxxxxx> wrote:
On 26/09/2022 18:02, The IESG wrote:
>
> The IESG has received a request from the Link State Routing WG (lsr) to
> consider the following document: - 'IS-IS Flood Reflection'
> <draft-ietf-lsr-isis-flood-reflection-10.txt> 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
> last-call@xxxxxxxx mailing lists by 2022-10-10. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
I am confused by s.8.3 as introduced at AD Review for IANA Considerations.
It specifies a new registry with a name that starts 'Sub-sub TLVs for
Flood....''under the "IS-IS TLV Codepoints" Grouping.
Here is the grouping of related registries. Maybe the confusion is that since it is multiple registries, it doesn't show up as a link in https://www.iana.org/protocols
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints
Thanks,
Acee
Grouping is not a term I recognise. IANA have just responded to a Last
Call comment on dnsop-dnssec-bcp to clarify that the preferred
terminology is registry and registry group; I cannot recall seeing
'grouping' being used.
Further, I cannot see IS-IS TLV Codepoints in any form.
IS-IS is one of those rare protocols whose IANA registry are all
together under a group with an obvious name so while this I-D does not
mention the group name, it is one of those rare cases when that should
not be a problem.
Second, there are several existing registry of Sub-Sub TLVs so Sub-Sub
would seem better - I do note that RFC8401 which created Sub-Sub-TLVs
for BIER uses sub-sub!
But the significant point is that I do not understand the reference in
the Registration Procedures to common expert review guidance for the
grouping since I do not know what is meant by a grouping.
Tom Petch
>
> Abstract
>
>
> This document describes a backward-compatible, optional IS-IS
> extension that allows the creation of IS-IS flood reflection
> topologies. Flood reflection permits topologies in which L1 areas
> provide transit forwarding for L2 using all available L1 nodes
> internally. It accomplishes this by creating L2 flood reflection
> adjacencies within each L1 area. Those adjacencies are used to flood
> L2 LSPDUs and are used in the L2 SPF computation. However, they are
> not ordinarily utilized for forwarding within the flood reflection
> cluster. This arrangement gives the L2 topology significantly better
> scaling properties than traditionally used flat designs. As an
> additional benefit, only those routers directly participating in
> flood reflection are required to support the feature. This allows
> for incremental deployment of scalable L1 transit areas in an
> existing, previously flat network design, without the necessity of
> upgrading all routers in the network.
>
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/
>
>
> The following IPR Declarations may be related to this I-D:
>
> https://datatracker.ietf.org/ipr/4186/
> https://datatracker.ietf.org/ipr/5807/
>
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
