Re: [Srcomp] Draft Minutes December 2

[Ron Bonica <[e-mail]>]

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) <[e-mail]>
Sent: Wednesday, December 9, 2020 11:55 PM
To: [e-mail]; Ron Bonica <[e-mail]>
Cc: [e-mail]; ddukes=[e-mail]
Subject: Re: [Srcomp] Draft Minutes December 2

[External Email. Be cautious of content]

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 <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 10 December 2020 at 03:38
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "ddukes=[e-mail]<mailto:ddukes=[e-mail]>" <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>
Subject: Re: [Srcomp] Draft Minutes December 2




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;
抄送人：[e-mail]<mailto:[e-mail]>;
日 期 ：2020年12月10日 00:10
主 题 ：RE: [Srcomp] Draft Minutes December 2
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, December 9, 2020 6:47 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Srcomp] Draft Minutes December 2

[External Email. Be cautious of content]

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: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, December 9, 2020 2:44 AM
To: Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re:[Srcomp] Draft Minutes December 2




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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/srcomp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!W0kOtY7uJIxRhwT6b2VgmMU2snVzJMPCkiOVdZhWCVahVTfb75kjWTsCfBIC6CCP$>

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.