Re: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

comments addressed and new version posted

-- tony

On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde <shraddha=
40juniper.net@dmarc.ietf.org> wrote:

> This is a very useful feature for large L2 networks and I support the
> publication of this
>
> document.
>
>
>
>
>
> I have below nits/suggestions on the document.
>
>
>
>
>
> 1. Figure 1: Example Topology of L1 with L2 Borders
>
> The diagram is not legible. The connections between L1 routers
>
> can be removed from the diagram and a description can be added that
>
> R1 layer routers are all connected to R2 layer and so on.
>
> From the diagram it appears that there is connectivity between R10 and R11
>
> and R11 and R12. If so that link can flood L2 domains and L2 is not
>
> fully disjoint. I would suggest to remove the R10->R11 link to show a pure
> clos topology
>
> in L1.
>
>
>
> 2.
>
> 4.1 Flood reflection TLV
>
> "On a given router, the same value
>
>       of the Flood Reflection Cluster ID MUST be advertised across all
>
>       interfaces advertising the Flood Reflection TLV in IIHs. "
>
>
>
> Do we really need this restriction of one single cluster-id on a router?
>
> I am imagining, this cluster-id mechanism can be used to segregate a
> single fabric
>
> into two or more clusters if the fabric size becomes too huge.
>
> The usecase itself is described out of scope for this document elsewhere
>
> which is fine but too restrictive statements like above would discourage
> further
>
> enhancements so may be worth considering these restrictions to be removed.
>
>
>
> 3.
>
> 4.2.  Flood Reflection Discovery Sub-TLV
>
> " A router receiving multiple Flood Reflection
>
>    Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>    TLV"
>
>
>
>    first sub-TLV is not deterministic as multiple TLV 242 can come is
> different fragments.
>
>    Suggest to change as below.
>
>    " A router receiving multiple Flood Reflection
>
>    Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
>
>    TLV of the lowest numbered fragment"
>
>
>
>    4.
>
>    "flood reflection tunnel endpoint" and "L1 shortcut"
>
>    terminology should be added to the glossary. These terms are used in
> sec 4.3
>
>    and reader may not get the context of these terms.
>
>
>
>
>
>
>
>    5. section 4.3
>
>
>
>    do we need the F bit? Looks like this info can be derived from the
>
>    C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set
> are possible shortcut endpoints.
>
>    The ones with C bit cleared are the flood reflector tunnel endpoints.
>
>
>
>
>
>    6. The tunnel encapsulation attribute has use outside of flood reflector
>
>    (such as RFC 8663). I am more in favor of getting rid of the F bit from
> this sub-TLV
>
>    as to avoid the confusions that may arise when it is used in the
> absence of flood reflectors.
>
>
>
>    7.
>
>    " A flood reflector receiving multiple Flood Reflection Discovery
>
>    Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
>
>    flag set SHOULD use one or more of the specified tunnel endpoints to
>
>    automatically establish one or more tunnels that will serve as flood
>
>    reflection adjacency(-ies)."
>
>
>
>    A flood reflector should establish tunnels with clients only and not
> with
>
>    other flood reflectors. also the cluster id needs to match.
>
>    This text as well as next para needs revision.
>
>
>
>    8. sec 4.4
>
>
>
>    "The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than
>
>    once in a given TLV.  A router receiving multiple Flood Reflection
>
>    Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV
>
>    and it SHOULD adequately log such violations subject to rate
>
>    limiting."
>
>
>
>    IMO should talk abt possibility of same TLV 22 in multiple fragments
> and
>
>    MUST use first sub-TLV from lowest numbered fragment.
>
>
>
>    9.
>
>
>
>    "If the clients have a
>
>    direct L2 adjacency they SHOULD use it instead of instantiating a new
>
>    tunnel."
>
>
>
>    above statement seems to contradict statement below in sec 4.5
>
>    " A router acting as a flood reflector MUST NOT have any traditional L2
>
>    adjacencies. "
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, December 3, 2021 9:22 PM
> *To:* Antoni Przygienda <prz@juniper.net>
> *Cc:* lsr@ietf.org
> *Subject:* [Lsr] WG Last Call for "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-06
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as WG member:
>
>
>
> I have already supported publication. I have a couple comments:
>
>
>
>    1. Can you add “leave” to the glossary in section 2?
>    2. Section 5.2 is a bit hard to read. I have some suggested changes in
>    my
>
> editorial comments but it would be good to expand the cases into smaller
>
> chunks and make state the overall goals ahead rather than after the
> details.
>
>           Your call though.
>
>    1. In section 7, would an IS-IS router really set the overload-bit in
>    L1 but not L2?
>
>
>
>
>
> I’ve also attached some suggested editorial changes. Some of these are
> very subjective
>
> and I won’t feel bad if you don’t include them all.
>
>
>
> Thanks,
>
> Acee
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>