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

From: Sander Steffann <[email-masked]>
Date: Mon, 12 Oct 2020 16:49:56 +0200

Hi Team,

Here is the draft for the minutes:

Srcomp meeting
2020-10-12 13:00 UTC

Status: draft

Attendees:
- Cheng Weiqiang of China Mobile [present]
- Sander Steffann of SJM Steffann Consultancy [present]
- Ron Bonica of Juniper [present]
- Darren Dukes of Cisco [present]
- Cheng Li of Huawei [present]
- Peng Shaofu of ZTE [present]
- Wim Henderickx of Nokia [present]
- Chongfeng Xie of China Telecom [present]

# Discussing document

Sections 3.1:
- Ron and Darren met several times last week and got agreement
- Text in email

Section 3.2:
- Discussing Darren's proposed changes
- Discuss if REQ-8-01-INTERNETWORKING-DOMAINS-00 is a migration
requirement or a permanent feature requirement
- Agreement that migration requirements belong in 3.2.
INTERNETWORKING-DOMAINS name was confusing
- The Inter-domain requirement applies to domains using any technology
(SR-MPLS, SRv6 etc) and is not SRComp specific
- Text edited by Darren during the call
- Ron: Supporting both compressed and non-compressed in one path is a
nice-to-have in some cases, but not a hard requirement. It rules out a
whole set of possible solutions. Decided to make it a SHOULD or MAY in a
separate requirement.

Notes from Darren (much appreciated!):

> - REQ-8-20-IPv6-to-CompSRv6-00: Migration from IPv6 or SR MPLS to the compressed solution is deployment and not a topic for this section.  It should be covered in section 4. 
> - Reviewed above, ok.
> - For REQ-8-01-INTERWORKING-DOMAINS-00, REQ-8-20-SRv6-to-CompSRv6-00, and REQ-8-26-SPRING-SRV6-MIGRATION-01, these could be covered by the following single requirement... 
> - Reviewed above, include HETEROGENEOUS Requirement to merge too.
> 
> - Title: SRv6-to-compressed-SRv6
> 
>   - Description: The compression solution MUST support deployment in existing SRv6 networks. 
>   - Rationale: 
>     - SRv6 is deployed today.  A compression solution that interoperates well with SRv6, as deployed, will reduce the overhead and simplify operations. For Network operators who would migrate to compressed SRv6, the move is expected to gradually occur over a period time, as they upgrade networks, domains, device families and software instances. 
>   - Metric: A compliant compression solution provides the following 
>     - Supports simultaneous deployment at a node with current SRv6 SIDs. 
>     - Supports simultaneous deployment at a node with current SRv6 control plane. 
>     - Supports simultaneous operation of current SRv6 paths with compressed paths. 
>     - Supports the behaviors in draft-ietf-spring-network-programming. 
>     - Does not require removal of existing IPv6 address planning. 
> 
>   - Options: It's a benefit to be able to Supports paths consisting of compressed and non-compressed segments.
>     - Make this a SHOULD
>     - Make this a separate requirement
>     - Make this a weaker requirement
>     - ACTION: pull out as separate requirement again.

Further REQ-8-26-HET-SID-LIST word-smithing happened and the result was:

> - Description: The compression solution SHOULD/MAY support a combination of compressed and non-compressed segments in a single path. 
> - Rationale: SRv6 is deployed today.  This requirement benefits networks that have deployed Srv6 before the compression mechanism was available and offers those networks improved compression on selected paths.  It does not benefit networks that will deploy SRv6 after the compression mechanism becomes widely available. A network that has deployed SRv6 can achieve improved compression on select paths using a compressed segment without migrating all SRv6 nodes to the compression mechanism.
> - Metric: A compliant compression solution
>             must use the srh
>             or...
>             permits compressed and non-compressed segments to be encoded in a single path.
> 
> ACTION: Close metrics on the mailing list.
Cheers,
Sander