Subject: Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST

From: <[email-masked]>
Date: Fri, 2 Oct 2020 10:51:05 +0800 (CST)

Hi Darren, Ron,

I think that could be important for a brownfield deployment scenario but not as critical in a greenfield case.

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：Ron Bonica;srcomp;
日 期 ：2020年09月30日 13:33
主 题 ：Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST

-- 
Srcomp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/srcomp

Hi Ron

The metric states that a proposal permits the use of compressed and non-compressed segments within a segment list.

"A solution that supports compressed and non-compressed segments, and allows their combination within
 a segment list meets this requirement."

The benefits to deployment seem clear.  Some nodes support the compression solution while others do
 not yet, the service is incrementally upgradable.

Darren

--------------------------------------------------------------------------------

From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Tuesday, September 29, 2020 4:39 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] comments on REQ-8-26-HET-SID-LIST 

Folk,

The rationale for this requirement are dubious.

You are proposing that SR ingress nodes must support the following SR encoding:

Legacy SRv6

Compressed

Hybrids containing Legacy encoding features and compressed encoding features

The rational are:

That this supports one particular transition strategies

That some nodes may not require compression

Other, more frequently deployed transition strategies are available. And what is the motivation for using classing encoding when compression is available?

                                                                       Ron

 

 

Juniper Business Use Only

---

From: Ron Bonica <[email-masked]>
Date: Fri, 2 Oct 2020 16:22:29 +0000

PSF,

In a brownfield, wouldn’t it make more sense to migrate as follows:

Day
SRH Capable
Compression Capable
Encoding
1
All nodes
No Nodes
All packets use SRH.
No packets use compression
2
All nodes
Some Nodes
All packets use SRH.
No packets use compression
3
All nodes
Some nodes
Packets that traverse upgraded nodes only use compression mechanism only.
All remaining packets use SRH only.
4
All nodes
All Nodes
Packets that traverse upgraded nodes only use compression mechanism only.
All remaining packets use SRH only.
5
All nodes
All nodes
All packets use compression
No packets use SRH

The benefit of this is that we don’t need to support a hybrid encapsulation that supports SRH and compression.

                                                                                                        Ron

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Thursday, October 1, 2020 10:51 PM
To: [email-masked]
Cc: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re:[Srcomp] comments on REQ-8-26-HET-SID-LIST

[External Email. Be cautious of content]

Hi Darren, Ron,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：Ron Bonica;srcomp;
日 期 ：2020年09月30日 13:33
主 题 ：Re: [Srcomp] comments on REQ-8-26-HET-SID-LIST
--
Srcomp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/srcomp
Hi Ron

"A solution that supports compressed and non-compressed segments, and allows their combination within a segment list meets this requirement."

The benefits to deployment seem clear.  Some nodes support the compression solution while others do not yet, the service is incrementally upgradable.

Darren
________________________________
From: Srcomp <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Tuesday, September 29, 2020 4:39 PM
To: srcomp <[email-masked]<mailto:[email-masked]>>
Subject: [Srcomp] comments on REQ-8-26-HET-SID-LIST

Folk,

  *   Legacy SRv6
  *   Compressed
  *   Hybrids containing Legacy encoding features and compressed encoding features

The rational are:

  *   That this supports one particular transition strategies
  *   That some nodes may not require compression

                                                                       Ron