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

[tony . li]

Hi Bruno,

Thank you for the clarification.  I understand completely what you’re trying to 
do and I agree that it’s valuable.

The downside of your approach is that the Area Leader will now need 
configuration of a new prefix to advertise as the Node SID. Not unthinkable.
What do the Inside Nodes do with this prefix, if anything?  

I am open to this approach, either in addition to, or instead of the approach 
currently in the draft.  I await feedback from the WG.

Regards,
Tony



p.s. The fact that the node SID requires a prefix is just a side effect of the 
IP address space excluding hosts from addressing. The one, true
way within IS-IS is the system ID, a separate, independent namespace for nodes 
that simply avoids ALL of these problems.  If RFC 8667 
encoded node SIDs as their own TLV without the unnecessary prefix that OSPF’s 
style mandates, this would be trivial.



> On Jul 31, 2020, at 2:24 AM, bruno.decra...@orange.com wrote:
> 
> Hi Tony,
>  
> Thank you for your reply.
> Top posting the description of the use case that I have in mind.
>  
> Ø  First off, the Area SID is 100% optional. If you choose not to use it, 
> then the Proxy LSP should be 100% compatible with a standard L2 node.
> Good. But I think that the idea of the Area SID is a good one, and I choose 
> to use it. Then I’d like to get it for free ;-)
>  
>  
> Please fine below a network topology:
> 
>  
>  
> My understanding is that the L2 topology seen by node S is the following
> 
>  
> P been the Proxy LSP.
>  
> S wants to protect from the failure of link S-C by using TI-LFA. For the 
> destination C, it would push 2 (*) node SIDs: P, C 
> So S needs a Node SID for P:
> a)  If P does not redistribute the Node SIDs from its area members, P 
> does not seem to advertise any node SID currently. There is a chance that C’s 
> TI-LFA implementation would not like it and hence would not install 
> protection for this (link, destination)
> b)  If P redistributes the Node SIDs from its area members, P advertises 
> 3 node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
> forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.
>  
> Two solutions I could think of:
> - when redistributing the node SID, P changes the SIDs values and replace 
> them with the value of the Area SID. This works for this use case, but it is 
> borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, 
> we have some SID conflict. Let’s try to avoid this subject).
> - P could advertise its own Node-SID with the Area SID value. This is what 
> I’m proposing. Both the IP loopback and the Area SID of this Node SID  are 
> likely configured by the network operator so this does not seem like a 
> significant effort from the implementation.
>  
> As you say, this does not involve any protocol extension. But the goal is to 
> improve interop with existing/legacy L2 nodes so this may be valuable in the 
> draft. This point could be pushed to a deployment consideration section if 
> you don’t want any impact on the protocol extension.
>  
> Thanks,
> --Bruno
>  
> (*) Assuming the right metrics on the links. This is not the subject of this 
> thread.
>  
>  
> From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Thursday, July 30, 2020 7:39 PM
> To: DECRAENE Bruno TGI/OLN 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-ietf-lsr-isis-area-proxy-02.txt
>  
>  
> Hi Bruno,
>  
> Thank you for your comments.
>  
> 
> 
> On Jul 30, 2020, at 9:22 AM, bruno.decra...@orange.com 
>  wrote:
>  
> Hi Tony,
>  
> Thanks for the updated draft.
>  
> “ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
>represents the entirety of the Inside Area to the Outside Area.  This
>sub-TLV is learned by all of the Inside Edge Nodes who should consume
>this SID at forwarding time.”
>  
> Excellent, from my perspective.
>  
> Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.
>  
> “When SR is enabled, it may be useful to advertise an Area SID which
>will direct traffic to any of the Inside Edge Routers.  The Binding/
>MT Binding TLVs described in RFC 8667 Section 2.4 
>  are used to
>advertise such a SID.
>  
>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) »
>  
>  
> This works.
>  
>  
> Excellent.
>  
> 
> 
> However I may have a different deployment environment than the one you have 
> in mind. Even if those issues may be mine, allow me to share them with you.
> In many WAN networks than I’m used to, there are routers from different 
> vendors, platforms, software, generations. Requiring all those routers to 
> support the new Binding SID TLV T-Flag will take ti

Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

[Thomas.Graf]

Hi Hannes,

Thanks a lot for the feedback. Yes, makes completely sense. Will take it for 
the next update.

Best Wishes
Thomas


From: Hannes Gredler 
Sent: Wednesday, July 29, 2020 9:31 AM
To: Graf Thomas, INI-NET-DCF 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-tgraf-ipfix-mpls-sr-label-type

Thomas,

I have one comment/suggestion to Paragraph 4 (IANA Considerations).

Please add also a code point for BGP Prefix-SID - it's quite popular in DC 
deployments.
https://tools.ietf.org/html/rfc8669

thanks,

/hannes


On 28.07.2020, at 10:11, 
thomas.g...@swisscom.com wrote:

Dear lsr,

I presented the following draft

Export of MPLS Segment Routing Label Type Information in IP Flow Information 
Export (IPFIX)
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-04

at the spring working group at IETF 108 yesterday
https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf

and today at OPSAWG where I call for adoption.

This draft adds additional segment routing code points for in the IANA IPFIX 
registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types to gain 
further insights into the MPLS-SR forwarding-plane.

I have been asked to not only gather feedback from spring and opsawg but also 
from lsr and mpls working groups since these code points are related to link 
state routing protocols and mpls data plane.

I am looking forward to your feedback and input.

Best Wishes
Thomas Graf
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr



smime.p7s
Description: S/MIME Cryptographic Signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

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

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.

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.

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.

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.

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[bruno.decraene]

Hi Tony,

Thank you for your reply.
Top posting the description of the use case that I have in mind.


Ø  First off, the Area SID is 100% optional. If you choose not to use it, then 
the Proxy LSP should be 100% compatible with a standard L2 node.
Good. But I think that the idea of the Area SID is a good one, and I choose to 
use it. Then I’d like to get it for free ;-)


Please fine below a network topology:
[cid:image003.jpg@01D6672D.1946D4F0]


My understanding is that the L2 topology seen by node S is the following
[cid:image004.jpg@01D6672D.1946D4F0]

P been the Proxy LSP.

S wants to protect from the failure of link S-C by using TI-LFA. For the 
destination C, it would push 2 (*) node SIDs: P, C
So S needs a Node SID for P:

a)  If P does not redistribute the Node SIDs from its area members, P does 
not seem to advertise any node SID currently. There is a chance that C’s TI-LFA 
implementation would not like it and hence would not install protection for 
this (link, destination)

b)  If P redistributes the Node SIDs from its area members, P advertises 3 
node SIDs (1,2, 3). S could pick any one at random. If it picks 3, the 
forwarding path would be S, A,B, 1, 2, 3, 2 , 1, C,  which is suboptimal.


Two solutions I could think of:
- when redistributing the node SID, P changes the SIDs values and replace them 
with the value of the Area SID. This works for this use case, but it is 
borderline. (e.g. if some a L2 node learn both the original and ‘NATed’ SID, we 
have some SID conflict. Let’s try to avoid this subject).
- P could advertise its own Node-SID with the Area SID value. This is what I’m 
proposing. Both the IP loopback and the Area SID of this Node SID  are likely 
configured by the network operator so this does not seem like a significant 
effort from the implementation.

As you say, this does not involve any protocol extension. But the goal is to 
improve interop with existing/legacy L2 nodes so this may be valuable in the 
draft. This point could be pushed to a deployment consideration section if you 
don’t want any impact on the protocol extension.

Thanks,
--Bruno

(*) Assuming the right metrics on the links. This is not the subject of this 
thread.


From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, July 30, 2020 7:39 PM
To: DECRAENE Bruno TGI/OLN 
Cc: lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi Bruno,

Thank you for your comments.



On Jul 30, 2020, at 9:22 AM, 
bruno.decra...@orange.com wrote:

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

>  - The Area Segment SID TLV has been replaced by extending the Binding SID 
> TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   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) »




This works.


Excellent.



However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 node.


First off, the Area SID is 100% optional. If you choose not to use it, then the 
Proxy LSP should be 100% compatible with a standard L2 node.



I cannot claim that we’ve exhaustively tested our implementation against all of 
the features that you cite, so there may still be corner cases, but our intent 
is to make that doable.  For exaple, the Proxy LSP can still contain a node 
SID, adjacency SID, and prefix SID as before. There’s no change there.



For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.


That’s certainly doab

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

[bruno.decraene]

Les,

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Thursday, July 30, 2020 7:29 PM
To: DECRAENE Bruno TGI/OLN ; tony...@tony.li; 
lsr@ietf.org
Subject: RE: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

One of the reasons to use the Binding TLV to advertise the Area SID was that it 
has been suggested that other use cases for Area SID – unrelated to Area Proxy 
– may come along.
Therefore tying the advertisement to an Area Proxy TLV seems not the best 
option if we want to allow for these other use cases (admittedly currently 
unknown).

Thoughts??

I have no problem with the format or the name of the IS-IS extension used to 
advertise the Area SID to external L2 nodes. Binding TLV works for me.
I think that the area SID is useful to external L2 nodes, including to nodes 
not supporting this extension. Hence the proposal to (also) advertise it in a 
regular Node SID. I’ll detail the use case in a subsequent email to be sent 
today. Writing it done will also be beneficial to me.

Thanks,
--Bruno


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: Thursday, July 30, 2020 9:22 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Hi Tony,

Thanks for the updated draft.

“ The Area SID Sub-TLV allows the Area Leader to advertise a SID that
   represents the entirety of the Inside Area to the Outside Area.  This
   sub-TLV is learned by all of the Inside Edge Nodes who should consume
   this SID at forwarding time.”

Excellent, from my perspective.

Ø  - The Area Segment SID TLV has been replaced by extending the Binding SID 
TLV.


“When SR is enabled, it may be useful to advertise an Area SID which

   will direct traffic to any of the Inside Edge Routers.  The Binding/

   MT Binding TLVs described in RFC 8667 Section 
2.4 are used to

   advertise such a SID.



   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) »




This works.
However I may have a different deployment environment than the one you have in 
mind. Even if those issues may be mine, allow me to share them with you.
In many WAN networks than I’m used to, there are routers from different 
vendors, platforms, software, generations. Requiring all those routers to 
support the new Binding SID TLV T-Flag will take time. Some platform may even 
be end of engineering (evolutions) so would never support such new features.
In my environment, ideally, I would prefer a solution which do not require any 
new feature on external L2 nodes, while all existing L2 features keep working, 
in particular SR, SR-TE, TI-LFA, SR uloop avoidance… This would require the 
Proxy LSP to be not (significantly) different than the LSP of a vanilla L2 
node. For SR, I think that this would require this Proxy LSP to advertise a 
Prefix/Node SID with the Area SID attached. One drawback is that a Node-SID is 
advertised with an IP address that would need to be provisioned.

Both approaches are not mutually exclusives. I’d be happy enough with an option 
for the Proxy LSP to advertise an Area Node SID with the Area SID attached.

Finally, there is no requirement to make me happy ;-) . The above could also be 
a local implementation knob not mentioned in the draft.

Thanks,
--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
tony...@tony.li
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org
Subject: [Lsr] Fwd: New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt


Hi folks,

This version of the draft reflects major changes in line with the discussions 
that we’ve had so far.

To wit:
- The Area Proxy TLV is now moved to be in L2 LSPs and indicates that the 
advertising node is an Inside Node and Area Proxy is active.
- The Area Proxy Router Capability has been removed.
- The Inside Node TLV has been removed.
- The Area Segment SID TLV has been replaced by extending the Binding SID TLV.

We know that some folks disagree with this last point, so we welcome discussion 
on this. We would like to reach consensus as quickly as possible.

Thanks,
Tony


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt
Date: July 25, 2020 at 6:46:05 PM PDT
To: "Vivek Ilangovan" mailto:ilango...@arista.com>>, 
"Sarah Chen" mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" mailto:sarahc...@arista.com>>, "Tony Li" 
mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isi