Robert,
First of all, I did not say that your quote was inaccurate. I apologize for 
possible misperception.

Second, I believe that spray or fan-out (meaning support of externally computed 
static MDTs) in SR-MPLS is a relevant focus area for the future WG work. Of 
course the solution must be aligned with the SPRING and MPLS architecture, and 
this imposes additional restrictions on how such a solution would look.

Last but not least, I have differentiated (from my first email on this thread) 
ingress replication in SR from the more generic multicast support in SR:

-          The latter is quite acceptable to me

-          The former, IMHO, should be left out of scope.

Hope this helps to clarify my position.
Regards, and, again, apologies for possible misinterpretation.

Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email protected]

From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk
Sent: Saturday, June 9, 2018 10:50 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; Xiejingrong <[email protected]>; Michael McBride 
<[email protected]>; Rob Shakir <[email protected]>; 
Paul Mattes <[email protected]>; Zafar Ali (zali) <[email protected]>; Eric C 
Rosen <[email protected]>; Voyer, Daniel <[email protected]>
Subject: Re: [spring] Updating the SPRING WG Charter


Sasha,

1. Where did I say it is a requirement ? My quote was precise and it clearly 
said that this is recommended.

2. Nothing in this thread requires use of domain-wide labels. All required 
functionality will work just fine with domain-wide indexes - so even we I or 
anyone one else said here anything about "domain-wide labels" fell free to 
substitute it with "domain-wide index" if this will make you happy.

3. To constructively move fwd let me propose we drop SR-MPLS all together from 
support of spray or fan-out functionality in the charter and just make sure 
charter reflect such support for SRv6 only. Now let's sit and watch how the 
proponents of index based offset instead of global SRGB will react if MPLS 
based network will miss such useful functionality :)

Cheers,
R.



On Sat, Jun 9, 2018 at 8:53 PM, Alexander Vainshtein 
<[email protected]<mailto:[email protected]>> 
wrote:
Robert,
I think that you have cut the quoted text from the Segment Routing 
Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
draft a bit too short. The complete fragment says:

   Where possible, it is recommended that identical SRGBs be configured
   on all nodes in an SR Domain.  This simplifies troubleshooting as the
   same label will be associated with the same prefix on all nodes.  In
   addition, it simplifies support for anycast as detailed in
   Section 
3.3<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.3>.

In other words,  the Segment Routing Architecture draft:

-          Does not consider identical SRGBs on all nodes in an SR domain as a 
requirement.

-          Explains that such configuration, if used, simplifies 
troubleshooting and support of anycast segments. With regard to the latter, 
please note that the Anycast 
Segments<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-02>
 draft defines a mechanism that facilitates usage of anycast segments in an 
environment with different SRGBs on different nodes.

Therefore, from my POV, domain-wide labels have been purged (for quite some 
time now) from the SR-MPLS architecture. I do not think that they should be 
re-introduced.

My 2c,
Sasha

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to