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

Hi Team,

For the following question:

"If segment list is <U-32,U-128, U-32,U-32> is padding required?  I did not see that in the draft, i.e how does this work . <U-32,U-128,pad,pad,U-32,U-32>"

The answer is: 

Yes, it requires padding, because each type of SID must be placed in SRH with aligned with the length of that type.

In detailed, suppose the above SID list is <U1-32,U2-128, U3-32,U4-32> , then the SIDs encoded in SRH originated by headend is like below:

    IPv6 Header: DA = U1-128

    SRH:

        128-bits-item[0] : pad0(64-bits), U4-32, U3-32

        128-bits-item[1]: U2-128

        128-bits-item[2]: pad0(96-bits), U1-32

The headend originated the packet, with SRH.flag = UET-32, and Segment Left = 3*4-1 = 11.

When packet is received by U1 segment node, since local SID entry for U1-SID has UET-128 flavor that indicates to get next 128-bits from SRH. Firtly, SRH.flag is changed to UET-128 (i.e, flag unset), Segment Left = 11/4 = 2. Secondly, traditional processing is executed: Segment Left --, read next 128-bits item, i.e.,  U2-128, from List[Segment Left], and pad0(96-bits) is ignored.

When packet is received by U2 segment node, since local SID entry for U2-SID has UET-32 flavor that indicates to get next 32-bits from SRH. Firtly, SRH.flag is changed to UET-32, Segment Left = 1*4 = 4. Secondly, similar to traditional processing: Segment Left --, read next 32-bits item, i.e, U3-32, from List[Segment Left];

When packet is received by U3 segment node, since local SID entry for U3-SID has UET-32 flavor that indicates to get next 32-bits from SRH. There is no change for SRH.flag. Thus, similar to traditional processing: Segment Left --, read next 32-bits item, i.e., U4-32, from List[Segment Left];

When packet is received by U4 segment node, since local SID entry for U4-SID has UET-128 flavor that indicates to get next 128-bits  from SRH. Firtly, SRH.flag is changed to UET-128 (i.e, flag unset), Segment Left = 2/4 = 0. At this time, it finds that no segments are left to be visited, and and pad0(64-bits) is ignored.

Regards,

PSF

原始邮件

发件人：RonBonica
收件人：srcomp@ietf.org;
日 期 ：2021年04月22日 04:35
主 题 ：[Srcomp] Draft meeting minutes: 4/21/2021

--  
Srcomp mailing list
Srcomp@ietf.org
https://www.ietf.org/mailman/listinfo/srcomp

Attendees: Weiqiang, Chongfeng, Ron, Cheng, Darren, Peng

Resolved

========

Any member of the design team may respond to comments about the requirements document on the SPRING mailing list, so long as they note that they are speaking as individuals, and not on behalf of the design team

Discussed

========

PSF presented analysis for Sections X through Y for UIDSR. Text provided below.

Action Items

==========

Ron to respond to Martin’s comment on 4.3.4 and 4.3.5

Darren to create a new, intermediate version of the analysis document

Text

====

UIDSR text:

3.1.  SRv6 Based

U.RFC8402 // Yes. 

[dd] concentrating on 16 and 32bit UID SID types

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.

[PSF] An IGP draft exists

U.BGP        // Yes. 

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

[dd] is there a draft for UIDSR and BGP?

[PSF] Reuses BGP draft

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.

[Ron] Combatibility issue:  what happens when an old platform receives an SRH with flags set?

[PSF] SRv6-base nodes should not receive a packet with flags set, the previous segment should have changed them before entering the srv6-base segment(s)

[Darren] If segment list is <U-32,U-128, U-32,U-32> is padding required?  I did not see that in the draft, i.e how does this work . <U-32,U-128,pad,pad,U-32,U-32>

Juniper Business Use Only