Tony –

Inline.

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


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


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.

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


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

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.

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


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.


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.

[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


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

Reply via email to