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

From: [email-masked]
Date: Tue, 7 Jul 2020 08:20:03 -0700

Hi all,

We’ve updated our draft to revise the TLV encodings along the lines of the discussions we’ve been having.

1) The Area Proxy Router Capability is removed.
2) The Inside Node TLV is removed. Instead, the Area Proxy TLV is used instead.
3) The Area Segment SID is advertised inside of a SID/Label Binding TLV. While we discussed using 
a flag within this TLV to denote that this was an Area Segment SID, after looking at it, it seemed simpler
and more consistent to use a sub-TLV.

Please review and comment.

Thanks,
Sarah, Vivek, Gyan, and Tony

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
> Date: July 7, 2020 at 8:14:58 AM PDT
> To: "Gyan Mishra" <[email-masked]>, "Vivek Ilangovan" <[email-masked]>, "Sarah Chen" <[email-masked]>, "Tony Li" <[email-masked]>, "Gyan S. Mishra" <[email-masked]>, "Yunxia Chen" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-01.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name:		draft-ietf-lsr-isis-area-proxy
> Revision:	01
> Title:		Area Proxy for IS-IS
> Document date:	2020-07-07
> Group:		lsr
> Pages:		19
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-01.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-01
> 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-01
> 
> 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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Jul 2020 07:43:19 +0000

Tony –

The new definitions in the latest version in the draft are very close to what we discussed in the earlier thread – so this looks pretty good to me.

I still have some concerns regarding the Area Segment SID.
You propose to advertise this in two places:

1)As a sub-TLV of the new Area Proxy TLV
2)As a new sub-TLV of the existing Binding TLVs (149, 150)

I am not sure why you need this in the Area Proxy TLV as you allow Binding TLVs to be advertised in the Proxy LSPs (Section 4.4.10).
???

If this is what is intended, it raises a number of concerns:

If both are present and inconsistent how are they used?
As Area Proxy TLV does not support MT (not suggesting that it should) it isn’t clear how this relates to MT context – which exists for TLVs 149/150.

Encoding wise, if we are to support Area Segment SID in the Binding TLVs, I think more detail needs to be provided as to flag settings when the new sub-TLV is present.
The following flags are currently defined for the Binding TLVs:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A|     |
+-+-+-+-+-+-+-+-+

F,S,D flags seem applicable w/o change.
However, M flag would need to be clear when Area Segment SID is present.
The A flag seems not applicable to Area Segment SID
And your encoding violates the current definition of Binding TLVs.
Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 states:

“The Prefix-SID sub-TLV is defined in Section 2.1<https://www.rfc-editor.org/rfc/rfc8667.html#PREFIXSIDSUBTLV> and contains the SID/Index/Label value associated with the prefix and range.
 The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the M-Flag is clear.
 The Prefix-SID sub-TLV MUST NOT be present when the M-Flag is set.”

While some changes to this definition are likely required to support Area Segment SID no matter what, it is hard for me to see a good way to do this w/o adding a new flag.

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, July 07, 2020 8:20 AM
To: [email-masked]
Subject: [Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

Hi all,

Thanks,

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt
Date: July 7, 2020 at 8:14:58 AM PDT
To: "Gyan Mishra" <[email-masked]<mailto:[email-masked]>>, "Vivek Ilangovan" <[email-masked]<mailto:[email-masked]>>, "Sarah Chen" <[email-masked]<mailto:[email-masked]>>, "Tony Li" <[email-masked]<mailto:[email-masked]>>, "Gyan S. Mishra" <[email-masked]<mailto:[email-masked]>>, "Yunxia Chen" <[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

---

From: [email-masked]
Date: Wed, 8 Jul 2020 08:29:26 -0700

Hi Les,

> The new definitions in the latest version in the draft are very close to what we discussed in the earlier thread – so this looks pretty good to me.

Excellent, thanks.

> I am not sure why you need this in the Area Proxy TLV as you allow Binding TLVs to be advertised in the Proxy LSPs (Section 4.4.10).

Again, the subTLVs of the area proxy TLV are for the coordination of the Inside Area. The Area Proxy TLV appears in the Inside Node’s normal LSP.

The Proxy LSP is for informing the Outside Area.

It’s fairly important that we install the forwarding state for the Area Segment SID and distribute the Proxy System ID before we advertise the Proxy LSP.

> If both are present and inconsistent how are they used?

If both are present and inconsistent, then we have a major malfunction of the Area Leader, since it is the single system that is intentionally advertising both.

The Inside Nodes would follow the contents of the Area Proxy TLV and employ one SID value.

The Outsiide Nodes would follow the contents of the Proxy LSP and employ a different SID value.

Hilarity ensues.

Note that this is somewhat analogous to a system that wished to advertise a loopback interface and advertised one prefix into L1 and another prefix into L2.

> Specifically, https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4 <https://www.rfc-editor.org/rfc/rfc8667.html#section-2.4.4> states:
>  
> “The Prefix-SID sub-TLV is defined in Section 2.1 <https://www.rfc-editor.org/rfc/rfc8667.html#PREFIXSIDSUBTLV> and contains the SID/Index/Label value associated with the prefix and range.

I’m open to suggestions here.

We are abusing the definition of the Binding TLV.  2.4 says: "The SID/Label Binding TLV may be used to advertise prefixes to SID/Label mappings.”  That’s not what we’re doing, so it’s not too surprising that there’s some conflicts.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Jul 2020 17:44:38 +0000

Tony –

Inline.

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, July 08, 2020 8:29 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

Hi Les,

Excellent, thanks.

[Les:] Understood – but I do not see why this requires you to advertise the SID in two different TLVs. As you allow the Binding SID TLVs to be advertised in both standard LSPs and Proxy LSPs, there seems to be no need for two different TLVs to include the advertisement.
??

Hilarity ensues.

[Les:] Yes – of course – this is pathological. (Probably not hilarious to the customer. 😊 )
I am just saying by having two sources for the advertisement you introduce the possibility of inconsistency – and the spec would have to speak to this – even if it should not happen.

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|M|S|D|A|     |
+-+-+-+-+-+-+-+-+

[Les:] Yes – the Binding TLV has some issues being generalized. There is history here as to why the format is the way it is and why it isn’t more easily extensible – and that is open for discussion AFAIAC, but we cannot break backwards compatibility for SR.
But I am also responding (in part) to your desire to make the Area Segment SID a more general tool – usable outside of Area Proxy – which seems like a good goal.

   Les

Tony

---

From: [email-masked]
Date: Wed, 8 Jul 2020 11:12:08 -0700

Hi Les,

> [Les:] Understood – but I do not see why this requires you to advertise the SID in two different TLVs. As you allow the Binding SID TLVs to be advertised in both standard LSPs and Proxy LSPs, there…

The semantics are completely different. Advertising it in the Binding TLV is permission to use the SID for packet forwarding.

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use that SID to establish the forwarding state.  

> [Les:] Yes – of course – this is pathological. (Probably not hilarious to the customer. 😊 )

No doubt, but I’ve found that if one doesn’t regard bugs with some humor, our profession would be morose, in the extreme.

> I am just saying by having two sources for the advertisement you introduce the possibility of inconsistency – and the spec would have to speak to this – even if it should not happen.

Ummm…. Not sure what I can say other than “don’t write bugs”.  But ok, I’ll happily do so.

> [Les:] Yes – the Binding TLV has some issues being generalized. There is history here as to why the format is the way it is and why it isn’t more easily extensible – and that is open for discussion…

Agreed, trying not to. :-)

> But I am also responding (in part) to your desire to make the Area Segment SID a more general tool – usable outside of Area Proxy – which seems like a good goal.

And you’ve requested that we put the Area Segment SID in the Binding TLV.  I’ve tried to do so and you don’t like how I’ve done it.  Please tell me what I can do that will satisfy you.  From what you’ve said so far, there is no legal way to use the Binding TLV.

Catch-22.  Yossarian!

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Jul 2020 18:19:28 +0000

Tony –

Inline.

From: Tony Li <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, July 08, 2020 11:12 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

Hi Les,

The advertisement in the Area Proxy LSP is to instruct the Inside Nodes to use that SID to establish the forwarding state.
[Les:] Sorry, I do not see why this requires you to advertise the SID in two different places.
The SID gets advertised in one place (which TLV is TBD for the moment). The instruction to enable use of it for Area Proxy comes in the Area Proxy TLV. That only requires (at most) a bit – and perhaps nothing other than the presence of the Area Proxy TLV. It certainly does not require the SID itself to be readvertised.

Let’s see if we can agree that the SID only needs to be advertised in one place before proceeding further.

    Les

Catch-22.  Yossarian!

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 12 Jul 2020 13:41:40 +0000

Resuming this thread…the authors were kind enough to meet with me and educate me on how Area Proxy works. The resulting conclusions are:

1)Area Proxy TLV is meant to  be sent ONLY in L1L2 LSPs (NOT Proxy LSPs).

2)Advertisement of Area SID in the Area Proxy TLV is needed so that Inside Nodes can install a receive entry for that SID

3)Advertisement of Area SID in Binding TLV is needed in Proxy LSPs so that outside nodes can install a forwarding entry towards the Inside Node(s).
This SID MUST be identical to the SID advertised in the Area Proxy TLV in L2 LSPs.
Use of the Binding TLVs to do this is the current choice.

4)Other uses of an Area SID not related to Area Proxy are outside the scope of the Area Proxy draft. However, as the concept seems potentially useful in other scenarios, being able to advertise an Area SID in the Binding TLV allows for these other uses.
But, any advertisement of Area SID in Binding TLV which appears in L1L2 LSPs is unrelated to Area Proxy. Whether that SID is the same value as that used for Area Proxy is something future use cases for Area SID will have to decide.

I therefore think it makes sense to allow advertisement of the Area SID in both the Area Proxy TLV and the Binding TLV, subject to the constraints above. This will NOT result in “duplicate advertisements”.

Further details regarding the encoding will need to be provided in future revisions of the draft.

   Les (both as WG member and Designated Expert for IS-IS TLV Codepoints Registry)

From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, July 08, 2020 11:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

Tony –

Inline.

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 08, 2020 11:12 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-01.txt

Hi Les,

    Les

Catch-22.  Yossarian!

Regards,
Tony