Re: [Lsr] [Technical Errata Reported] RFC9346 (7348)

[Chris Smiley]

Greetings,

FYI - this report has been deleted as junk.

Thank you.

RFC Editor/cs


> On Feb 14, 2023, at 10:06 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC9346,
> "IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS 
> Traffic Engineering".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7348
> 
> --
> Type: Technical
> Reported by: a 
> 
> Section: glober
> 
> Original Text
> -
> i
> 
> Corrected Text
> --
> i
> 
> Notes
> -
> i
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC9346 (draft-ietf-lsr-isis-rfc5316bis-07)
> --
> Title   : IS-IS Extensions in Support of Inter-Autonomous System 
> (AS) MPLS and GMPLS Traffic Engineering
> Publication Date: February 2023
> Author(s)   : M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong
> Category: PROPOSED STANDARD
> Source  : Link State Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Aijun Wang]

Hi, Les:As I remembered, https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/  will not be forwarded, and the proposed hierarchy within ISIS is not practical.Then, it seems that we can still treat area same as the level 1.  It’s the time to reduce the confusion?Aijun WangChina TelecomOn Feb 15, 2023, at 00:32, Les Ginsberg (ginsberg)  wrote:







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  
Sent: Tuesday, February 14, 2023 2:16 AM
To: Shraddha Hegde 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr@ietf.org
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:
 
AB
 
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 

[Lsr] [Technical Errata Reported] RFC9346 (7348)

[RFC Errata System]

The following errata report has been submitted for RFC9346,
"IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS 
Traffic Engineering".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7348

--
Type: Technical
Reported by: a 

Section: glober

Original Text
-
i

Corrected Text
--
i

Notes
-
i

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC9346 (draft-ietf-lsr-isis-rfc5316bis-07)
--
Title   : IS-IS Extensions in Support of Inter-Autonomous System 
(AS) MPLS and GMPLS Traffic Engineering
Publication Date: February 2023
Author(s)   : M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Les Ginsberg (ginsberg)]

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 
Sent: Tuesday, February 14, 2023 2:16 AM
To: Shraddha Hegde 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem 
; lsr@ietf.org
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:

AB

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 
mailto:shrad...@juniper.net>> wrote:
I prefer 

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Aijun Wang]

What’s the reason to keep area in the description? Is there any flooding activities that based on area?I suggest also remove the mention of area in these descriptions.Aijun WangChina TelecomOn Feb 14, 2023, at 18:16, Chris Parker  wrote: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 bestChrisOn Tue, Feb 14, 2023 at 4:00 AM Shraddha Hegde  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  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, February 14, 2023 2:26 AM
To: Acee Lindem ; Chris Parker 
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  On Behalf Of Acee Lindem
> Sent: Monday, February 13, 2023 12:15 PM
> To: Chris Parker 
> 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 
> > 
> 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 

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Chris Parker]

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  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  On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, February 14, 2023 2:26 AM
> To: Acee Lindem ; 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  On Behalf Of Acee Lindem
> > Sent: Monday, February 13, 2023 12:15 PM
> > To: Chris Parker 
> > 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
> > > 
> > 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
> >