Subject: [Srcomp] 2020-10-21 Minutes for DT meeting

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 21 Oct 2020 14:25:48 +0000

Minutes:
All members were present.

Weiqiang asked what we deliver to the SPRING WG at IETF 109
- The DT resolved to post a draft with only content that is
  reviewed and agreed to in the design team.  Include no
  other text.

The team reviewed 4.2.1, 4.2.2. 4.2.3
- 4.2.3 requires further discussion on the mailing list

Draft text from the call for further discussion on the list:

Section 4.2.1
=============
    Description: The compression mechanism MUST support flexible IPv6
      address planning, and MUST NOT rely on specific address type
      and address value. Also, It MUST support deployment by using GUA
      from different address blocks.

     Rationale: The address planning of the network may vary based on the
      addressing scheme of the operator, so the solution MUST support
      a flexible addressing scheme.  Operators need to deploy the solution
      based on their own address planning.

      Metric: A solution requiring a specific addressing scheme may not be compliant

Section 4.2.2
=============
Description: The segments of the compressed SID list MUST be
equivalent to the original SID List. For example, a strict path TE
SID List is not compressed to a loose path TE SID list.

Rationale: In SRv6 we can represent a path to meet certain objectives.
A compressed solution needs to support the objectives in the same way.

Metric: Information present in the pre-compression segment list MUST
also be present in the post-compression SID list.

Section 4.2.3
=============
- There was discussion around the need to identify a segment list in a packet.
- There was discussion around how useful that segment list was without control plane information.
- The team needs to determine if there is a requirement here and what it is.
- More discussion on the email list was encouraged.

---

From: <[email-masked]>
Date: Thu, 22 Oct 2020 09:50:56 +0800 (CST)

Hi Team,

For 4.2.3, I'm sorry I didn't make my opinion clear at the meeting. I repeat as follows:

    --- Getting the complete SID List information from the packet without the help of control information is very convinent for packet debugging and analysising by off-line tool. I think this is a traditional capability for any type of packet, such as Ethernet, IP, MPLS, etc.

   --- Another typical example is that a packet paser can examine there are how many labels in an MPLS packet. Although, each label is just  a meaningless number, but we can not say "so that the packet paser need not have the capability to examine MPLS packets". As we know, how to use the parsed label stack is the second step of debugging, maybe depend on other additional information.

   --- Getting the complete SID List, at least, has an obvious benefit that is to check whether the SID list encapsulation is correct and there is no missing information.

To sum up my point, that is:

1) It is a traditional capability for any type of packets, no exeption for CompSRv6.

2) It is benefit for packet debugging, analysising, emulation.

Regards,

PSF

原始邮件

发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月21日 22:30
主 题 ：[Srcomp] 2020-10-21 Minutes for DT meeting

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

Minutes:

Section 4.2.1
=============

Section 4.2.2
=============

Section 4.2.3
=============

---

From: Ron Bonica <[email-masked]>
Date: Mon, 26 Oct 2020 19:54:33 +0000

Peng,

I agree. A tool like Wireshark does not have access to the control plane. Yet:

  *   It can parse the fields of an IPv6 header
  *   It can parse the fields of any other IPv6 extension header
  *   It can parse the fields of an MPLS labels stack entry

Network operators find this ability to be very useful. Wireshark, TCPDUMP and similar tools should work for CompSRv6.

                                                                              Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, October 21, 2020 9:51 PM
To: ddukes=[email-masked]
Cc: [email-masked]
Subject: Re: [Srcomp] 2020-10-21 Minutes for DT meeting

[External Email. Be cautious of content]

Hi Team,

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：[email-masked]<mailto:[email-masked]>;
日 期 ：2020年10月21日 22:30
主 题 ：[Srcomp] 2020-10-21 Minutes for DT meeting
--
Srcomp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/srcomp
Minutes:
All members were present.

Section 4.2.1
=============

Section 4.2.2
=============

Section 4.2.3
=============