Re: [Srcomp] Todays text

[Ron Bonica <[e-mail]>]

Darren,

AFAIKS, there has been no progress since last week. Namely,


  *   The CSID document has not been updated
  *   Since the document has not been updated, we really can’t tell how it will affect other sections of the draft (2.3?, 3.1?)
  *   We haven’t dealt with the case of a single area with multiple address blocks

A wise man once said nothing.

A slightly less wise man once said that the definition of insanity is to do the same thing twice, expecting different results each time.

What inputs to tomorrow’s meeting will be different from the inputs to last week’s meeting?

                                                                Ron

P.S. I guess that I am not wise enough to say nothing 😉




Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[e-mail]>
Sent: Tuesday, July 6, 2021 4:20 PM
To: Ron Bonica <[e-mail]>; [e-mail]
Subject: Re: Todays text

[External Email. Be cautious of content]

A short update on this topic.

The update is nearly done for the CSID draft.  The text will be nearly identical to https://www.ietf.org/archive/id/draft-decraene-spring-srv6-vlsid-05.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-decraene-spring-srv6-vlsid-05.txt__;!!NEt6yMaO-gk!Xuow5soVRsSOecGNea6e0KOLBqv1HJN1mAms3uxuqJCIa8oCT_iGZ8WXCCQh2Hy_$> section 6.2, which has been analyzed by the team already.

As discussed last week, paragraph 1 of the NEW text is good for me.  The second paragraph is not needed, nor are additional tables needed.

We made a decision several months ago, as a team, to provide compression tables for 0-15 transport segments and one VPN segment.  We mention when additional segments are required and the existing tables describe the relevant encapsulation size.

Given the previous decision on section 2 tables, I believe we can wrap up this section with the content of the first paragraph.

NEW>
All compression mechanism provide the encapsulation saving described in Tables 1 and 2. CRH provides this encapsulation savings regardless of the IPv6 addressing scheme. CSID adds a CSID container, or one compressed SID, for each change in locator block in a segment list. VSID and UIDSR add one compressed SID for each change in locator block in the segment list.
<NEW

Thanks
  Darren


On 2021-06-30, 10:52 AM, "Srcomp" <[e-mail]<mailto:[e-mail]>> wrote:

Folks,

This is where we left the conversation today. I don’t think that we have quite agreed on the text below, but we are getting close.

The only action item is for Darren to update the CSID draft so we know how the new SID flavor works and what else it impacts.

                                                                            Ron



OLD>
Compression mechanisms ABC and D provide the encapsulation savings described in Table 1 and 2 regardless of the addressing scheme. Compression mechanism, W, X, Y and Z only provide the encapsulation savings described in Table 1 and 2 when every CSID in the SR path shares a common Locator Block. When they do not share a common locator block, encapsulation savings ranges from LowValue to HighValue.
<OLD

NEW>
All compression mechanism provide the encapsulation saving described in Tables 1 and 2. CRH provides this encapsulation savings regardless of the IPv6 addressing scheme. CSID adds a CSID container, or one compressed SID, for each change in locator block in a segment list. VSID and UIDSR add one compressed SID for each change in locator block in the segment list.

Tables X and Y provide the same data as Tables 1 and 2, when there are three Locator block changes as depicted in Figure A. This data is supported by the Appendix Whatever.

<NEw




Juniper Business Use Only