Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

[[e-mail]]

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:[e-mail]]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN <[e-mail]>; [e-mail]
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, August 04, 2020 5:45 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Lsr] draft-ietf-lsr-isis-area-proxy-02

Hi,

I may be missing something but the SR Binding SID TLV extension  is not clear to me.

1)      It does not seem compliant with RFC 8667

Draft says that the advertisement has: T-flag set, M & A flags cleared, SID/Label sub-TLV present, Prefix-SID sub-TLV NOT present


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)



         When T-flag is set:



            M and A flag MUST be clear



            Range and Prefix are ignored



      Section 2.4.4 of RFC 8667<https://tools.ietf.org/html/rfc8667#section-2.4..4> is altered to say:



         "The Prefix-SID sub-TLV MUST be present in the SID/Label

         Binding TLV when the M-Flag and T-flag are both clear.  The

         Prefix-SID sub-TLV MUST NOT be present when either the M-Flag

         or T-flag are set."



      Regarding the SID/Label sub-TLV Section 2.4.5 of RFC 8667<https://tools.ietf.org/html/rfc8667#section-2.4.5> is

      altered to say:



         "It MUST be present in the SID/Label Binding TLV when either

         the M-Flag or T-flag is set in the Flags field of the parent

         TLV."

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#page-14



By definition, legacy L2 external  node will support vanilla RFC 8667, which says:
"The Prefix-SID sub-TLV MUST be present in the SID/Label Binding TLV when the M-Flag is clear."
https://www.rfc-editor.org/rfc/rfc8667.html#name-sid-label-binding-tlv

So it seems that the extension violates the above MUST in RFC8667, as regarding the Prefix-SID sub-TLV
-          Area proxy says "MUST NOT be present" (as T-flag is set)
-          RFC 8667 says "MUST be present" (as M-flag is cleared)


In addition to the above, legacy node _will_ interpret the 'Range' and 'Prefix' fields. So there is probably a need to specify which values need to be advertised for those legacy nodes. A priori range would be one as a single SID is advertised. Prefix seems more problematic as you need to find an IP prefix to advertise. And please let's avoid SID conflict and Prefix conflict...
[Les:] Format of the Binding TLV when the new T-bit is set is similar to the format when the M-bit is set in that Prefix-SID sub-TLV is NOT present.
A legacy node parsing the Binding TLV would be looking for the Prefix-SID sub-TLV (M-bit NOT set) and would not find it. The contents of the Binding TLV would therefore be unusable to a legacy node.
The correct behaviour for a legacy node would be to (optionally) report an "invalid TLV" and to ignore the TLV.
[Bruno]
Clearly, there is a way to advertise the SID without violating a MUST in a RFC. e.g. version -00 of this draft
I don't see a reason to define a spec which deliberately violates another spec. In the best case, this would report errors forever to the network operator. In the worst case, this could fall into a bug.


2)      It's not clear to me whether the segment/SID is global or local.
As per my understanding of the draft-ietf-lsr-isis-area-proxy use case, the area-proxy SID would be global (in the external L2): "Area SID which will direct traffic to any of the Inside Edge Routers."

But the SID/Label Sub-TLV used by area-proxy has no flag (L-flag) indicating whether the SID is global or local. One could argue that if it carries a label it's a local SID and if it carries and index it's a global SID. But this has not been specified.
It has also no "algorithm" indicating how it needs to be routed global, so at minimum would not work with different routing algo/flex algo.
I'm not seeing in RFC 8402 or 8667 any text saying that such SID would be global hence globally routed in the L2 domain. (To me, this IS-IS SID was local, but arguably also can't find text stating this).

[Les:] There is a subtle difference between the Prefix-SID sub-TLV as defined in https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 and the SID/Label sub-TLV defined in https://www.rfc-editor.org/rfc/rfc8667.html#SIDLABELSUBTLV

The Prefix-SID sub-TLV has a flags field which includes V-bit/L-bit to indicate whether the variable length field which follows is a 3 byte label (both bits set to 1) or a 4 byte index (both bits set to 0).

The SID/Label sub-TLV has no flags field. The length of the sub-TLV indicates whether the advertised value has is a label (length = 3)  or an index (length = 4).

[Bruno] Agreed so far.
Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? We both agree that this sub-TLV has no mention of the global flag nor the routing algo to be used.
Coming back to my first question, is this segment expected to be global or local within the (external) L2?
I see no issue here.

I would also point out that the new Area Proxy SID sub-TLV ( https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-4.3.2 ) does include V/L bits - similar to the Prefix-SID sub-TLV.
[Bruno] yes but that one is only advertised within the area. I'm referring to the L2 advertisement external to the area.


At minimum, area-proxy would need to specify whether the SID is global and local. And if global, with which hard coded algorithm it is routed. (I would assume "0")

[Les:]Just as the Mirror SID has no algorithm associated, neither does the Area SID.
If you feel that is an issue, please expand on how you intend to use an algorithm specific Area SID.
[Bruno]
My understanding is that the IGP Mirror SID is a local segment.
For the area SID, I think it should be global, but I see no mention of this in the draft. Let's begin with the first question: in the (external) L2, is the area SID a global or local segment?

--Bruno
Thus far you seem more inclined to use an anycast  Prefix-SID, so I am not clear on what you think is needed here and why.
I would agree that if algorithm is required it is currently not available - but it is not yet clear that algorithm is required.

   Les

Thanks,
Regards,
--Bruno


_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.