Re: [Srcomp] Section 3.3.3

[[e-mail]]

Hi Team,

Sorry to see the email so late.
I agree with the text, except for some spelling mistakes.

Regards,
PSF




------------------原始邮件------------------
发件人：DarrenDukes(ddukes)
收件人：Darren Dukes (ddukes);Ron Bonica;Chengli (Cheng Li);[e-mail];
日 期 ：2021年06月11日 19:39
主 题 ：Re: [Srcomp] Section 3.3.3
--
Srcomp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/srcomp

Any thoughts on this before the meeting today?
Peng, Cheng and Ron, I believe this is accurate for all proposals.  If you have any comments it would be good to see email first and I can add it to the pptx deck.
Darren
On 2021-06-09, 9:54 PM, "Srcomp" <[e-mail]> wrote:
The following is more accurate as a note prior to the conclusion.

Note: Utilizing segments in multiple SR sub-domains, as illustrated in Section 2.1.1 of this document, may require an additional segment in the segment list.  When sub-domains utilize different SRv6 blocks, the CSID, VSID and UIDSR proposals include either  one additional segment in the segment list per sub-domain to swap the SRv6 block, or use an uncompressed SID in the SRH with the new block.
The CRH proposal does not require a locator swap to utilize segments in different sub-domains since its compression is independent of the IPv6 number space, however it does require an additional  CSID in its segment lists per sub-domain to traverse different CSID number spaces per sub-domain.
Conclusion: All compression mechanisms support flexible IPv6 planning.
Darren
On 2021-06-07, 8:12 PM, "Srcomp" <[e-mail]> wrote:
Cheng Li,
I would agree with the “Yes” under CSID if it were followed by this conclusion:
Conclusion: All compression mechanisms support flexible IPv6 planning.
However, the CSID provides the encapsulation savings described in Section 2.1.1 of this document only when all CSIDs in an SR Path share a single Locator Block. When the CSIDs in an SR Path are drawn from different  locator blocks, encapsulation savings range from 0 to the values state in Section 2.1.1. The CRH provides the encapsulation savings described in Section 2.1.1 of this document regardless of the network addressing plan.
Ron
Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]>
Sent: Monday, June 7, 2021 2:50 AM
To: Ron Bonica <[e-mail]>; [e-mail]
Subject: RE: Section 3.3.3
[External Email. Be cautious of content]
3.3.3.  Address Planning
Description: Network operators require addressing plan flexibility,
The compression mechanism MUST support flexible IPv6 address
planning, it MUST support deployment by using GUA from different
address blocks.
+---------------------------+------+-----+------+-------+
|                           | CSID | CRH | VSID | UIDSR |
+---------------------------+------+-----+------+-------+
| Flexible Address Planning |  yes | Yes |  yes |       |
+---------------------------+------+-----+------+-------+
Address Planning
From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Thursday, June 3, 2021 11:37 PM
To: [e-mail]
Subject: [Srcomp] Section 3.3.3
3.3.3.  Address Planning
Description: Network operators require addressing plan flexibility,
The compression mechanism MUST support flexible IPv6 address
planning, it MUST support deployment by using GUA from different
address blocks.
+---------------------------+------+-----+------+-------+
|                           | CSID | CRH | VSID | UIDSR |
+---------------------------+------+-----+------+-------+
| Flexible Address Planning |      | Yes |      |       |
+---------------------------+------+-----+------+-------+
Address Planning
Juniper Business Use Only