Subject: [Srcomp] Draft Meeting Minutes Feb 10 2021

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 11 Feb 2021 21:21:33 +0000

Attendees: Darren, Wim, Ron

Minutes

  *   Not sufficient quorum to conclude new business
  *   We updated the backlog document as follows:
     *   Agreed on point to multipoint text and suggest it be added to the next version- proposed text below, review requested.
     *   The second IPv6 based requirement had no final consensus, we suggest it is added to a “requirements without unanimous consensus” section – proposed text below review requested.
     *   Added Parsability requirement to the backlog as a proposal to combine explicit SID length and debuggability.  No consensus, needs discussion – Ron to kick off.

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

Short Name: IPv6-based2

Description: The compression mechanism requires every node along the packet's delivery path to be IPv6-capable. It MUST not require any node along the packet's forwarding path to support any other forwarding plane (e.g., IPv4, MPLS)

Rational: According to RFC 8402, SRv6 is an instantiation of the SR Architecture over the IPv6 data plane.

Metric: A compliant solution requires every node along the packet's delivery path to be IPv6-capable. It does not not require any node along the packet's forwarding path to support any other forwarding plane (e.g., IPv4, MPLS)

------------------------------
Short Name: Point to multipoint

Description: The compression mechanism SHOULD support point-to- multipoint SR paths.

Rationale: Many VPN services require point-to-multipoint SR paths.

Metric: A compliant proposal can encode a multicast address in the ultimate segment of the segment list.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 12 Feb 2021 16:42:30 +0000

Darren,

Shouldn't the short name of the second requirement, below,  be "IPv6-based" instead of "IPv6-based2".  There is no "IPv6-based1".

                                                                              Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, February 11, 2021 4:22 PM
To: [email-masked]
Subject: [Srcomp] Draft Meeting Minutes Feb 10 2021

[External Email. Be cautious of content]

Minutes

     *   Agreed on point to multipoint text and suggest it be added to the next version- proposed text below, review requested.
     *   The second IPv6 based requirement had no final consensus, we suggest it is added to a "requirements without unanimous consensus" section - proposed text below review requested.
     *   Added Parsability requirement to the backlog as a proposal to combine explicit SID length and debuggability.  No consensus, needs discussion - Ron to kick off.

Short Name: IPv6-based2

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Wed, 17 Feb 2021 20:54:52 +0800

Hi,

The both items look good for me.

B.R.

Weiqiang Cheng

发件人: Srcomp [mailto:[email-masked]] 代表 Ron Bonica
发送时间: 2021年2月13日 00:43
收件人: Darren Dukes (ddukes); [email-masked]
主题: Re: [Srcomp] Draft Meeting Minutes Feb 10 2021

Darren,

Shouldn’t the short name of the second requirement, below,  be
“IPv6-based” instead of “IPv6-based2”.  There is no “IPv6-based1”.

Ron

Minutes

*	Agreed on point to multipoint text and suggest it be added to the
next version- proposed text below, review requested.
*	The second IPv6 based requirement had no final consensus, we suggest
it is added to a “requirements without unanimous consensus” section –
proposed text below review requested.
*	Added Parsability requirement to the backlog as a proposal to
combine explicit SID length and debuggability.  No consensus, needs
discussion – Ron to kick off.

Short Name: IPv6-based2

Description: The compression mechanism requires every node along the
packet's delivery path to be IPv6-capable. It MUST not require any node
along the packet's forwarding path to support any other forwarding plane (e.
g., IPv4, MPLS)

Rational: According to RFC 8402, SRv6 is an instantiation of the SR
Architecture over the IPv6 data plane.

Metric: A compliant solution requires every node along the packet's delivery
path to be IPv6-capable. It does not not require any node along the packet's
forwarding path to support any other forwarding plane (e.g., IPv4, MPLS)

Description: The compression mechanism SHOULD support point-to- multipoint
SR paths.

Metric: A compliant proposal can encode a multicast address in the ultimate
segment of the segment list.