Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Hi Les,

> [Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
> have to be configured with the Area Prefix and associated SID.


The Area Leader may not be an IER.  In fact, in an important use case for us, 
the area is a leaf-spine topology.  The Area Leader is one of the spines.  The 
leaves are the edge routers.  For resource reasons, we do NOT want the Area 
Leader to be a leaf.


We do NOT require that the Area Leader candidates have identical 
configurations.  In fact, if there is a configuration change, it may be 
beneficial to configure one candidate differently and then raise its priority.  
It’s a simple way of effecting an area-wide configuration change.  

> Perhaps you are allowing that each IER could choose a different Area 
> Prefix/SID. Not sure why you would want to do that – but even if you did, the 
> behavior of the winning prefix/SID is analogous to an anycast address.
> The difference here is that the advertisement of the Prefix Reachability 
> associated with the area prefix is within the Proxy LSP – which appears to 
> OERs as if it was originated by all of the IERs i.e., the set of IERs appears 
> as a single node to the OERs. Still, all IERs are aware of the winning prefix 
> reachability advertisement and will do what is required in forwarding based 
> on that content.


They will not be aware of it unless we tell them via the Area Proxy TLV.  For 
obvious reasons, the Inside Nodes do NOT do anything with the Proxy LSP other 
than flood it.


> Which is why we’re using the Prefix SID.
>  
> [Les:] You are using the prefix-SID, but the advertisement is not associated 
> with a prefix reachability  advertisement, yet you want nodes to install 
> forwarding entries based on this advertisement. This is what seems 
> inappropriate.


We want outside nodes to install forwarding entries on the Prefix SID.  This is 
entirely backward compatible.  How is that inappropriate?


> The only current case where a prefix-SID is advertised and is NOT associated 
> with prefix reachability is in the Binding TLVs. This has two use cases:
> Advertising SIDs for prefixes associated with nodes which are NOT SR capable
> As an alternative to per prefix advertisement if the operator prefers to use 
> a centralized SID assignment service
>  
> In both of these cases if a SID were to be advertised in prefix reachability 
> TLV for the same prefix the SID in the prefix reachability advertisement 
> would be preferred.
> You don’t discuss this at all in the draft i.e., what happens if the SID in 
> the prefix reachability advertisement for the Area Prefix differs from that 
> advertised in the Area Proxy TLV. What I am pushing for is eliminating the 
> need to do so by relying on the existing prefix SID advertisements and not 
> introducing a new one in the Area Proxy TLV.


The existing ones do not have the required semantics.

> [Les:] The semantics you require are functionally equivalent to anycast 
> behavior – which is supported already.


Please point me to anycast semantics that will ONLY be selected by IERs. 

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Inline.

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 5:40 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Les,

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with 
me to get it clarified to your satisfaction.



Also explain why it is necessary for something other than a prefix reachability 
advertisement to cause an entry to be created in forwarding for a prefix – and 
ONLY when received in an L2 LSP?
This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I 
repeat: "There is no other mechanism whereby system A can advertise a prefix 
SID to a number of other systems and have them install receive/POP forwarding 
entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


[Les:] Any one of the IERs can be elected Area Leader, therefore all of them 
have to be configured with the Area Prefix and associated SID.
Perhaps you are allowing that each IER could choose a different Area 
Prefix/SID. Not sure why you would want to do that – but even if you did, the 
behavior of the winning prefix/SID is analogous to an anycast address.
The difference here is that the advertisement of the Prefix Reachability 
associated with the area prefix is within the Proxy LSP – which appears to OERs 
as if it was originated by all of the IERs i.e., the set of IERs appears as a 
single node to the OERs. Still, all IERs are aware of the winning prefix 
reachability advertisement and will do what is required in forwarding based on 
that content.


If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant 
outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.

[Les:] Agreed. Nothing I have asserted suggests otherwise.


My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

[Les:] You are using the prefix-SID, but the advertisement is not associated 
with a prefix reachability  advertisement, yet you want nodes to install 
forwarding entries based on this advertisement. This is what seems 
inappropriate.
The only current case where a prefix-SID is advertised and is NOT associated 
with prefix reachability is in the Binding TLVs. This has two use cases:

  *   Advertising SIDs for prefixes associated with nodes which are NOT SR 
capable
  *   As an alternative to per prefix advertisement if the operator prefers to 
use a centralized SID assignment service

In both of these cases if a SID were to be advertised in prefix reachability 
TLV for the same prefix the SID in the prefix reachability advertisement would 
be preferred.
You don’t discuss this at all in the draft i.e., what happens if the SID in the 
prefix reachability advertisement for the Area Prefix differs from that 
advertised in the Area Proxy TLV. What I am pushing for is eliminating the need 
to do so by relying on the existing prefix SID advertisements and not 
introducing a new one in the Area Proxy TLV.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.


Again, SR does not support the semantics that we require.


[Les:] The semantics you require are functionally equivalent to anycast 
behavior – which is supported already.

   Les


As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony


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

Re: [Lsr] Remind Reply: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Ning So]

 As Co-Author, I support working group adoption of this draft as
experimental.

Ning So

--
> *From:* Lsr  on behalf of Anil Kumar <
> anil.i...@gmail.com>
> *Sent:* Saturday, August 22, 2020 2:10 PM
> *To:* Acee Lindem (acee) 
> *Cc:* lsr@ietf.org 
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
> Hi All,
>
> As Co-Author, I support working group adoption of this draft as
> experimental.
>
> With Regards
> Anil S N
>
> On Tue, Aug 18, 2020 at 7:47 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>
>

-- 
Ning So
972-955-0914
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Les,

> As per the draft:
>  
> Area Proxy TLV is advertised by IERs in their L2 LSP. 
> Area Proxy TLV is NOT advertised in the Proxy LSP.
> So how do the OERs become aware of the 
>  
> “prefix and  SID that represents the entirety of the Inside Area to the 
> Outside  Area”
>  
> ???
>  
> I assume that they learn this because the Proxy LSP (at least) contains a 
> Prefix Reachability TLV with the same prefix/SID that was advertised in the 
> Area Proxy TLV.
> Is this correct? If not, please correct me.


That’s correct.  If this isn’t crystal clear from the draft, please work with 
me to get it clarified to your satisfaction.


> Also explain why it is necessary for something other than a prefix 
> reachability advertisement to cause an entry to be created in forwarding for 
> a prefix – and ONLY when received in an L2 LSP?
> This is unprecedented.



It is unprecedented because there we are proposing something unprecedented.  I 
repeat: "There is no other mechanism whereby system A can advertise a prefix 
SID to a number of other systems and have them install receive/POP forwarding 
entries.”

It is NOT creating forwarding TO a prefix.  It’s reception.


> If I am right, you then have  multiple TLVs which advertise duplicate 
> advertisements – even if not in the same LSP - which exposes you to the 
> problems I mentioned.
> My goal is to have one – and only one – advertisement which creates 
> forwarding state.


Well, I’m sorry, but your goal is unachievable.  The Proxy LSP is only relevant 
outside of the area.  The Inner Node LSPs aren’t circulated outside of the area.


> My second goal is not to invent a new SID type/advertisement when the object 
> associated with it (a prefix) already has a defined SID type.


Which is why we’re using the Prefix SID.

 
> What I object to – and am concerned about – is that you seem to invent your 
> version of SR for Area Proxy even when you use the same object (a prefix) 
> that SR already supports.


Again, SR does not support the semantics that we require. 


> As you know, I was prepared to support a new type of SID when you actually 
> were defining a new object type. The fact that you decided NOT to invent a 
> new object type is fine with me – but please do not claim that you need a new 
> SID type when you don’t.


I’m sorry that you still don’t understand.  We do need something different.

Tony


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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony –

Sigh…

I introduced the term “Area Destination” only as a means of demonstrating that 
this could have been something other than a prefix – as had been proposed in 
earlier versions of the draft. I am not asking you to introduce the term in the 
draft and as it seemed to confuse you I won’t use it any more in this thread.

As per the draft:

Area Proxy TLV is advertised by IERs in their L2 LSP.
Area Proxy TLV is NOT advertised in the Proxy LSP.
So how do the OERs become aware of the

“prefix and  SID that represents the entirety of the Inside Area to the Outside 
 Area”

???

I assume that they learn this because the Proxy LSP (at least) contains a 
Prefix Reachability TLV with the same prefix/SID that was advertised in the 
Area Proxy TLV.
Is this correct? If not, please correct me.  Also explain why it is necessary 
for something other than a prefix reachability advertisement to cause an entry 
to be created in forwarding for a prefix – and ONLY when received in an L2 LSP?
This is unprecedented.

If I am right, you then have  multiple TLVs which advertise duplicate 
advertisements – even if not in the same LSP - which exposes you to the 
problems I mentioned.
My goal is to have one – and only one – advertisement which creates forwarding 
state.
My second goal is not to invent a new SID type/advertisement when the object 
associated with it (a prefix) already has a defined SID type.

What I object to – and am concerned about – is that you seem to invent your 
version of SR for Area Proxy even when you use the same object (a prefix) that 
SR already supports.

As you know, I was prepared to support a new type of SID when you actually were 
defining a new object type. The fact that you decided NOT to invent a new 
object type is fine with me – but please do not claim that you need a new SID 
type when you don’t.

   Les

From: Tony Li  On Behalf Of tony...@tony.li
Sent: Wednesday, August 26, 2020 4:02 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt



Hi Les,


You have chosen to assign a prefix as the “Area Destination”.


Are you sure you have the right document?  The word “Destination” does not 
appear anywhere within 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03



This is fine with me. But having done that, forwarding should be based on the 
existing mechanisms for advertising a prefix and the associated prefix SID.


Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy 
LSP.


If you’re referring to the Area SID advertisement, then there is no existing 
mechanism for advertising that today, that’s why we’re having to create an 
additional subTLV.
There is no other mechanism whereby system A can advertise a prefix SID to a 
number of other systems and have them install receive/POP forwarding entries.



By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don’t (everyone else)

You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
“Area Prefix” advertisement functionally equivalent to the “Router-ID” 
advertisement. It’s a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.


You seem to be asking that the Area Leader also advertise a Prefix SID in its 
own LSP, as well as a prefix in the Area Proxy TLV.  This is not just 
duplication of advertisement, it’s duplication plus a prefix.  By your own 
criteria, this suggestion is worse than what we’ve proposed.

All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. 
 Only the Inside Edge Nodes need to install forwarding state for the Area SID.  
Advertising a separate Prefix SID to the Inside Nodes forces them to create 
additional forwarding state that may not be desired by the network 
administrator.



I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.


Thank you, but no thanks. As you’ve seen, a large driver for doing it this way 
is backward compatibility. Adding a bit would not be helpful in that regard.



But advertising a prefix-SID in two different places is a bad idea.


Advertising it in 2.5 places is worse.



In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

“An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose the pseudo

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[tony . li]

Hi Les,


> You have chosen to assign a prefix as the “Area Destination”.


Are you sure you have the right document?  The word “Destination” does not 
appear anywhere within 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03 



> This is fine with me. But having done that, forwarding should be based on the 
> existing mechanisms for advertising a prefix and the associated prefix SID.


Which is exactly what we’re doing: we’re advertising a prefix SID in the Proxy 
LSP.


If you’re referring to the Area SID advertisement, then there is no existing 
mechanism for advertising that today, that’s why we’re having to create an 
additional subTLV.
There is no other mechanism whereby system A can advertise a prefix SID to a 
number of other systems and have them install receive/POP forwarding entries.


> By doing that you avoid a number of problems:
>  
> Duplicate SID advertisements for the same prefix and the possibility of 
> inconsistency
> Differing forwarding behavior for routers (IERs) who understand the Area 
> Proxy TLV and those routers which don’t (everyone else)
>  
> You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
> Prefix, but there is no need to also advertise the SID there. This makes the 
> “Area Prefix” advertisement functionally equivalent to the “Router-ID” 
> advertisement. It’s a convenient way to identify the prefix associated with 
> the area, but it does not eliminate the need to also advertise prefix 
> reachability information for that prefix in order to enable forwarding.


You seem to be asking that the Area Leader also advertise a Prefix SID in its 
own LSP, as well as a prefix in the Area Proxy TLV.  This is not just 
duplication of advertisement, it’s duplication plus a prefix.  By your own 
criteria, this suggestion is worse than what we’ve proposed.

All Inside Nodes need to understand the Area Proxy TLV and respond accordingly. 
 Only the Inside Edge Nodes need to install forwarding state for the Area SID.  
Advertising a separate Prefix SID to the Inside Nodes forces them to create 
additional forwarding state that may not be desired by the network 
administrator. 


> I have also suggested that an additional bit could be assigned in the 
> Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if 
> you wish.


Thank you, but no thanks. As you’ve seen, a large driver for doing it this way 
is backward compatibility. Adding a bit would not be helpful in that regard.

 
> But advertising a prefix-SID in two different places is a bad idea.


Advertising it in 2.5 places is worse.


> In an unrelated matter, 
> https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 
>  
> states:
>  
> “An Inside Edge Router may be elected the DIS for a Boundary
>LAN.  In this case using the Area Proxy System Id as the basis for
>the LAN pseudonode identifier could create a collision, so the
>Insider Edge Router SHOULD compose the pseudonode identifier using
>its native system identifier.”
>  
> I understand the potential collision that could arise if the Area Proxy 
> System-Id were to be used in the pseudonode-id. However, what you propose is 
> incompatible with a strict interpretation of ISO 10589 Section 8.4.5:
>  
> “If this system, as a result of the Designated Intermediate System election 
> process, considers itself to be designated Intermediate System, the LAN ID 
> field shall be set to the concatenation of this system’s own system ID and 
> the locally assigned one octet Local Circuit ID.”
>  
> This raises the possibility that some of the non-DIS neighbors might not 
> honor the pseudo-node ID since it does not match the system-id associated 
> with their adjacency to the pseudo-node.
> At a minimum this possibility should be mentioned in the text.


This is fair and I will add a mention.  I should also point out that we have 
tested this against other implementations and not found a problem.

 
> One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in 
> their IIHs so as to avoid this case.


True, or avoiding edge LANs entirely.  As you’ve previously remarked elsewhere, 
true multi-access LANs are on the decline.

Tony



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

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[Toy, Mehmet]

  I am not  aware of any other IPR that applies to draft-chen-isis-ttz.
Thanks
Mehmet


---
*From:* Acee Lindem (acee) 
*Sent:* Tuesday, August 18, 2020 10:24 AM
*To:* draft-chen-isis-...@ietf.org 
*Cc:* lsr@ietf.org 
*Subject:* LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz.txt


Authors,



The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified
here:



https://datatracker.ietf.org/ipr/4029/






Are you aware of any other IPR that applies to draft-chen-isis-ttz?



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.



Thanks,

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

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

[Les Ginsberg (ginsberg)]

Tony -

You have chosen to assign a prefix as the "Area Destination". This is fine with 
me. But having done that, forwarding should be based on the existing mechanisms 
for advertising a prefix and the associated prefix SID.
By doing that you avoid a number of problems:


  *   Duplicate SID advertisements for the same prefix and the possibility of 
inconsistency
  *   Differing forwarding behavior for routers (IERs) who understand the Area 
Proxy TLV and those routers which don't (everyone else)


You can still include a sub-TLV in the Area Proxy TLV to identify the Area 
Prefix, but there is no need to also advertise the SID there. This makes the 
"Area Prefix" advertisement functionally equivalent to the "Router-ID" 
advertisement. It's a convenient way to identify the prefix associated with the 
area, but it does not eliminate the need to also advertise prefix reachability 
information for that prefix in order to enable forwarding.

I have also suggested that an additional bit could be assigned in the 
Prefix-Attributes sub-TLV (RFC 7794) to mark a prefix as an Area Prefix if you 
wish.

But advertising a prefix-SID in two different places is a bad idea.

.

In an unrelated matter, 
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03#section-2 states:

"An Inside Edge Router may be elected the DIS for a Boundary
   LAN.  In this case using the Area Proxy System Id as the basis for
   the LAN pseudonode identifier could create a collision, so the
   Insider Edge Router SHOULD compose the pseudonode identifier using
   its native system identifier."

I understand the potential collision that could arise if the Area Proxy 
System-Id were to be used in the pseudonode-id. However, what you propose is 
incompatible with a strict interpretation of ISO 10589 Section 8.4.5:

"If this system, as a result of the Designated Intermediate System election 
process, considers itself to be designated Intermediate System, the LAN ID 
field shall be set to the concatenation of this system's own system ID and the 
locally assigned one octet Local Circuit ID."

This raises the possibility that some of the non-DIS neighbors might not honor 
the pseudo-node ID since it does not match the system-id associated with their 
adjacency to the pseudo-node.
At a minimum this possibility should be mentioned in the text.

One way to mitigate this is to have the IERs advertise a LAN Priority of 0 in 
their IIHs so as to avoid this case.

   Les

From: Lsr  On Behalf Of tony...@tony.li
Sent: Monday, August 24, 2020 10:02 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt


Hi folks,

This updated draft has been published for a few weeks now.  We would like to 
solicit your opinion on this.  In particular, we have changed the encoding of 
the Area SID.  Do you find this encoding adequate and appropriate?

Thanks,
Tony



Begin forwarded message:

From: internet-dra...@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: mailto:i-d-annou...@ietf.org>>
Cc: lsr@ietf.org
Reply-To: internet-dra...@ietf.org, 
lsr@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

   Title   : Area Proxy for IS-IS
   Authors : Tony Li
 Sarah Chen
 Vivek Ilangovan
 Gyan S. Mishra
 Filename: draft-ietf-lsr-isis-area-proxy-03.txt
 Pages   : 19
 Date: 2020-08-05

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-03
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


__