Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

[Aijun Wang]

Hi, Robert:

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang 
Cc: Peter Psenak ; Huzhibo 
; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Xiaoyaqun 

Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

[WAJ] Such information is for underlay link state and should be flooded via 
IGP? The ambiguity arises from IGP summary behavior and should be solved by 
itself?

 

Well if we look at this problem from a distance while on surface it seems like 
an IGP issue (not to mention some which use BGP as IGP :) IMO it is only 
hurting when you have some service overlay on top utilizing the IGP. 

[WAJ] There are situations that the PUA mechanism apply when no service overlay 
running over IGP.  Scenarios described in  

 draft-wang-lsr-prefix-unreachable-annoucement-03#section-3 are not tightly 
coupled with the overlay service.

 

So typically today if I am running any service with BGP I do count on BGP to 
remove routes which are no longer reachable. IGP just tells me how to get to 
the next hop, which direction to go and not if the endpoint (service CPE or PE 
connected to given CE) is up or down. 

 

So today smart BGP implementations in good network design can use RD based 
withdraws to very fast (milliseconds) remove the affected service routes. When 
I said should we do it in BGP I meant to ask WG if this is good enough to 
quickly remove service routes. If not maybe we should send such affected next 
hop in BGP to even faster invalidate all routes with such next hop as failing 
PE. 

 

Bottom line if you think the problem is IGP then I think Acee's comments apply. 

[WAJ] Which comment is not addressed yet?

 

Last - See today you are bringing the case to signal transition to DOWN  
but for some people and applications it may be not enough. In fact UP/DOWN they 
can get via BGP. But if you have two ABRs and one will due to topology changes 
in its area suddenly will be forced to reach atomic destination covered by 
summary over much higher metric path that for applications running above may be 
much more severe case and not acceptable one too. 

[WAJ] Or else, the application traffic will be broken.

 

And BGP will not remove service routes nor modify best path in any way as 
summary is masking the real metric to some next hops. So while in the network 
you may have alternate better native transit paths with a lot of free capacity 
if you only switch to a different bgp next hop (not talking about any TE at 
all) you are stuck offering much worse service to your customers. 

[WAJ] if there are other links to reach the affected prefix via the ABR, then 
this ABR will not send the PUA information.

 

Those cases are starting to be solved by performance routing both at the 
service itself or at BGP nh levels. Should IGP assist here ... I am not sure.

[WAJ] when node become down, it can only depend on other nodes within the same 
IGP to send such unreachability information. IGP can certainly help here J

 

 

Many thx,

R.

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

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

[bruno.decraene]

Les,

Please see inline.

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, August 4, 2020 4:50 PM
To: DECRAENE Bruno TGI/OLN ; lsr@ietf.org
Subject: RE: draft-ietf-lsr-isis-area-proxy-02

Bruno -

Please see inline.

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
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 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 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 

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

[Tony Li]

Hi Bruno,


> 
> [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 algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Tony

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

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

[Les Ginsberg (ginsberg)]

Bruno -

Please see inline.

From: Lsr  On Behalf Of bruno.decra...@orange.com
Sent: Tuesday, August 04, 2020 5:45 AM
To: lsr@ietf.org
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 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 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.



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

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.


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.
Thus far you seem more inclined to use an anycast  Prefix-SID, so I am not 
clear on what you think is 

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

[bruno.decraene]

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 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 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr