Thank you to all who replied for your consideration, and thank you to Acee for the kind welcome!
In regards the idea to change the wording to "The IS-IS FAD Sub-TLV has an area/level scope", I personally think that any mention of the word "area" in regards to IS-IS flooding could still be a source of confusion. I'll expand the example in my previous mail, in case it's helpful. Imagine a theoretical level 2 topology which contains a few hundred routers. - Some routers are in area 49.0001 - Some routers are in area 49.0002 - Some routers are in area 49.0003 - Some routers are in area 49.0004 (I know "49" is not strictly speaking part of the area identifier, but I've included it in the example just for clarity.) If a router in area 49.0002 were to generate the IS-IS FAD Sub-TLV, I believe the intended delivery scope is "all routers in the same level as the original sender", regardless of the area the router is in. It's the level that defines the flooding scope, not the area. So for example, L2 routers in area 49.0004 should receive this sub-TLV, Even if we were to talk about level 1, it is possible for an L1 router to be in two IS-IS areas at once, which is a way of creating a single L1 topology, a single LSP flooding domain. With all that in mind, hopefully it's a bit clearer why I worry about any mention of the word "area" in IS-IS when it comes to describing flooding scope, and why I feel that the wording "has an area/level scope" still has the potential to cause confusion. As a reader, I would wonder whether the implementer has a choice in the scope. The intention would not be explicitly clear to me. The word "area" has a slightly different meaning in IS-IS than it does in OSPF. Hopefully that explanation is helpful. I'm very aware that I'm a newcomer talking to people far more knowledgeable than me about things like this, so I hope you'll forgive me if it turns out I'm mistaken. All the best Chris On Tue, Feb 14, 2023 at 4:00 AM Shraddha Hegde <shrad...@juniper.net> wrote: > I prefer changing the sentence to > " The IS-IS FAD Sub-TLV has an area/level scope" > > Rgds > Shraddha > > > Juniper Business Use Only > > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg (ginsberg) > Sent: Tuesday, February 14, 2023 2:26 AM > To: Acee Lindem <acee.i...@gmail.com>; Chris Parker < > ch...@networkfuntimes.com> > Cc: lsr@ietf.org > Subject: Re: [Lsr] Two small potential typing errors in > draft-ietf-lsr-flex-algo > > [External Email. Be cautious of content] > > > Disclaimer: I am not an author of the flex-algo draft. > > However, the text regarding "scope" of the FAD sub-TLV is in the context > of the flooding scope of the containing Router Capability TLV (as defined > in RFC 7981). > There we have two scopes defined: > > 1)Area/level scope (S-bit clear) > > Such information MUST NOT be leaked between levels > > 2)Domain-wide scope (S-bit set) > > Such information MUST be flooded across the entire IS-IS flooding domain - > which means it is leaked between levels (UP and DOWN as appropriate) > > Both "area/level" and "domain-wide" are terms used in RFC 7981. > > The full paragraph from the flex-algo draft reads: > > "The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV in > which the FAD Sub-TLV is present MUST have the S-bit clear." > > I think this is correct - but if the authors wanted to update this to > "area/level" I would not object. > > Les > > > -----Original Message----- > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem > > Sent: Monday, February 13, 2023 12:15 PM > > To: Chris Parker <ch...@networkfuntimes.com> > > Cc: lsr@ietf.org > > Subject: Re: [Lsr] Two small potential typing errors in > > draft-ietf-lsr-flex-algo > > > > Hi Chris, > > > > > On Feb 13, 2023, at 2:56 PM, Chris Parker > > > <ch...@networkfuntimes.com> > > wrote: > > > > > > Hi all, > > > > > > First time poster here. Sincere apologies if I make any mistakes in > > etiquette. I work at Juniper, and am mailing on suggestion of Shraddha > > Hegde, after a conversation about draft-ietf-lsr-flex-algo. > > > > > > Having read the draft, I think I've found two tiny things to fix. > > > > > > The first is a typo: In the text "The following values area > > > allocated by IANA > > from this registry for Flex-Algorithms", I think it should say "are", > not "area”. > > > > This is definitely a typo. > > > > > > > > The second is a point of clarification in the text "The IS-IS FAD > > > Sub-TLV has > > an area scope". I think perhaps this should be "level scope", not > > "area scope". > > > > I can’t seem to find similar IS-IS terminology. I’ll defer to the > authors. > > However, you’d be correct for OSPF. > > > > > > > > For example, imagine a level 2 backbone that contains four areas. I > > > would > > imagine the intended behavior is actually to flood this sub-TLV > > through the entire level 2 backbone, rather than just to the other > > routers in the particular area that the originator happens to reside in? > > > > > > Hopefully these are useful changes. Apologies once again if I've > > > made any > > errors in this process. > > > > Speaking as WG Co-Chair - This is definitely the right process and we > > look forward to your future reviews of LSR documents!!! > > > > Thanks, > > Acee > > > > > > > > > > Best regards > > > Chris Parker > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls > > > r__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDh > > > zuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$ > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPT > > zcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$ > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$ >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr