Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[James Guichard <[e-mail]>]

Hi Gyan, et al.

Your email is timely.

This past week the chairs have been working on a set of plans and approaches to move the SR IPv6 Compression work ahead expeditiously. We are currently finalizing those plans and will make an announcement to the WG very shortly.

Thanks!

Jim, Joel & Bruno



From: spring <[e-mail]> On Behalf Of Gyan Mishra
Sent: Saturday, June 27, 2020 9:25 PM
To: Ron Bonica <rbonica=[e-mail]>
Cc: SPRING WG <[e-mail]>; Darren Dukes (ddukes) <ddukes=[e-mail]>
Subject: Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Darren

The SR flavor and SRv6 compression comparison draft I am planning to publish soon is a from a “neutral” party myself as an operator versus vendor bias having vendor affiliation.

I would like this document to gain traction with Spring and WG adoption as it being “Neutral” it benefit all both operators as well as vendors alike.

I would like to get all the nitty gritty meat deep dive behind the technical merit of each SRv6 compression technique.  This draft I am proposing as well will help maybe either come to a consensus that one drafts compression technique is the one Spring WG has decided to back and has WG concerns over other compression techniques.  And maybe might be the case that all have their merit and all the compression techniques gain WG adoption and as they all have their pluses and minuses and at that point we would let the industry decide which gains traction in a real world deployments.

Kind Regards

Gyan

On Sat, Jun 27, 2020 at 9:13 PM Gyan Mishra <[e-mail]<mailto:[e-mail]>> wrote:

Daren

As SRv6 has its inherent MSD issues right out of the gate and requires use of a myriad of compression techniques to make SRv6 viable for long SR-TE strict paths.

Ref: List of competing solutions in SPRING
[1] https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-np/?include_text=1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cl-spring-generalized-srv6-np%2F%3Finclude_text%3D1&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518555905&sdata=GPLglky55ugjXpEwIBjg6jaqz517CFV5eg0x5XSbdgA%3D&reserved=0>
[2] https://datatracker.ietf.org/doc/draft-li-spring-compressed-srv6-np/?include_text=1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-spring-compressed-srv6-np%2F%3Finclude_text%3D1&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518565902&sdata=svmAL2RQma2yEDw1sDnmZJBhQhy9njMLd4qnrEx1REQ%3D&reserved=0>
[3] https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/?include_text=1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mirsky-6man-unified-id-sr%2F%3Finclude_text%3D1&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518565902&sdata=YSJZStCW8rXd2O7H%2BUPgYjvL1dUdEGOhFNeKg%2Fkf4SI%3D&reserved=0>
[4] https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-decraene-spring-srv6-vlsid%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518575894&sdata=LDgbOtSzBo8T7J%2BPBmHlgbZY2DDCwjulCvZJtJaffYA%3D&reserved=0>
[5] https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/?include_text=1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfils-spring-net-pgm-extension-srv6-usid%2F%3Finclude_text%3D1&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518575894&sdata=0NAQxSVO2LfjH9FuNIHkmA5eh95kPpbURVg%2BDGw5RzU%3D&reserved=0>

In recent May timeframe an email came out below came claiming yet another version which takes two of the drafts above and generates a new version to help address the MSD pitfalls of SRv6 that failed to start right out of the gate.

My thoughts are as an operator it would be good to have a draft that compares and contrasts all of the SRv6 compression techniques and why this new one proposed now is better then any of the others.

I am working on a draft that does exactly that as well as comparing the SRv6 compression techniques, it also digs into the weeds and compare from and decision tree perspective pros and cons of Segment Routing flavors SR-MPLS, SRv6 and SRM6 and which makes sense for Greenfield  and Brownfield deployments.

Once I have the draft published I will be polling all the authors of the SRv6 compression drafts to dig into the detailed comparison of compression techniques and why one should chosen over another.

Excerpt from email to Spring WG May timeframe:

Dear SPRING,

The authors of draft-filsfils-spring-net-pgm-extension-srv6-usid and draft-cl-spring-generalized-srv6-for-cmpr have been working together on a joint document that describes how compressed SRv6 Segment-List encoding in the SRH can be achieved without any change to the SRv6 data plane or control plane. The new draft link is as follows:

https://www.ietf.org/internet-drafts/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01.txt&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518585891&sdata=eiWyVoACjJakye5Yc8vFnr6L1DsMVEcEhMSVeQUAGBI%3D&reserved=0>

In this draft, we leverage the notions of SIDfunction and argument defined in draft-ietf-spring-srv6-network-programming to compress the SRv6Segment List encoding in the SRH. The compressed encoding is achieved through two new flavors of the base Network Programming behaviors (End, End.X and End.T), named NEXT-C-SID and REPLACE-C-SID.

Sent from my iPhone


On Jun 27, 2020, at 7:45 PM, Ron Bonica <rbonica=[e-mail]<mailto:[e-mail]>> wrote:

Darren,

Your draft purports to be an “SRv6 Network Programming Overhead Analysis”.  As such, it should address overhead analysis and avoid:


  *   Topics that are orthogonal to overhead analysis
  *   The appearance of attempting to position one compression strategy over another for reasons other than overhead

So, I recommend that you make the following changes to Section 5:


  *   The sentence “The mapping proposal, [I-D.bonica-spring-sr-mapped-six], does not bring any compression benefit compared to SRv6-native compression methods [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc]” gives the appearance of author bias. Please replaces it with a neutral sentence like, “The two  proposals [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] [I-D.bonica-spring-sr-mapped-six] provide similar compression.
  *   You say that ” The SRm6 proposal does have several deficiencies however, including:”…. None of these have anything to do with overhead analysis. They don’t belong in this document.
  *   Also, many of the things that you say in that bullet list are blatantly false. For example, SRm6 does not introduce a new data plane. In is extremely orthodox IPv6.

                                                                                                                        Ron





Juniper Business Use Only
From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Darren Dukes (ddukes)
Sent: Saturday, June 27, 2020 1:22 AM
To: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: [spring] Fw: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Hello SPRING working group

There has been lots of work done in SPRING to develop, combine and refine methods of reducing the overhead of the SRv6 SRH.  We have some good submissions of requirements, framework analysis but no direct comparisons of different methods.

This draft kicks off that conversation with a simple analysis comparing SRv6 native compression available via draft-filsfilscheng-spring-srv6-srh-comp-sl-enc vs the mapped SRm6 proposal draft-bonica-spring-sr-mapped-six.


Thanks
  Darren


________________________________
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, June 27, 2020 1:00 AM
To: Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt


A new version of I-D, draft-dukes-spring-srv6-overhead-analysis-00.txt
has been successfully submitted by Darren Dukes and posted to the
IETF repository.

Name:           draft-dukes-spring-srv6-overhead-analysis
Revision:       00
Title:          SRv6 Network Programming Overhead Analysis
Document date:  2020-06-27
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-dukes-spring-srv6-overhead-analysis-00.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-dukes-spring-srv6-overhead-analysis-00.txt__%3B!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjEj0Z_T4%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518585891&sdata=4YF%2Bj3nWlM0mf63hQgSmnADiPyv7LP9UhPHVTNcGUFI%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-dukes-spring-srv6-overhead-analysis/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dukes-spring-srv6-overhead-analysis%2F__%3B!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOMg93gm%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518585891&sdata=yJNsY1WzDbAEhWkewAmuyfaJxZdYitlU%2BQhUyMqyUSI%3D&reserved=0>
Htmlized:       https://tools.ietf.org/html/draft-dukes-spring-srv6-overhead-analysis-00<https://urldefense...com/v3/__https:/tools.ietf..org/html/draft-dukes-spring-srv6-overhead-analysis-00__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjH9AbgoR$>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis<https://urldefense...com/v3/__https:/datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOjtZl8r$>


Abstract:
   SRv6 network programming provides the framework for the best
   compression of an IPv6 header within an SR domain.  This document
   provides the analysis to illustrate this fact.


The IETF Secretariat
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518595889&sdata=wg9dF%2F%2FQbQ6a06DdTYObINRJ3BhqkH%2FAeR2ZejyzN54%3D&reserved=0>
--

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc2ddaad6243b42b9984a08d81b023111%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637289043518595889&sdata=Zyou1NC%2FYObph6JwHpSO%2BMzFxNfcd1BkgKVufWDjqR0%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD