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

From: [email-masked]
Date: Wed, 05 Aug 2020 13:17:39 -0700

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/

---

From: [email-masked]
Date: Mon, 24 Aug 2020 10:02:09 -0700

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: [email-masked]
> Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
> Date: August 5, 2020 at 1:17:39 PM PDT
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked], [email-masked]
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2020 01:01:11 +0200

Hi Tony & WG,

The changes which went into sections 4.3.2 & 4.4.13 do address my
suggestions made earlier to the list. So I do support the current version.

With the option of having a configurable area prefix this delivers quite a
powerful extension.

Also the current text says:

"Other uses of the Area SID are outside the scope of this document. "

Maybe we could state instead:

Other uses of the Area SID and area prefix are outside the scope of this
document.

Many thx,
R.

On Mon, Aug 24, 2020 at 7:02 PM <[email-masked]> wrote:

>
> 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: [email-masked]
> *Subject: **I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt*
> *Date: *August 5, 2020 at 1:17:39 PM PDT
> *To: *<[email-masked]>
> *Cc: [email-masked]
> *Reply-To: [email-masked], [email-masked]
>
>
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2020 21:29:19 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, August 24, 2020 10:02 AM
To: [email-masked]
Subject: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi folks,

Thanks,
Tony

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt
Date: August 5, 2020 at 1:17:39 PM PDT
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Reply-To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Abstract:

[email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Wed, 26 Aug 2020 16:02:28 -0700

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

> 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 <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
>    its native system identifier.”
>  
> “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 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Aug 2020 00:16:49 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, August 26, 2020 4:02 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Les,

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

  *   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)

Tony

---

From: [email-masked]
Date: Wed, 26 Aug 2020 17:40:16 -0700

Les,

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

> 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…

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

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Aug 2020 03:40:54 +0000

Tony –

Inline.

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

Les,

As per the draft:

???

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

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

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

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

   Les

Tony

---

From: [email-masked]
Date: Wed, 26 Aug 2020 20:55:44 -0700

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.  

> 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…

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.

> [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.…

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

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

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Aug 2020 14:29:30 +0000

Tony –

Inline.

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, August 26, 2020 8:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Hi Les,

[Les:] Thanx for clarifying this. A careful reading of the draft supports what you say, but as this point could be easily overlooked it might be worth emphasizing this in the draft.
In any case this isn’t significant for the points we are debating here.

[Les:] Section 4.2 states:

“For consistency, all Area Leader candidates SHOULD be configured with
   the same Proxy System Id, Proxy Hostname, and any other information
   that may be inserted into the Proxy LSP.”

I would agree that the flexibility to easily propagate a config change to be reflected in the Proxy LSP content requires relaxation of this rule.
But again, not significant for the points we are debating here.

[Les:] Installation of forwarding entries today is based on Prefix Reachability advertisements. You are proposing to extend that by requiring a forwarding entry to be installed based on the context of the Area Proxy TLV.
I would prefer that you not introduce this.
In addition, since there will also be a Prefix Reachability Advertisement for the Area Prefix in the Proxy LSP, the IERs will have two sources of information for the SID associated with the Area prefix (Area SID sub-TLV from Area leader L2 LSP and Prefix Reachability advertisement in the Proxy LSP). Which introduces the possibility of inconsistency.
If you do NOT advertise the SID in the Area Proxy TLV then you both eliminate the introduction of installing forwarding entries based on non-reachability advertisements and you eliminate the possibility of inconsistency.
That is what I am asking you to do.

[Les:] That’s wasn’t the point. The point was that when a SID is advertised in prefix reachability it is used in preference to advertisements in other TLVs.

Please point me to anycast semantics that will ONLY be selected by IERs.
[Les:] You have specified that only IERs and Outside Routers process Proxy LSP content.  So why do you ask this question?

   Les

Tony

---

From: [email-masked]
Date: Thu, 27 Aug 2020 08:19:23 -0700

Les,

> [Les:] Thanx for clarifying this. A careful reading of the draft supports what you say, but as this point could be easily overlooked it might be worth emphasizing this in the draft.

Noted and enhanced.

> I would agree that the flexibility to easily propagate a config change to be reflected in the Proxy LSP content requires relaxation of this rule.

This is exactly why it says SHOULD and not MUST.

> I would prefer that you not introduce this.

I am well aware of that.

Perhaps it would help if I tell you that I am 100% impervious to Persuasion by Repetition.  I understand what you want. I disagree with you on the tradeoffs.

> In addition, since there will also be a Prefix Reachability Advertisement for the Area Prefix in the Proxy LSP, the IERs will have two sources of information for the SID associated with the Area pr…

No, since the IERs are supposed to ignore the Proxy LSP for any purpose other than flooding. I’m adding an explicit statement to this effect. The only source of truth is the Area Proxy TLV generated by the Area Leader.

> [Les:] That’s wasn’t the point.

That is the entire point.  You insist that we advertise the Area SID as a Prefix SID in addition to the a prefix in the Area Proxy TLV.  The additional Prefix SID does NOT have the semantics that we want and causes deleterious side-effects.

> The point was that when a SID is advertised in prefix reachability it is used in preference to advertisements in other TLVs.

Except when it is part of the Proxy LSP, in which case we want the Inside Routers to ignore it.  We do NOT want Inside Routers creating forwarding state or SPF state for every prefix and SID in the Proxy LSP.

> [Les:] You have specified that only IERs and Outside Routers process Proxy LSP content.  So why do you ask this question?

You’re asking me to use another mechanism.  I don’t see how it applies.  I’m open to you educating me.

IERs do NOT process Proxy LSP content other than to flood it.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Aug 2020 15:35:39 +0000

Tony –

The statement “the … Prefix SID does NOT have the semantics that we want and causes deleterious side-effects” is FALSE.

Other than  that,  we understand each other and we disagree.
You have my input.

There is an alternative here:

Given that there isn’t any defined use case for the Area Prefix/SID, you could choose to defer its definition until such time as a use case arises.
I agree that the concept is appealing and is potentially useful – which is why I thought it worthwhile to invest time in defining it. But a conservative approach might be to wait until we actually need it before defining it. It is always possible that when the use case arises we will find that there are some other issues which have been overlooked which might alter how this would be advertised.

   Les

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, August 27, 2020 8:19 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

Les,

Noted and enhanced.

I am well aware of that.

Tony

---

From: [email-masked]
Date: Thu, 27 Aug 2020 09:03:29 -0700

Les,

> The statement “the … Prefix SID does NOT have the semantics that we want and causes deleterious side-effects” is FALSE.

Ahem.  I disagree.  No need to be rude about it.

> I agree that the concept is appealing and is potentially useful – which is why I thought it worthwhile to invest time in defining it. But a conservative approach might be to wait until we actually…

You’ve heard two of our customers here on the list tell you that they want this.  Therefore, we’re going to ship it.

Tony