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 
> <https://tools.ietf.org/html/rfc8667#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 doable and requires no new protocol machinery. If the WG 
prefers this mode of operation, I’m not opposed.

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


Our goal is to make as many customers as happy as possible.  ;-)

Tony

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

Reply via email to