Subject: [Srcomp] Analysis Text: Protocol Design

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 23 Mar 2021 02:32:02 +0000

Following up on last week’s actions, attached is the protocol design analysis text

4.  Protocol Design Requirements

4.1.  SRv6 Base Coexistance

   The compression proposal MUST support deployment in existing SRv6
   networks.

           +-----------------------+------+-----+------+-------+
           |                       | CSID | CRH | VSID | UIDSR |
           +-----------------------+------+-----+------+-------+
           | SRv6 Base Coexistence | Yes  | Yes | Yes  |       |
           +-----------------------+------+-----+------+-------+

   Conclusion: All proposals can be deployed simultaneously with the
   SRv6 base solution.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Mar 2021 15:14:15 +0800

Hi，folks
I don't think this requirement is clear, does it mean "The compression proposal MUST support deployment in existing SRv6 networks without any upgradation or replacement of the existing SRv6-capable equipment" or not? 
Thanks!

Chognfeng

[email-masked]
 
From: Darren Dukes \(ddukes\)
Date: 2021-03-23 10:32
To: [email-masked]
Subject: [Srcomp] Analysis Text: Protocol Design
Following up on last week’s actions, attached is the protocol design analysis text

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 23 Mar 2021 07:22:47 +0000

Hi Chongfeng,

This requirement says that the compression mechanism MUST be capable to co-exist with SRv6.
It does not limit the gradation of the existing SRv6 device.
The solution CAN NOT co-exist with SRv6 is not applicable with this requirement.

So far, I think all compression mechanisms can be deployed with SRv6 simultaneously.
Hope my answer address your question.

Thanks,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 23, 2021 3:14 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Analysis Text: Protocol Design

Hi，folks

Chognfeng

________________________________
[email-masked]<mailto:[email-masked]>

From: Darren Dukes \(ddukes\)<mailto:ddukes=[email-masked]>
Date: 2021-03-23 10:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Srcomp] Analysis Text: Protocol Design
Following up on last week’s actions, attached is the protocol design analysis text

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Mar 2021 15:32:07 +0800

Cheng,
Thank you for your feedback, I view this from the perspective of the equipment, the co-exsitance happens within the same equipment ?
Best regards
Chongfeng

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 15:22
To: [email-masked]; Darren Dukes (ddukes); srcomp
Subject: Re: [Srcomp] Analysis Text: Protocol Design
Hi Chongfeng,

 
Thanks,
Cheng

 
Hi，folks
 
Chognfeng

[email-masked]

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 23 Mar 2021 07:35:30 +0000

I guess we need to update the devices for sure. But some mechanisms require redesigning the chipset, while some mechanism like G-SRv6 only require software update, or some minor microcode update.

So from this requirement, yes, the same equipment.

Thanks,
Cheng

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 3:32 PM
To: Chengli (Cheng Li) <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; srcomp <[email-masked]>
Subject: Re: Re: [Srcomp] Analysis Text: Protocol Design

Cheng,

From: Chengli (Cheng Li)<mailto:[email-masked]>
Date: 2021-03-23 15:22
To: [email-masked]<mailto:[email-masked]>; Darren Dukes (ddukes)<mailto:ddukes=[email-masked]>; srcomp<mailto:[email-masked]>
Subject: Re: [Srcomp] Analysis Text: Protocol Design
Hi Chongfeng,

Thanks,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 23, 2021 3:14 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; srcomp <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Srcomp] Analysis Text: Protocol Design

Hi，folks

Chognfeng

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Mar 2021 15:54:20 +0800

Cheng,
When hardware chipset is redesigned, then the network is not "exsiting network" anymore.  I think we are talking about "Compressed and uncompressed approaches can co-exist on the same equipment", right?

Chongfeng

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 15:35

Thanks,
Cheng

 
Cheng,

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 15:22

 
Thanks,
Cheng

 
Hi，folks
 
Chognfeng

[email-masked]

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 23 Mar 2021 08:15:50 +0000

Hi Chongfeng,

I reread the draft[1], and I think you are correct, and I may be correct as well! The text in the requirement draft describe more details.
So we include multiple requirements in this one☺

Regards,
Cheng

[1]. https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-05#section-5.1

Description: The compression proposal MUST support deployment in
   existing SRv6 networks.

   Rationale: SRv6 is deployed today.  A compression proposal that
   interoperates well with SRv6, as deployed, will reduce the overhead
   and simplify operations.  For Network operators who would migrate to
   compressed SRv6 SID lists, the migration is expected to gradually
   occur over a period of time as they upgrade networks, domains, device
   families and software instances.

   Metric: A compliant compression proposal provides the following

   o  Supports simultaneous deployment at a node with current SRv6 SIDs.
   o  Supports simultaneous deployment at a node with current SRv6
      control plane.
   o  Supports simultaneous operation of current SRv6 paths with
      compressed paths.
   o  Supports the behaviors in
      [I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-05#ref-I-D.ietf-spring-srv6-network-programming>].
   o  Does not require removal of existing IPv6 address planning.

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 3:54 PM
To: Chengli (Cheng Li) <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; srcomp <[email-masked]>
Subject: Re: Re: [Srcomp] Analysis Text: Protocol Design

Cheng,

Chongfeng

Thanks,
Cheng

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, March 23, 2021 3:32 PM
To: Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; srcomp <[email-masked]<mailto:[email-masked]>>
Subject: Re: Re: [Srcomp] Analysis Text: Protocol Design

Cheng,

Thanks,
Cheng

Hi，folks

Chognfeng

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 23 Mar 2021 16:28:03 +0800

Cheng,
I found none of requirement in the list make sure that the network is "existing network".

Chongfeng 

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 16:15
 
I reread the draft[1], and I think you are correct, and I may be correct as well! The text in the requirement draft describe more details.
So we include multiple requirements in this oneJ
 
Regards,
Cheng

 

      [I-D.ietf-spring-srv6-network-programming].

 
 
Cheng,
 
Chongfeng

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 15:35

Thanks,
Cheng

 
Cheng,

[email-masked]
 
From: Chengli (Cheng Li)
Date: 2021-03-23 15:22

 
Thanks,
Cheng

 
Hi，folks
 
Chognfeng

[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Tue, 23 Mar 2021 13:56:49 +0000

Darren,

Same comment here. We should explain *why* we think that each solution satisfies the requirement.

                                                                              Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, March 22, 2021 10:32 PM
To: [email-masked]
Subject: [Srcomp] Analysis Text: Protocol Design

[External Email. Be cautious of content]

Following up on last week's actions, attached is the protocol design analysis text

---

From: Ron Bonica <[email-masked]>
Date: Tue, 23 Mar 2021 14:36:59 +0000

Cheng,

Which of the following are you suggesting:

  *   That the compression mechanism MUST be supportable on all existing SRv6 chipsets
  *   That the compression mechanism MUST be supportable on at least one existing SRv6 chipset
  *   That it must be possible to implement the compression mechanism on a chipset that also support uncompressed (classic) SRv6

                                                                          Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Tuesday, March 23, 2021 4:16 AM
To: [email-masked]; Darren Dukes (ddukes) <ddukes=[email-masked]>; srcomp <[email-masked]>
Subject: Re: [Srcomp] Analysis Text: Protocol Design

Hi Chongfeng,

I reread the draft[1], and I think you are correct, and I may be correct as well! The text in the requirement draft describe more details.
So we include multiple requirements in this one:)

Regards,
Cheng

      [I-D.ietf-spring-srv6-network-programming<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-05*ref-I-D.ietf-spring-srv6-network-programming__;Iw!!NEt6yMaO-gk!TV5hSgSquqSdujOegVbKE4Qz2IWK5Cj602eyuJoX5M1DCMCEohDbFrxKNwmRkD38$>].

Cheng,

Chongfeng

Thanks,
Cheng

Cheng,

Thanks,
Cheng

Hi，folks

Chognfeng