Subject: [Srcomp] Draft Minutes December 2

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 2 Dec 2020 14:25:51 +0000

Attendees: Weiqiang, Chongfeng, Cheng Li, Ron, Darren, Wim

Please correct or complete as necessary.

  *   Appendix A text nearly concluded by Ron and Darren
     *   Plan to conclude today and send an update to the list.
  *   REQ-8-26-NETWORK-SCALE
     *   There was agreement that this was equivalent to "4.3.2. Prefix segment scale"
  *   ACTION: Darren - Send a proposal to be sent to the list to merge
     *   REQ-9-01-SERVICE-SCALE-00
     *   REQ-9-01-LINKNODE-SCALE-00
     *   REQ-9-08-Compression-Levels-00
  *   ACTION: Weiqiang to follow up with Greg, pending further updates.
  *   ACTION: Address Planning:
     *   Add from minutes on 10/21
  *   ACTION: Darren add additional requirements from email list to backlog document for future discussion.
  *   Remaining requirements:

     *   ### REQ-7-29-EXPLICIT-SID-LENGTH-00
        *   Team discussed with no conclusion.
        *   Awaiting PSF to continue discussion
     *   ### REQ-8-07-DEBUGGING-01
        *   Same as above
     *   ### REQ-8-13-SID-DETECTED-00
        *   Related to how to use the SR solution and not the compression solution itself.
        *   Remove this from backlog
     *   ### REQ-8-13-SID-INFORMATION-PROTECTED-00
        *   Darren and Chongfeng to discuss
        *   There seems to be two requirements associated with this
        *   A compression solution should not require nodes outside the SR domain to know SID values.
        *   A compression solution should be able to block access to SIDs within the SR domain.
     *   ### REQ-8-19-SEGMENT-FUNCTION-DIVERSITY-01
        *   Function Diversity is covered in A2.1
        *   Text in parking lot can be deleted
     *   ### REQ-9-08-Point-to-Multipoint-00
        *   Needs  more discussion
  *   Next meeting and on the list:
     *   Cheng to kick off security discussion on the email list.

---

From: <[email-masked]>
Date: Wed, 9 Dec 2020 15:44:58 +0800 (CST)

Hi All,

For REQ-7-29-EXPLICIT-SID-LENGTH-00, I don't have any more new ideas, I just repeat the previous ones:

It is a very important basic ability for packets to be parsed. Traditional IPv4, IPv6, Ethernet, MPLS shim and other headers, etc, all support parsing. The so-called parsing refers to the ability to read the correct detailed information from the packet, rather than generally speaking that it is an IPv4 header or an IPv6 header. When the Segment List is encapsulated into the IPv6 header or one of its extension headers, it is very important to parse the correct Segment List from the packet, and that is done depending on the packet itself.

I think we should pretend that there are no compression solutions so far, and then consider whether the requirement is reasonable. Shouldn't it be in the requirement phase?

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28
主 题 ：[Srcomp] Draft Minutes December 2

--  
Srcomp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/srcomp

 

Appendix A text nearly concluded by Ron and Darren 

Plan to conclude today and send an update to the list. 

REQ-8-26-NETWORK-SCALE 

There was agreement that this was equivalent to "4.3.2. Prefix segment scale" 

ACTION: Darren - Send a proposal to be sent to the list to merge 

REQ-9-01-SERVICE-SCALE-00 

REQ-9-01-LINKNODE-SCALE-00 

REQ-9-08-Compression-Levels-00 

ACTION: Weiqiang to follow up with Greg, pending further updates. 

ACTION: Address Planning: 

Add from minutes on 10/21 

ACTION: Darren add additional requirements from email list to backlog document for future discussion. 

Remaining requirements: 

### REQ-7-29-EXPLICIT-SID-LENGTH-00 

 Team discussed with no conclusion.  

 Awaiting PSF to continue discussion

 ### REQ-8-07-DEBUGGING-01 

 Same as above

 ### REQ-8-13-SID-DETECTED-00 

 Related to how to use the SR solution and not the compression solution itself.

 Remove this from backlog

 ### REQ-8-13-SID-INFORMATION-PROTECTED-00 

 Darren and Chongfeng to discuss

 There seems to be two requirements associated with this

 A compression solution should not require nodes outside the SR domain to know SID values.

 A compression solution should be able to block access to SIDs within the SR domain.

 ### REQ-8-19-SEGMENT-FUNCTION-DIVERSITY-01 

 Function Diversity is covered in A2.1

 Text in parking lot can be deleted

 ### REQ-9-08-Point-to-Multipoint-00 

 Needs  more discussion

 Next meeting and on the list:

 Cheng to kick off security discussion on the email list.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 9 Dec 2020 11:46:45 +0000

Hi Shaofu, I agree that the ability to identify the segment list is important for debugging.

The current destination of the packet is in the destination address, the path it will take through the network is encoded in the segment list.

However, interpreting the segment list to determine the packet's path always requires control plane information.  Control plane information is required to identify segments and their behavior.  This is true for SR MPLS and SRv6 today.  Without it, all that I have is a segment list.

I believe a more complete requirement for debugging is:

The segment list MUST be present in the packet so an operator can inspect it for debugging purposes. Decompressing the segment list MAY depend on control plane data to identify the segments, and the behavior of each segment, so the expected path of the packet through the network can be determined.

Darren

________________________________
From: [email-masked] <[email-masked]>
Sent: Wednesday, December 9, 2020 2:44 AM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re:[Srcomp] Draft Minutes December 2

Hi All,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28

  *   REQ-8-26-NETWORK-SCALE

        *   Same as above

        *   Needs  more discussion

---

From: Ron Bonica <[email-masked]>
Date: Wed, 9 Dec 2020 16:05:22 +0000

Darren,

A packet header can be self-describing *and* elicit a behavior that is determined by the control plane.

In a self-describing packet header:

  *   We know exactly where each field begins and each field ends.
  *   We know exactly what each field means.
  *   We don’t need any information from the control plane to parse the packet.
  *
The IPv4, IPv6 and MPLS headers are all self-describing. So are all of the IPv6 extension headers and transport layer headers.

The operations community has decades of experience debugging protocols with self-describing headers. I’m not sure that it has any experience debugging protocols that do not have self-describing  headers.

The requirement that we are discussing recommends that the compression mechanism employ a self-describing header. It allows the behavior elicited by that self-describing header to be determined by the control plane. Please don’t confuse the two issues.

                                                                                                Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, December 9, 2020 6:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Srcomp] Draft Minutes December 2

[External Email. Be cautious of content]

Darren

________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 9, 2020 2:44 AM
To: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re:[Srcomp] Draft Minutes December 2

Hi All,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28
主 题 ：[Srcomp] Draft Minutes December 2
--
Srcomp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/srcomp

  *   REQ-8-26-NETWORK-SCALE

        *   Same as above

        *   Needs  more discussion

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 10:37:58 +0800 (CST)

Hi Ron and Darren,

As Ron stated:

"The requirement that we are discussing recommends that the compression mechanism employ a self-describing header. It allows the behavior elicited by that self-describing header to be determined by the control plane. Please don’t confuse the two issues."

That's exactly what I want to say, that is, SID or Label can have specific forwarding behavior (by traditional MPLS LIB entry or SRv6 local SID entry ), but this is independent of packet parsing.

Regards,

PSF

原始邮件

发件人：RonBonica
收件人：Darren Dukes (ddukes);彭少富10053815;
抄送人：[email-masked];
日 期 ：2020年12月10日 00:10
主 题 ：RE: [Srcomp] Draft Minutes December 2

Darren,

 

 

We know exactly where each field begins and each field ends.

We know exactly what each field means.

We don’t need any information from the control plane to parse the packet.

 

 

 

                                                                                                Ron

 

 

 

 

 

 

 

 

Darren

 

--------------------------------------------------------------------------------

 

Hi All,

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)

收件人：srcomp;

日 期 ：2020年12月02日 22:28

 

REQ-8-26-NETWORK-SCALE 

Remaining requirements: 

 

 

 

 

Same as above

 

 

Remove this from backlog

 

 

 

 

 

 

 

 

 

Needs  more discussion

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 10 Dec 2020 04:55:18 +0000

If we take the analogy to Ipv4 or IPv6 the prefix length is not in the packet and we are running the Internet on it. So the combination of a header with control plane is what matters.

From: Srcomp <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, 10 December 2020 at 03:38
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "ddukes=[email-masked]" <ddukes=[email-masked]>
Subject: Re: [Srcomp] Draft Minutes December 2

Hi Ron and Darren,

As Ron stated:

Regards,

PSF

原始邮件
发件人：RonBonica

                                                                                                Ron

Darren

Hi All,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28

  *   REQ-8-26-NETWORK-SCALE

        *   Same as above

        *   Needs  more discussion

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 14:02:06 +0800 (CST)

Wim,

It is an invalid example.

As we know, In IPv4 or IPv6 packet, there is no "prefix" field, but an "Ip Address" field with EXACT length.

Prefix is a routing related concept, used to direct packets forwarding. So you also confuse the forwarding behavior with the parsing of the packet.

Regards,

PSF

原始邮件

发件人：Henderickx,Wim(Nokia-BE/Antwerp)
收件人：彭少富10053815;[email-masked];
抄送人：[email-masked];ddukes=[email-masked];
日 期 ：2020年12月10日 12:55
主 题 ：Re: [Srcomp] Draft Minutes December 2

 

 

Hi Ron and Darren,

As Ron stated:

Regards,

PSF

原始邮件

发件人：RonBonica

抄送人：[email-masked];

日 期 ：2020年12月10日 00:10

Darren,

 

 

 

 

 

                                                                                                Ron

 

 

 

 

 

 

 

 

Darren

 

 

Hi All,

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)

收件人：srcomp;

日 期 ：2020年12月02日 22:28

 

REQ-8-26-NETWORK-SCALE 

Remaining requirements: 

 

 

 

 

Same as above

 

 

Remove this from backlog

 

 

 

 

 

 

 

 

 

Needs  more discussion

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 10 Dec 2020 06:46:54 +0000

Hi PSF,

How about SRv6 SID structure? Locator/Function/Argument.  Do we need to describe it in the data plane?  I do not think so.

We can parse the SRv6 Segment list, but we will not know what is the meaning of SIDs, like which node it is associated with. It is the same for IPv4 and IPv6, right?
What we can get is a 32-bit or 128-bit value, unless it is a well-known special value like FC::00/7. We need the control plane to know what is the meaning of the value. I think this is the same in forwarding.

·         If it is a segment endpoint node, then the node can understand what is the behavior associated to the active SID in IPv6 DA, and how to process it.

·         If it is not the segment endpoint node, it is OK for it to only know the Segment List. I think it is more secure. Like we control plane to know the prefix/Locator of the IPv6 DA.

For debugging, both the control plane and data plane are important. We can not debug it with only data plane information only. Therefore, I don’t think we need to add an explicit flag to indicate the length of Compressed SID.

Anyone can provide a solution with a flag, that is fine. But this is not required.

Thanks,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 10, 2020 2:02 PM
To: [email-masked]
Cc: [email-masked]; ddukes=[email-masked]; [email-masked]
Subject: Re: [Srcomp] Draft Minutes December 2

Wim,

Regards,

PSF

原始邮件
抄送人：[email-masked];ddukes=[email-masked]<mailto:[email-masked];ddukes=[email-masked]>;

From: Srcomp <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 10 December 2020 at 03:38
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "ddukes=[email-masked]<mailto:ddukes=[email-masked]>" <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Subject: Re: [Srcomp] Draft Minutes December 2

Hi Ron and Darren,

As Ron stated:

Regards,

PSF

原始邮件
发件人：RonBonica
收件人：Darren Dukes (ddukes);彭少富10053815;
抄送人：[email-masked]<mailto:[email-masked]>;
日 期 ：2020年12月10日 00:10
主 题 ：RE: [Srcomp] Draft Minutes December 2
Darren,

·         We know exactly where each field begins and each field ends.

·         We know exactly what each field means.

·         We don’t need any information from the control plane to parse the packet.

·

                                                                                                Ron

Juniper Business Use Only
From: Srcomp <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, December 9, 2020 6:47 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Srcomp] Draft Minutes December 2

Darren

Hi All,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28

·         Appendix A text nearly concluded by Ron and Darren

§  Plan to conclude today and send an update to the list.

·         REQ-8-26-NETWORK-SCALE

§  There was agreement that this was equivalent to "4.3.2. Prefix segment scale"

·         ACTION: Darren - Send a proposal to be sent to the list to merge

§  REQ-9-01-SERVICE-SCALE-00

§  REQ-9-01-LINKNODE-SCALE-00

§  REQ-9-08-Compression-Levels-00

·         ACTION: Weiqiang to follow up with Greg, pending further updates.

·         ACTION: Address Planning:

§  Add from minutes on 10/21

·         ACTION: Darren add additional requirements from email list to backlog document for future discussion.

·         Remaining requirements:

§  ### REQ-7-29-EXPLICIT-SID-LENGTH-00

§  Team discussed with no conclusion.

§  Awaiting PSF to continue discussion

§  ### REQ-8-07-DEBUGGING-01

§  Same as above

§  ### REQ-8-13-SID-DETECTED-00

§  Related to how to use the SR solution and not the compression solution itself.

§  Remove this from backlog

§  ### REQ-8-13-SID-INFORMATION-PROTECTED-00

§  Darren and Chongfeng to discuss

§  There seems to be two requirements associated with this

§  A compression solution should not require nodes outside the SR domain to know SID values.

§  A compression solution should be able to block access to SIDs within the SR domain.

§  ### REQ-8-19-SEGMENT-FUNCTION-DIVERSITY-01

§  Function Diversity is covered in A2.1

§  Text in parking lot can be deleted

§  ### REQ-9-08-Point-to-Multipoint-00

§  Needs  more discussion

·         Next meeting and on the list:

§  Cheng to kick off security discussion on the email list.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2020 16:05:32 +0800 (CST)

Hi Cheng,

See inline [PSF]

Regards,

PSF

原始邮件

发件人：Chengli(ChengLi)
收件人：彭少富10053815;[email-masked];
抄送人：[email-masked];ddukes=[email-masked];[email-masked];
日 期 ：2020年12月10日 14:47
主 题 ：RE: [Srcomp] Draft Minutes December 2

Hi PSF,

[PSF] What we are talking about is what Ron calls packet self-describing capability, I think that is no relationship with the FIB state maintained in data plane. If you are referring to the need to describe these information(Loc/Func/Arg) in the packet, may answer is absolutely NOT.

[PSF] Firstly, we need parse the correct SRv6 Segment List from the packet. Secondly, we try to get the meanning of each Segment. In some cases, the second step maybe simple, but in other cases it maybe difficult. But anyway, the second step has nothing to do with the first step.

 [PSF] Good. That is different forwarding behaviors on different nodes. Referring to RFC8200,  the behavior of segment node is different with non-segment node. But what does this have to do with packet self-describing capability ?

[PSF] Debugging is an example of how to benefit from packet self-describing capability. Others are operation and maintenance. Please do not assume that the first step is not necessary because the second step may be difficult and maybe need more information(such as the state of control plane). 

[PSF] If I follow your logic, I can get: because the IPv6 packet itself needs to rely on other additional information to forward, and these additional information is not provided by the IPv6 packet itself, that is, only relying on the IPv6 packet itself can not determine how to forward, so the IPv6 packet does not need to have the ability of self-describing.

[PSF] I'm refining your point: Because an enhancement function requires additional information, thus basic functionality is not necessary.

[PSF] Disagree.

Thanks,

Cheng

 

 

Wim,

Regards,

PSF

原始邮件

日 期 ：2020年12月10日 12:55

 

 

Hi Ron and Darren,

As Ron stated:

Regards,

PSF

原始邮件

发件人：RonBonica

抄送人：[email-masked];

日 期 ：2020年12月10日 00:10

Darren,

 

 

·          

 

 

 

                                                                                                Ron

 

 

 

 

 

 

 

 

Darren

 

 

Hi All,

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)

收件人：srcomp;

日 期 ：2020年12月02日 22:28

 

·         REQ-8-26-NETWORK-SCALE 

 

 

 

 

§  Same as above

 

 

 

 

 

 

 

 

 

 

 

 

§  Needs  more discussion

---

From: Ron Bonica <[email-masked]>
Date: Thu, 10 Dec 2020 18:38:13 +0000

Wim,

There are no variable length fields in the IPv4 or IPv6 header. So, those headers are self-describing.

                                                                   Ron

Juniper Business Use Only
From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>
Sent: Wednesday, December 9, 2020 11:55 PM
To: [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]; ddukes=[email-masked]
Subject: Re: [Srcomp] Draft Minutes December 2

Hi Ron and Darren,

As Ron stated:

Regards,

PSF

原始邮件
发件人：RonBonica

                                                                                                Ron

Darren

Hi All,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：srcomp;
日 期 ：2020年12月02日 22:28
主 题 ：[Srcomp] Draft Minutes December 2
--
Srcomp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/srcomp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!W0kOtY7uJIxRhwT6b2VgmMU2snVzJMPCkiOVdZhWCVahVTfb75kjWTsCfBIC6CCP$>

  *   REQ-8-26-NETWORK-SCALE

        *   Same as above

        *   Needs  more discussion