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

[Gyan Mishra <[e-mail]>]

Thank you Jim, Joel & Bruno for the update.

I am looking forward to the SRv6 compression work being finalized.  This is
a big step forward for SRv6.

Just an idea I am wondering if the official compression update algorithm
that is being finalized should maybe update the two main documents that
make up the SRv6 specification, RFC 8754 and SRV6 PGM draft.

That would make SRH compression solution part of the original SRv6
specification instead of an add on feature to the specification.   Would
make for seamless integration and deployment of the compression technique.


Kind Regards

Gyan


On Sun, Jun 28, 2020 at 5:32 PM James Guichard <
[e-mail]> wrote:

> 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]> 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]> 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]> *On Behalf Of *Darren Dukes
> (ddukes)
> *Sent:* Saturday, June 27, 2020 1:22 AM
> *To:* SPRING WG <[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] <[e-mail]>
> *Sent:* Saturday, June 27, 2020 1:00 AM
> *To:* Darren Dukes (ddukes) <[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]
> 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: 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*
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD