Subject: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

From: [email-masked]
Date: Sat, 25 Jul 2020 18:49:27 -0700

Hi folks,

This version of the draft reflects major changes in line with the discussions that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
> Date: July 25, 2020 at 6:46:05 PM PDT
> To: "Vivek Ilangovan" <[email-masked]>, "Sarah Chen" <[email-masked]>, "Gyan S. Mishra" <[email-masked]>, "Gyan Mishra" <[email-masked]>, "Yunxia Chen" <[email-masked]>, "Tony Li" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name:		draft-ietf-lsr-isis-area-proxy
> Revision:	02
> Title:		Area Proxy for IS-IS
> Document date:	2020-07-25
> Group:		lsr
> Pages:		20
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02
> 
> 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.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
>

---

From: <[email-masked]>
Date: Thu, 30 Jul 2020 16:22:04 +0000

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 2.4<https://tools.ietf.org/html/rfc8667#section-2.4> are used to

   advertise such a SID.

   The following extensions to the Binding TLV are defined in order to

   support Area SID:

      A new flag is defined:

         T-flag: The SID directs traffic to an area.  (Bit 5) »

This works.
However I may have a different deployment environment than the one you have in mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different vendors, platforms, software, generations. Requiring all those routers to support the new Binding SID TLV T-Flag will take time. Some platform may even be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any new feature on external L2 nodes, while all existing L2 features keep working, in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node. For SR, I think that this would require this Proxy LSP to advertise a Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, July 26, 2020 3:49 AM
To: [email-masked]
Subject: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Hi folks,

To wit:

Thanks,
Tony

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" <[email-masked]<mailto:[email-masked]>>, "Sarah Chen" <[email-masked]<mailto:[email-masked]>>, "Gyan S. Mishra" <[email-masked]<mailto:[email-masked]>>, "Gyan Mishra" <[email-masked]<mailto:[email-masked]>>, "Yunxia Chen" <[email-masked]<mailto:[email-masked]>>, "Tony Li" <[email-masked]<mailto:[email-masked]>>

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 Jul 2020 17:29:13 +0000

Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it has been suggested that other use cases for Area SID – unrelated to Area Proxy – may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best option if we want to allow for these other use cases (admittedly currently unknown).

Thoughts??

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, July 30, 2020 9:22 AM
To: [email-masked]; [email-masked]
Subject: Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

  *   - The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

   advertise such a SID.

   support Area SID:

      A new flag is defined:

This works.

Thanks,
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, July 26, 2020 3:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Hi folks,

To wit:

Thanks,
Tony

Begin forwarded message:

Abstract:

The IETF Secretariat

Thank you.

---

From: [email-masked]
Date: Thu, 30 Jul 2020 10:39:26 -0700

Hi Bruno,

Thank you for your comments.

> On Jul 30, 2020, at 9:22 AM, [email-masked] wrote:
> 
> Hi Tony,
>  
>    MT Binding TLVs described in RFC 8667 Section 2.4 <https://tools.ietf.org/html/rfc8667#section-2.4> are used to
>    advertise such a SID.
>  

Excellent.

> In my environment, ideally, I would prefer a solution which do not require any new feature on external L2 nodes, while all existing L2 features keep working, in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node.

First off, the Area SID is 100% optional. If you choose not to use it, then the Proxy LSP should be 100% compatible with a standard L2 node. 

I cannot claim that we’ve exhaustively tested our implementation against all of the features that you cite, so there may still be corner cases, but our intent is to make that doable.  For exaple, the Proxy LSP can still contain a node SID, adjacency SID, and prefix SID as before. There’s no change there.

> For SR, I think that this would require this Proxy LSP to advertise a Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is advertised with an IP address that would need to be provisioned.

That’s certainly doable and requires no new protocol machinery. If the WG prefers this mode of operation, I’m not opposed.

> Finally, there is no requirement to make me happy ;-) . The above could also be a local implementation knob not mentioned in the draft.

Our goal is to make as many customers as happy as possible.  ;-)

Tony

---

From: <[email-masked]>
Date: Fri, 31 Jul 2020 08:16:30 +0000

Les,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, July 30, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

Thoughts??

I have no problem with the format or the name of the IS-IS extension used to advertise the Area SID to external L2 nodes. Binding TLV works for me.
I think that the area SID is useful to external L2 nodes, including to nodes not supporting this extension. Hence the proposal to (also) advertise it in a regular Node SID. I’ll detail the use case in a subsequent email to be sent today. Writing it done will also be beneficial to me.

Thanks,
--Bruno

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 30, 2020 9:22 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

   advertise such a SID.

   support Area SID:

      A new flag is defined:

This works.

Thanks,
--Bruno

Hi folks,

To wit:

Thanks,
Tony

Begin forwarded message:

Abstract:

The IETF Secretariat

Thank you.

---

From: <[email-masked]>
Date: Fri, 31 Jul 2020 09:24:06 +0000

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.

Ø  First off, the Area SID is 100% optional. If you choose not to use it, then the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to use it. Then I’d like to get it for free ;-)

Please fine below a network topology:

My understanding is that the L2 topology seen by node S is the following

P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:

a)      If P does not redistribute the Node SIDs from its area members, P does not seem to advertise any node SID currently. There is a chance that C’s TI-LFA implementation would not like it and hence would not install protection for this (link, destination)

b)      If P redistributes the Node SIDs from its area members, P advertises 3 node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.

Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them with the value of the Area SID. This works for this use case, but it is borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m proposing. Both the IP loopback and the Area SID of this Node SID  are likely configured by the network operator so this does not seem like a significant effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to improve interop with existing/legacy L2 nodes so this may be valuable in the draft. This point could be pushed to a deployment consideration section if you don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this thread.

From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

Hi Bruno,

On Jul 30, 2020, at 9:22 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Tony,

   advertise such a SID.

   support Area SID:

      A new flag is defined:

This works.

Excellent.

Tony

---

From: [email-masked]
Date: Fri, 31 Jul 2020 10:49:34 -0700

Hi Bruno,

Thank you for the clarification.  I understand completely what you’re trying to do and I agree that it’s valuable.

The downside of your approach is that the Area Leader will now need configuration of a new prefix to advertise as the Node SID. Not unthinkable.
What do the Inside Nodes do with this prefix, if anything?  

I am open to this approach, either in addition to, or instead of the approach currently in the draft.  I await feedback from the WG.

Regards,
Tony

<IS-IS bigotry>

p.s. The fact that the node SID requires a prefix is just a side effect of the IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes that simply avoids ALL of these problems.  If RFC 8667 
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s style mandates, this would be trivial.

</IS-IS bigotry>

> On Jul 31, 2020, at 2:24 AM, [email-masked] wrote:
> 
> Hi Tony,
>  
> On Jul 30, 2020, at 9:22 AM, [email-masked] <mailto:[email-masked]> wrote:
>  
> Hi Tony,
>