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 <hayabusagsm@gmail.com> 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
>
> [2] https://datatracker.ietf.org/doc/draft-li-spring-compressed-srv6
> -np/?include_text=1
>
> [3] https://datatracker.ietf.org/doc/draft
> -mirsky-6man-unified-id-sr/?include_text=1
>
> [4] https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/
>
> [5] https://datatracker.ietf.org/doc/draft
> -filsfils-spring-net-pgm-extension-srv6-usid/?include_text=1
>
>
> 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
>
> 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=
> 40juniper.net@dmarc.ietf.org> 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 <spring-bounces@ietf.org> *On Behalf Of *Darren Dukes
> (ddukes)
> *Sent:* Saturday, June 27, 2020 1:22 AM
> *To:* SPRING WG <spring@ietf.org>
> *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:* internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Sent:* Saturday, June 27, 2020 1:00 AM
> *To:* Darren Dukes (ddukes) <ddukes@cisco.com>
> *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://urldefense.com/v3/__https:/www.ietf.org/internet-drafts/draft-dukes-spring-srv6-overhead-analysis-00.txt__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjEj0Z_T4$>
> Status:
> https://datatracker.ietf.org/doc/draft-dukes-spring-srv6-overhead-analysis/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-dukes-spring-srv6-overhead-analysis/__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOMg93gm$>
> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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