Re: [Srcomp] Todays text

Hi Darren,

I also noticed that END.XPS behavior from VSID has been merged into CSID.
IMO, END.XPS behavior, and END.BS flavor (see https://datatracker.ietf.org/doc/draft-peng-spring-truncated-sid-inter-domain/) are both independent with the specific compression scheme, i.e., any scheme can refter to these basic behavior or flavor. Do you think so ?
BTW, END.XPS is just a variant of END.X, while END.BS flavor is not limited to END.X case.

Regards,
PSF

------------------原始邮件------------------
发件人：DarrenDukes(ddukes)
收件人：Ron Bonica;Darren Dukes (ddukes);srcomp@ietf.org;
日 期 ：2021年07月07日 18:18
主 题 ：Re: [Srcomp] Todays text
--
Srcomp mailing list
Srcomp@ietf.org
https://www.ietf.org/mailman/listinfo/srcomp
We did complete analysis of vsid. It has documented a prefix change sid for a long time.
As mentioned, the csid would use the sid behavior as defined in the vsid draft. Now csid is updated with the end.vxps behavior from vsid. It seems to me that we can now conclude this section and be done with the analysis.
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-00
Darren
From: Srcomp <srcomp-bounces@ietf.org> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Sent: Tuesday, July 6, 2021 6:00 PM
To: Darren Dukes (ddukes); srcomp@ietf.org
Subject: Re: [Srcomp] Todays text
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=40cisco.com@dmarc.ietf.org>
Sent: Tuesday, July 6, 2021 4:20 PM
To: Ron Bonica <rbonica@juniper.net>; srcomp@ietf.org
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 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" <srcomp-bounces@ietf.org> 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