Re: [Last-Call] Last Call: <draft-ietf-lsr-isis-flood-reflection-10.txt> (IS-IS Flood Reflection) to Experimental RFC

[tom petch <[e-mail]>]

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
> [e-mail] mailing lists by 2022-10-10. Exceptionally, comments may
> be sent to [e-mail] 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>