Subject: [Srcomp] Section 3.4 Scalability Requirements

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 12 May 2021 11:06:44 +0000

Below is the discussion text that we should include in this section:

The 32-bit variants of all proposals support this scale of prefix, adjacency and services at a node.

Each proposals 16-bit variant has some ability to support the required scale.  All proposals can encode at least 2^16 prefix, adjacency and service segments.  However each proposal has various ways of supporting some larger scale per node if required.

CRH 16-bit proposes the encoding of the ultimate segment in a TPF destination option instead of the CRH.  This supports service segments with greater scale.

VSID proposes the combination of multiple vSIDs, or the use of multiple SRv6 blocks.  This supports adjacency and service segments with greater scale.

CSID 16-bit variant uses a LIB for adjacency and service segments, the LIB allows local definition of SIDs longer than 16-bits when needed.  This supports adjacency and service segments with greater scale.

UIDSR – ShaoFu?

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 May 2021 15:30:32 +0000

Folks,

I think that we are wrestling with this issue too vigorously. The following text would suffice.

"The 32-bit variants of all proposals support this scale of prefix, adjacency and services at a node. The 16-bit variants all support a similar but lesser degree of scaling".

The bitter truth is that there is no way to fit 1,000,000 pieces of information in fewer than 20 bits. Each proposal has some clever method of encoding 1.000,000 pieces of information in two 16-bit SIDS. But there is no difference between two 16-bit SIDs and a single 32-bit SID.

                                                                                               Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, May 12, 2021 7:07 AM
To: [email-masked]
Subject: [Srcomp] Section 3.4 Scalability Requirements

[External Email. Be cautious of content]

UIDSR - ShaoFu?

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 12 May 2021 17:18:50 +0000

Hi Ron, I think your observation is valid but since we have requirements for scale and various compression levels, we owe a few sentences of context for each proposal’s 16-bit variant and it’s scalability.  I think we have that text now and will soon be able to close these notes (pasted below from todays call).

Each proposal’s 16-bit variant supports a lesser scale. All proposals can encode 2^16 prefix, adjacency and service segments. However, each proposal has various ways of supporting some larger scale per node if required.

CRH 16-bit proposes the encoding of the ultimate segment in a TPF destination option instead of the CRH. This supports 2^32 service segments per node.

VSID proposes the combination of multiple vSIDs. This supports adjacency and service segments with greater scale.

UIDSR: PSF to send text: Very similar to VSID, with a global and a local identifier

On 2021-05-12, 11:30 AM, "Srcomp" <[email-masked]> wrote:

Folks,

“The 32-bit variants of all proposals support this scale of prefix, adjacency and services at a node. The 16-bit variants all support a similar but lesser degree of scaling”.

                                                                                               Ron

UIDSR – ShaoFu?

---

From: Ron Bonica <[email-masked]>
Date: Wed, 12 May 2021 17:51:09 +0000

Darren,

If we must have this text, the following is more accurate:

OLD> This supports adjacency and service segments with greater scale.
NEW> This satisfies requirement, but may require two 16-bit SIDs and the same overhead as a single 32-bit SID.

This text appear under CSID and VSID.

                                          Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, May 12, 2021 1:19 PM
To: Ron Bonica <rbonica=[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; [email-masked]
Subject: Re: [Srcomp] Section 3.4 Scalability Requirements

Hi Ron, I think your observation is valid but since we have requirements for scale and various compression levels, we owe a few sentences of context for each proposal's 16-bit variant and it's scalability.  I think we have that text now and will soon be able to close these notes (pasted below from todays call).

Each proposal's 16-bit variant supports a lesser scale. All proposals can encode 2^16 prefix, adjacency and service segments. However, each proposal has various ways of supporting some larger scale per node if required.

On 2021-05-12, 11:30 AM, "Srcomp" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

                                                                                               Ron

Juniper Business Use Only
From: Srcomp <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, May 12, 2021 7:07 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Srcomp] Section 3.4 Scalability Requirements

UIDSR - ShaoFu?

---

From: <[email-masked]>
Date: Thu, 13 May 2021 09:36:03 +0800 (CST)

Hi Team,

The following is reply for UIDSR:

UIDSR uses  global SID (e.g, a single END.T.X for wildcard adjacency segments) plus local index (e.g, interface-id for each L3 adjacency) to represent a complete segment when 16 bits is not enough to represent the required global segments.The local index can be 16 bits, 32 bits.

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2021年05月12日 19:07
主 题 ：[Srcomp] Section 3.4 Scalability Requirements

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

 

 

 

 

 

 

UIDSR – ShaoFu?

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 May 2021 11:10:13 +0000

Hi Ron, see inline (DD)

________________________________
From: Ron Bonica <rbonica=[email-masked]>

Darren,

(DD) that’s not quite accurate since any length can be used for csid.  I suppose we should apply the same logic to the last sentence of crh too ‘but requires a 64-bit TPF destination option and the same overhead as four 16-bit SIDs”.

                                          Ron

Folks,

                                                                                               Ron

UIDSR – ShaoFu?

---

From: Ron Bonica <[email-masked]>
Date: Thu, 13 May 2021 15:41:15 +0000

Darren,

Are we really arguing about how we fit 1,000,000 pieces of information into 16 bits?

                                                                                                 Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Thursday, May 13, 2021 7:10 AM
To: Ron Bonica <rbonica=[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: Section 3.4 Scalability Requirements

Hi Ron, see inline (DD)

________________________________
From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>

Darren,

(DD) that's not quite accurate since any length can be used for csid.  I suppose we should apply the same logic to the last sentence of crh too 'but requires a 64-bit TPF destination option and the same overhead as four 16-bit SIDs".

                                          Ron

To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>; [email-masked]<mailto:[email-masked]>

Folks,

                                                                                               Ron

UIDSR - ShaoFu?

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 13 May 2021 18:33:24 +0000

No argument here Ron.  I think a few words in this section to talk about scalability with 16bit variants and their limitations and capabilities across these three dimensions of scale is a good idea.

Darren

________________________________
From: Ron Bonica <[email-masked]>
Sent: Thursday, May 13, 2021 11:41 AM
To: Darren Dukes (ddukes); Ron Bonica; [email-masked]
Subject: RE: Section 3.4 Scalability Requirements

Darren,

                                                                                                 Ron

Hi Ron, see inline (DD)

Darren,

                                          Ron

Folks,

                                                                                               Ron

UIDSR – ShaoFu?

---

From: Ron Bonica <[email-masked]>
Date: Thu, 13 May 2021 19:54:05 +0000

Darren,

If we must...... If you propose CSID text, I will mimic the style with CRH text,

                                                                                              Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Thursday, May 13, 2021 2:33 PM
To: Ron Bonica <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: Section 3.4 Scalability Requirements

Darren

________________________________
From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 13, 2021 11:41 AM
To: Darren Dukes (ddukes); Ron Bonica; [email-masked]<mailto:[email-masked]>
Subject: RE: Section 3.4 Scalability Requirements

Darren,

                                                                                                 Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 13, 2021 7:10 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Section 3.4 Scalability Requirements

Hi Ron, see inline (DD)

Darren,

                                          Ron

Folks,

                                                                                               Ron

UIDSR - ShaoFu?