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...
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).
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")
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.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
