Re: [Srcomp] Draft meeting minutes: 4/14/2021

Sent on behalf of peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn> (srcomp@ mailarchive did not archive the original correctly)

On 2021-04-19, 10:57 PM, "Srcomp" <srcomp-bounces@ietf.org> wrote:

Hi Team,

Please see below for UIDSR analysis result:

3.1.  SRv6 Based

U.RFC8402 // Yes.

U.RFC8754 // Yes, introduce new Flags in SRH.Flags field.

U.PGM    // Yes, introduce new Flavors of current SID to indicate how to decap next SID in SRH.

U.IGP         // Yes, need more extensions to advertise the capability of U-SID compression (32bits, 16bits, etc...)

                      For compression enhancement, draft-cp-spring-srv6-sid-allocation also introduce "Global Container SID + local index" to save SIDs resource.

U.BGP        // Yes.

                      Also for compression enhancement, VPN SID can also be "Global Container SID + local index".

U.POL        // Yes.

U.BLS        // Yes, with more extensions according to IGP extensions.

U.SVC       // Yes. Service Function SID need also to be compressed.

                     Also for compression enhancement, Service Function SID can also be "Global Container SID + local index".

U.ALG       // Yes.

U.OAM      // Yes.

3.2.1.  SRv6 Functionality

F.SID       // Yes, with "Global Container SID + local index" enhancement.

F.Scope   // Yes, with "Global Container SID + local index" enhancement.

F.PFX      // Yes.

F.ADJ      // Yes, with "Global Container SID + local index" enhancement.

F.BIND    // Yes. BSID can also be compressed.

F.PEER   // Yes. EPE SID can also be compressed.

                    For compression enhancement, draft-peng-spring-truncated-sid-inter-domain also introduce "Block Siwitch" to indicate the new Block of the next domain.

F.SVC     // Yes. Service Function SID need also to be compressed. Note "Global Container SID + local index" enhancement.

F.ALG     // Yes.

F.TILFA   // Yes. For protections described in section 6.1.2.1, 6.1.2.2, and 6.2, to get next-next SID from SRH with the help of draft-pl-spring-compr-path-recover.

F.SEC     // Yes.

F.IGP      // Yes. need more extensions to advertise the capability of U-SID compression (32bits, 16bits, etc...). Note "Global Container SID + local index" enhancement.

F.BGP     // Yes, with "Global Container SID + local index" enhancement. VPN SID can also be compressed.

F.POL     // Yes.

F.BLS     // Yes, with more extensions according to IGP extensions.

F.SFC     // Yes, with "Global Container SID + local index" enhancement. SF SID can also be compressed.

F.PING    // Yes.

3.2.2.  Heterogeneous SID Lists

Heterogeneous SID Lists  // Yes. Any type and length of SIDs can be encoded in a single SRH. However, UIDSR does not suggest this feature, but same fixed length of all SIDs in the SRH.

3.2.3.  SID List Length

16 Segments    //Yes

3.2.4.  SID Summarization

SID Summarization  // Yes for stiching mode. For mapping mode, an additional global prefix segment is required for each domain border to be traversed.

3.3.1.  Lossless Compression

Lossless Compression  // Yes.

3.4.  Scalability Requirements

Adjacency Segment Scale 65000  // This is related to the actual address planning of the operator. If there are more bits to encode the required adjacency functions, that is ok. Otherwise, "Global Container SID + local index" can be considered.

Prefix Segment Scale 1000000   // See above.

Service Scale 1000000          // See above.

Regards,

PSF

原始邮件
发件人：RonBonica
收件人：srcomp;
日 期 ：2021年04月14日 22:34
主 题 ：[Srcomp] Draft meeting minutes: 4/14/2021
--
Srcomp mailing list
Srcomp@ietf.org
https://www.ietf.org/mailman/listinfo/srcomp
Attendees: Weiqiang,  Ron, Cheng, Darren, Wim

RESOLVED
=========

・         Darren will copy the data provided below into the appropriate tables in the analysis document. This data is not final. The DT will resolve disputed conclusions on its mailing list.

DISCUSSED
=========

・         The data provided below was compiled.

ACTION ITEMS
============

・         Ron and Darren will meet on Thursday to continue work on Section 2.

・         Ron will provide further information on Section 3.1

DATA to be copied into the analysis draft
=================================

CRH
3.1
8402 yes
8754-na
pgm-yes (to what degree?)
igp-no (draft)
bgp-no (draft)
pol-??
BLS-??
SVC-no (draft)
OAM-??
ALG-no (draft)

3.2.1
FSID - Compliant
FSCOPE - Compliant
F.PFX - Compliant
F.ADJ - Compliant
F.BIND - Compliant
F.PEER - specification required
F.SVC - compliant
F.ALG - compliant (see IP Flexalgo draft)
F.TILFA - compliant
F.SEC - Compliant
F.IGP - Compliant ( see ISIS CRH draft)
F.BGP - Compliant (see CRH BGP draft)
F.POL - compliant
F.BLS - specification required
F.SFC - compliant
F.PING: compliant
TODO: add specification where defined

3.2.2 Compliant.

Satisfies this requirement by using a binding SID to impose an additional SRv6 header (IPv6 header plus optional SRH) with non-compressed SID.

3.2.3. Compliant. See Section 2.1. for compression at each SR path length.

3.2.4. Not compliant

3.3.1. Compliant. And classic SID can be represented by a CRH SID.

3.3.2. Compliant.

3.3.3. Compliant.

3.4 Compliant. The 16-bit CRH SID can represent 65K objects. The 32-bit SID and TPF can represent 4G objects.

3.4.4 Compliant. 16 and 32

CSID
Ron notes OAM o-bit when no RH is needed.

VSID
3.2.1
Wim: notes may have trouble with U.SVC
Wim: does vSID in fact support other SID types?  The draft only talks about adj SIDs optimization. Cheng Li indicates the draft only describes one example.
Perhaps we need more details per specification?

Juniper Business Use Only