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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 27 Jun 2020 05:21:37 +0000

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: [email-masked] <[email-masked]>
Sent: Saturday, June 27, 2020 1:00 AM
To: Darren Dukes (ddukes) <[email-masked]>
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
Status:         https://datatracker.ietf.org/doc/draft-dukes-spring-srv6-overhead-analysis/
Htmlized:       https://tools.ietf.org/html/draft-dukes-spring-srv6-overhead-analysis-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis

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

---

From: Ron Bonica <[email-masked]>
Date: Sat, 27 Jun 2020 23:44:47 +0000

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 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Saturday, June 27, 2020 1:22 AM
To: SPRING WG <[email-masked]>
Subject: [spring] Fw: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

[External Email. Be cautious of content]

Thanks
  Darren

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

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:

The IETF Secretariat

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Jun 2020 21:13:26 -0400

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=[email-masked]> 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
>  
> 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
>  
>  
>  
>  
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 27 Jun 2020 21:25:24 -0400

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 <[email-masked]> 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*
>
> [3] https://datatracker.ietf.org/doc/draft
> -mirsky-6man-unified-id-sr/?include_text=1
>
> [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.
>
>
> 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:
>
> 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
>
> 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
>
>
>
>    - 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
>
>
>
>
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Darren Dukes
> (ddukes)
> *Sent:* Saturday, June 27, 2020 1:22 AM
> *To:* SPRING WG <[email-masked]>
> *Subject:* [spring] Fw: New Version Notification for
> draft-dukes-spring-srv6-overhead-analysis-00.txt
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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:* [email-masked] <[email-masked]>
> *Sent:* Saturday, June 27, 2020 1:00 AM
> *To:* Darren Dukes (ddukes) <[email-masked]>
> *Subject:* New Version Notification for
> draft-dukes-spring-srv6-overhead-analysis-00.txt
>
>
>
>
> 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:
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: James Guichard <[email-masked]>
Date: Sun, 28 Jun 2020 21:32:07 +0000

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 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Saturday, June 27, 2020 9:25 PM
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Daren

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>

Dear SPRING,

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>

Sent from my iPhone

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

Darren,

  *   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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Saturday, June 27, 2020 1:22 AM
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Fw: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Thanks
  Darren

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:

The IETF Secretariat
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 29 Jun 2020 02:46:05 -0400

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 <
[email-masked]> 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 <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* Saturday, June 27, 2020 9:25 PM
> *To:* Ron Bonica <rbonica=[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Darren Dukes (ddukes) <ddukes=
> [email-masked]>
> *Subject:* Re: [spring] New Version Notification for
> [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>
>
> <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>
>
>
>
> 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://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
> <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://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://urldefense...com/v3/__https:/tools.ietf..org/html/draft-dukes-spring-srv6-overhead-analysis-00__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjH9AbgoR$>
> Htmlized:
> <https://urldefense...com/v3/__https:/datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOjtZl8r$>
>
>
> Abstract:
> <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>
>
> --
>
> <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>
>
>
>
-- 

*Gyan Mishra*

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 30 Jun 2020 01:33:04 +0000

Hi Ron. Thanks for reading the document.

You say about section 5:
> 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.

SRm6 uses IPv6 for transport and it introduces a dataplane that maps 32 or 16 bit identifiers to a behavior and IPv6 address. Every SRm6 node must use this new dataplane implementation.  This is correct.

I believe the bullets I listed are relevant when holistically considering the proposals.

Sincerely,
  Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]>
Sent: Saturday, June 27, 2020 7:44:47 PM
To: Darren Dukes (ddukes) <[email-masked]>; SPRING WG <[email-masked]>
Subject: RE: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Darren,

                                                                                                                        Ron

Thanks

  Darren

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:

The IETF Secretariat

---

From: Ron Bonica <[email-masked]>
Date: Tue, 30 Jun 2020 02:59:04 +0000

Darren,

The 6man WG is responsible for exactly one data plane. That is, IPv6.

IPv6 is extensible. So, new Routing headers and Options can be defined  without creating a new data plane. That's the whole idea of IPv6 extensibility. Do you believe new data planes were created when the following were defined:

  *   The NIMROD Routing header
  *   They Type 2 Routing header
  *   The RPL Routing header
  *   The Segment Routing Header

Also, the bullets under discussion have little to do with an "SRv6 Network Programming Overhead Analysis".

If your real goal is holistic comparison of SRm6 and draft-filfilscheng-srv6-srh-comp-sl-eng, I would be glad to work with you on that. But a holistic comparison should probably have representation from both sides. Otherwise, it is mere marketing.

                                                    Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Monday, June 29, 2020 9:33 PM
To: Ron Bonica <[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Sincerely,
  Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Saturday, June 27, 2020 7:44:47 PM
To: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Darren,

                                                                                                                        Ron

Thanks

  Darren

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:/urldefense...com/v3/__https:/tools.ietf..org/html/draft-dukes-spring-srv6-overhead-analysis-00__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjH9AbgoR$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAYtsAIIb$>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis<https://urldefense.com/v3/__https:/urldefense...com/v3/__https:/datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOjtZl8r$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAXN2pMyI$>

Abstract:

The IETF Secretariat

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 30 Jun 2020 07:20:40 +0000

Hi Guru,
In my humble opinion statement that something compressed is not a new data plane could be a little wrong.
Genesis of the solution (all solutions comes from extension capabilities of IPv6) could only permit to tell that it is "the same protocol", or more precise "extension of the same protocol".
But if new forwarding table (with shorter labels) should be created in PFE - then it is probably new data plane. It occupies separate resources in data plane.
Eduard
From: spring [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: 30 июня 2020 г. 5:59
To: Darren Dukes (ddukes) <ddukes=[email-masked]>; SPRING WG <[email-masked]>
Subject: Re: [spring] New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Darren,

-        The NIMROD Routing header
-        They Type 2 Routing header
-        The RPL Routing header
-        The Segment Routing Header

                                                    Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Sent: Monday, June 29, 2020 9:33 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Sincerely,
  Darren

Darren,

·        Topics that are orthogonal to overhead analysis

·        The appearance of attempting to position one compression strategy over another for reasons other than overhead

·        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

Thanks

  Darren

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:/urldefense...com/v3/__https:/tools.ietf..org/html/draft-dukes-spring-srv6-overhead-analysis-00__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjH9AbgoR$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAYtsAIIb$>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis<https://urldefense..com/v3/__https:/urldefense...com/v3/__https:/datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOjtZl8r$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAXN2pMyI$>

Abstract:

The IETF Secretariat

---

From: Ron Bonica <[email-masked]>
Date: Tue, 30 Jun 2020 11:40:51 +0000

Hello friend,

SRv6 and SRm6 contain the same information in their FIBs. The difference is that the FIBs are structured differently.

Are you assuming that a change in FIB structure constitutes a new forwarding plane. Can you find any text in the IPv6 specifications that support this assumption?

Exploring the other side of the coin, the RFC 4291 definition of an IPv6 address is very different from draft-filsfilscheng-spring-srv6-srh-comp-sl-enc definition of a C-SID container. Yet both can be placed in the destination address field of an IPv6 header. Is this still IPv6, or have we created a new data plane?

                                                                 Ron

Juniper Business Use Only
From: Vasilenko Eduard <[email-masked]>
Sent: Tuesday, June 30, 2020 3:21 AM
To: Ron Bonica <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; SPRING WG <[email-masked]>
Subject: RE: New Version Notification for draft-dukes-spring-srv6-overhead-analysis-00.txt

Hi Guru,
To: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>

Darren,

                                                    Ron

Sincerely,
  Darren

Darren,

                                                                                                                        Ron

Thanks

  Darren

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:/urldefense...com/v3/__https:/urldefense...com/v3/__https:/tools.ietf..org/html/draft-dukes-spring-srv6-overhead-analysis-00__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjH9AbgoR$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAYtsAIIb$__;!!NEt6yMaO-gk!RxsuHx0YNYzQXzJ2rt5ZSZGFNHR3iYYUrPbwro_OkcXlb76SiuIv7eLzJm4pyMMH$>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis<https://urldefense.com/v3/__https:/urldefense...com/v3/__https:/urldefense...com/v3/__https:/datatracker.ietf.org/doc/html/draft-dukes-spring-srv6-overhead-analysis__;!!NEt6yMaO-gk!XQ30Nxg22KtJi8ikwlkNqwrZPkBjF4IixztGJYkMVwpqxc8PEt_xKQSRjOjtZl8r$__;!!NEt6yMaO-gk!QrTNpOov227mx78vk0QW9dUiezD-3jNSo7hrwU5wJzCSX8FX6z6L4BIiAXN2pMyI$__;!!NEt6yMaO-gk!RxsuHx0YNYzQXzJ2rt5ZSZGFNHR3iYYUrPbwro_OkcXlb76SiuIv7eLzJvAzSORN$>

Abstract:

The IETF Secretariat