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

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 26 Oct 2020 14:40:02 +0000

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

Sander was away today so I captured the minutes.  Please correct/revise/add as necessary.
Section 4.2.3
Conclusion: document post rev00
Notes: Several attempts were made trying to define how parse-able a compression mechanism must be without any external or control plane knowledge.
Getting the wording correct was a challenge with multiple interpretations.

Section 4.2.4
Conclusion: Determined to be the same as 4.2.3, delete this section.

Section 4.2.5
Action: Chongfeng and Weiqiang to modify the text to cover the following functionality
Proposed intent: When CE nodes are SR source nodes and add a segment list to a packet, a PE node must be able to detect the compressed SID list.
- Be able to protect SIDs in the provider network from use by customers.
- Be able to permit specific SIDs in the provider network to be used by specific customers.

Section 4.2.6
Action: Chongfeng and Darren to edit this and submit
Proposed intent: A compression solution MUST NOT require that segments within the operator's domain are visible to nodes outside the operator's domain

Section 4.2.7
Action: decision to be made in next call to keep 4.2.1 or 4.2.7 (or merge)
Note: This overlaps with 4.2.1

Section 4.2.8
Decision: leave this out of rev00 of the document.
Rationale: multicast is not documented in the SR architecture.
Proposed intent: This requires that a multicast address be supported as the last segment of a segment list. Supported with SRv6 today.

Section 4.3 (Scale)
Action: Team to provide comments on the mailing list. We want to have some scalability requirements closed by the end of the week.
Directions: Consider the entire set of requirements, there are many duplicates.

Darren

---

From: <[email-masked]>
Date: Tue, 27 Oct 2020 11:02:36 +0800 (CST)

Hi Darren,

Related scale section, for the following requirement example,

4.3.1.  REQ-7-27-LINK-SCALE-00

   o  Description:The compression mechanism must support 65,536 link per

      node (16 bit).

   o  Rational:Some network operators deploy networks which use a lot of

      links on a node.

   o  Metric:The compression mechanism allows to work in an environment

      that support this scalability.

Do you think this requirement must be under certain preconditions, i.e, the address planning is specific and determined ? 

For example 1, a specific address planning can provide dedicated 16 bit range for END.X SIDs allocation to support 65,536 link, then:

   --- Mechanism A is good because it can support 65536 link, while mechanism B is not good because it need expand the address planning (larger than 16) to support that. Right ?

For example 2, a specific address planning can only provide 16 bit range for all SIDs allocation, but still need to support 65,536 link, then:

   --- Mechanism A is good because it can support 65536 link, while mechanism B is not good because it need expand the address planning (larger than 16) to support that. Right ?

Regards,

PSF 

原始邮件

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

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

Section 4.2.3

Section 4.2.4

Section 4.2.5

Action:
 Chongfeng and Weiqiang to modify the text to cover the following functionality

Section 4.2.6

Action: Chongfeng and Darren to edit this and submitProposed intent: A compression solution MUST NOT require that segments within the operator's domain are visible to nodes outside the operator's domain

Section 4.2.7

Section 4.2.8

Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 27 Oct 2020 04:40:31 +0000

I prefer the more general requirements for node, link and service scale since I don't think there are any values for scale requirements that are truly absolute.

I Like REQ-9-01-SERVICE-SCALE-00, REQ-9-01-LINKNODE-SCALE-00 because they describe a requirement for a proposal to support small and large scale deployments allowing the proposal to specify how.

Darren
________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, October 26, 2020 11:02 PM
To: Darren Dukes (ddukes) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re:[Srcomp] 2020-10-26 Minutes for DT meeting

Hi Darren,

      node (16 bit).

      links on a node.

Regards,

PSF

原始邮件
发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月26日 22:45

Section 4.2.4

Section 4.2.5

Section 4.2.6

Section 4.2.7

Section 4.2.8

Section 4.3 (Scale)

Darren

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 27 Oct 2020 16:38:38 +0800

Hi, Shaofu,
With regard to the number of links, I have one comment, pls see inline,

From: [email-masked]
Date: 2020-10-27 11:02
To: ddukes=[email-masked]
CC: srcomp
Subject: Re: [Srcomp]2020-10-26 Minutes for DT meeting

Hi Darren,

xiechf:  Since IPv6 has super-large space, every normal address planning can support 65,536  links.  Besides the addresses which have been allocated, IPv6 network operator has reserved plenty of addresses for future usage in generall. When new requirement , such as addressing for SRv6,emerges,  it can allocate one specific block from its address space reserved, I don't see any factor which can influence the number of the links.   

Regards,
PSF 

Chongfeng

原始邮件
发件人：DarrenDukes(ddukes)
收件人：[email-masked];
日 期 ：2020年10月26日 22:45

Section 4.2.4

Section 4.2.5

Section 4.2.6

Section 4.2.7

Section 4.2.8

Section 4.3 (Scale)

Darren