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

   Les


From: Lsr <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<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.
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<mailto:tony...@tony.li>
Sent: Sunday, July 26, 2020 3:49 AM
To: lsr@ietf.org<mailto: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<mailto: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" <ilango...@arista.com<mailto:ilango...@arista.com>>, 
"Sarah Chen" <sarahc...@arista.com<mailto:sarahc...@arista.com>>, "Gyan S. 
Mishra" <gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>>, "Gyan 
Mishra" <gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>>, "Yunxia 
Chen" <sarahc...@arista.com<mailto:sarahc...@arista.com>>, "Tony Li" 
<tony...@tony.li<mailto:tony...@tony.li>>


A new version of I-D, draft-ietf-lsr-isis-area-proxy-02.txt
has been successfully submitted by Tony Li and posted to the
IETF repository.

Name:                     draft-ietf-lsr-isis-area-proxy
Revision:     02
Title:                        Area Proxy for IS-IS
Document date:      2020-07-25
Group:                     lsr
Pages:                      20
URL:            
https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
Htmlized:       https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-02

Abstract:
  Link state routing protocols have hierarchical abstraction already
  built into them.  However, when lower levels are used for transit,
  they must expose their internal topologies to each other, leading to
  scale issues.

  To avoid this, this document discusses extensions to the IS-IS
  routing protocol that would allow level 1 areas to provide transit,
  yet only inject an abstraction of the level 1 topology into level 2.
  Each level 1 area is represented as a single level 2 node, thereby
  enabling greater scale.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at 
tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat



_________________________________________________________________________________________________________________________



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

Reply via email to