Chris – Indeed – welcome to the forum. The concept of area address in IS-IS has confused many – including folks with a much longer history than you.
Please see inline. From: Chris Parker <[email protected]> Sent: Tuesday, February 14, 2023 2:16 AM To: Shraddha Hegde <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem <[email protected]>; [email protected] Subject: Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo 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.) [LES:] For the purposes of IS-IS, everything to “the left” of the system-id should be considered part of the area address. So “49” is indeed part of the area address in your examples. 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, [LES:] The scope is determined by the state of the “S-bit” in the enclosing Router Capability TLV. It is up to the router who originates the advertisement to set the scope as desired and up to the L1L2 routers who receive it to honor the scope request and perform leaking as appropriate. An L1 router can originate an advertisement and specify that it should be flooded domain-wide (S-bit set). It is then the responsibility of the L1L2 routers in the same area to leak the advertisement into the L2 sub-domain (still with S-bit set) and up to L1L2 routers in other areas to leak the advertisement downwards into their L1 areas (with S-bit and D-bit set). 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. [LES:] No – this is not possible. A router can be in one – and only one – L1 area. IS-IS does have the concept of “synonymous areas”. For example, consider the simple topology: A----B On A we have the following area addresses configured: 49.0001 On B, we have the following area addresses configured: 49.0001 49.0002 On the link A—B, the adjacency formed can support Level 1 because ISO 10589 requires only that there be at least one area address in common. The area then has two synonymous area addresses – it is NOT two different areas. If B were an L1L2 router connected to C – who has area address 49.0003 configured, - B and C would form an L2 only adjacency (no area address in common) and B would announce the set of “computed area addresses” as (49.0001, 49.0002) in its L2 LSPs, indicating that there are two synonyms for its L1 area. In the context of IP/IPv6 routing, synonymous area addresses are only useful when one is preparing to collapse two areas into one or preparing to split one area into two. 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. [LES:] There are three meaningful flooding scopes in base IS-IS (let’s not worry about additional scopes introduced by other protocol extensions – such as RFC 7356 - in this discussion): 1)Area scope 2)L2 sub-domain scope 3)Domain-wide scope (All areas and the L2 sub-domain) Area can be thought of equivalent to level 1 in base IS-IS, but if one extends the protocol to greater levels of hierarchy (e.g., as proposed in https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/ ) then area is no longer equivalent to level-1. So, I think it is still quite useful to retain the notion of area. Hope this discussion hasn’t been too obscure. Les 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, February 14, 2023 2:26 AM To: Acee Lindem <[email protected]<mailto:[email protected]>>; Chris Parker <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> On Behalf Of > Acee Lindem > Sent: Monday, February 13, 2023 12:15 PM > To: Chris Parker <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]> > 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 > > <[email protected]<mailto:[email protected]>> > 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 > > [email protected]<mailto:[email protected]> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls> > > r__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDh > > zuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$ > > _______________________________________________ > Lsr mailing list > [email protected]<mailto:[email protected]> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_> > _;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPT > zcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$ _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HBc_idYdlO5aWVAVEVX1LRxYrDu_445eISaA4KmlFc4JtucPDhzuPTzcXChYX4Zjpc8NSYtp5Hkb0-bbx1BHCi2QTEYt6aW5$>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
