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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Tony –

Inline.

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


Hi Les,


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.

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


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




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


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.


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