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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 3 Dec 2021 15:51:46 +0000

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

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 3 Dec 2021 16:14:20 +0000

Hey Acee

  1.  Will do
  2.  I look @ your suggested changes for sure. Generally, I think starting to enumerate “cases” will be far more confusing since it’s easier to implement “rules” rather than try to figure out how the cases are supposed to work. Hence normative rules are given. If you think we need more “MUST” tell me.
  3.   Per spec it can, I don’t know any major commercial implementations that would allow that but for completeness sake it’s included & don’t forget the routers “in the middle” are L1 only so it’s entirely viable to partition the area for L2 purposes by setting bunch overload bits on the “routers in the middle L1 only”

--- tony

From: "Acee Lindem (acee)" <[email-masked]>
Date: Friday, 3 December 2021 at 16:55
To: Antoni Przygienda <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: 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:

Thanks,
Acee

Juniper Business Use Only

---

From: Shraddha Hegde <[email-masked]>
Date: Tue, 7 Dec 2021 06:24:02 +0000

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 <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda <[email-masked]>
Cc: [email-masked]
Subject: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-06

Speaking as WG member:

  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

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

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 7 Dec 2021 16:44:41 +0800

Hi, Shraddha:

For large L2 networks, the solution
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-ttz is more
suitable.

For CLOS topology that is used to connect disjoint L2 area, as that
described in
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-01, the
area proxy solution is more straightforward. 

Is there any other scenario that the flood reflection solution be applied?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Shraddha
Hegde
Sent: Tuesday, December 7, 2021 2:24 PM
To: Acee Lindem (acee) <acee=[email-masked]>; Antoni Przygienda
<[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] WG Last Call for "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflection-06

This is a very useful feature for large L2 networks and I support the
publication of this

document.

 

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

I am imagining, this cluster-id mechanism can be used to segregate a single
fabric

which is fine but too restrictive statements like above would discourage
further

3.

   TLV"

   first sub-TLV is not deterministic as multiple TLV 242 can come is
different fragments.

   4.

   terminology should be added to the glossary. These terms are used in sec
4.3

   

   5. section 4.3

   C bit in Flood Reflection Discovery Sub-TLV. The ones with C bit set are
possible shortcut endpoints.

   

   (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.

   8. sec 4.4

   limiting."

   9.

   "If the clients have a

   tunnel."

   adjacencies. "

 

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of
Acee Lindem (acee)
Sent: Friday, December 3, 2021 9:22 PM
To: Antoni Przygienda <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [Lsr] WG Last Call for "IS-IS Flood Reflection"
-draft-ietf-lsr-isis-flood-reflection-06

Speaking as WG member:

2.       Section 5.2 is a bit hard to read. I have some suggested changes in
my

          Your call though.

3.       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

Thanks,

Acee

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 7 Dec 2021 12:03:55 +0100

> fully disjoint. I would suggest to remove the R10->R11 link to show a pure

1. well, it's ASII. I'll redraw for the thing to look maybe more
straightforward thought it may lead
more folks astray to think it's a CLOS.

The link R10-R11 is there on purpose, this is NOT a CLOS and flood
reflection is not restricted by any
topology constraints. I drew it CLOS like since that's what lots people
do/start to do, thinking about
it I probasbly change the picture for the thing to be much less CLOS like
;-)

10-11 and 11-12 are there on purpose to show L2 leaf shortcuts.

> Do we really need this restriction of one single cluster-id on a router?

For operational simplicity very much so. For future possible things, maybe
not but introducing
multiple cluster IDs in same area and possibly same cluster ID in different
areas leads to all
kind of corner cases & configuration complications because cluster ID
becomes de facto
a property of an interface (or have to carry a set of possible Cluster IDs
and that leads to
"negotiation" scenarios with additional complications in case of dynamic
tunnel establishment).
We don't have in ISIS areas "per interface" for the same reason
as we should not have a cluster ID per interface. Yes, some vendors support
"multiple"
areas per router but we know it's used only for merge/split and is a whole
dance to get it right
during transitions.

Having said that, if enough people feel that way we _should_ move the MUST
to a SHOULD
I think it's livable and then let's hope some clever vendors can try to
support multiple cluster IDs if they find an operationally
acceptable way.

> enhancements so may be worth considering these restrictions to be removed.

as said above, I'm ok with a SHOULD but generally all the procedures
described & formats
stay at a single cluster ID.

>    TLV of the lowest numbered fragment"

ok, thanks. good one.

>    and reader may not get the context of these terms.

ok, will add. thanks for comment.

>    The ones with C bit cleared are the flood reflector tunnel endpoints.

nope, we can't since clients may have different endpoints for the FR tunnel
& for the shortcut tunnels so
whoever originates the tunnel has to be sure they shortcut to the correct
endpoint.

> absence of flood reflectors.

as per 5. the bit is needed.

>    This text as well as next para needs revision.

yes, thanks. will clarify. the cluster ID match is also a good one albeit
it seems
logical given adjacency restrictions.

>    MUST use first sub-TLV from lowest numbered fragment.

yes, good catch again here.

>    " A router acting as a flood reflector MUST NOT have any traditional L2

well, it probably slipped by you that clients can have shortcut in L2
client-2-client so
there is no contradiction.

But yes, good observation as to client-reflector rule. I clarify that a
flood reflector
SHOULD use a direct L2 interface adjacency to a client if it has one rather
than a tunnel.

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 9 Dec 2021 12:43:01 +0100

comments addressed and new version posted

-- tony

On Tue, Dec 7, 2021 at 7:24 AM Shraddha Hegde <shraddha=
[email-masked]> wrote:

> *From:* Lsr <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, December 3, 2021 9:22 PM
> *To:* Antoni Przygienda <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [Lsr] WG Last Call for "IS-IS Flood Reflection"
> *[External Email. Be cautious of content]*
>
>
>
> Speaking as WG member:
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>