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

From: Sander Steffann <[email-masked]>
Date: Mon, 19 Oct 2020 16:06:28 +0200

Hi Team,

Here is the draft for the minutes:

Srcomp meeting
2020-10-19 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

4.1.1:
Darren and Ron worked on proposed text. Darren presented it and the
contents were extensively discussed. We are heading for a rough
consensus on the required functionality. There is no consensus on how to
record whether a solution re-uses existing machinery (SRH). For
operators who don't already use SRH it is not important, but for some of
the users who have already deployed SRH it may be a useful data-point.

Darren and Ron will discuss further offline.

4.1.8:
Finished last week.

4.2.1:
Agreement reached on new text: the compression must work with any
addressing scheme and must not rely on any specific addressing (like
requiring that the addresses all come from a single prefix for example).
Operators must have be free to use their address space in any way they want.

New text (thanks Darren!):

> 4.2.1.  REQ-7-28-FLEX-ADDRESS-PLANNING-00 
> 
>  
> 
>    o  Description:The compression mechanism MUST support flexible IPv6 
> 
>       address planning, and MUST NOT require for specific address type 
> 
>       and address value.  Also, It MUST support to be deployed by using 
> 
>       GUA, ULA and other unicast address types. 
> 
>  
> 
>    o  Description:The compression mechanism MUST support flexible IPv6 
> 
>       address planning, and MUST NOT rely on any specific address type 
> 
>       and address value.  Also, It MUST support to be deployed by using 
> 
>       GUA, ULA and other unicast address types. 
> 
>  
> 
>    o  Rational: The address planning of the network is vary based on the 
> 
>       address schema of the operator, so the solution MUST support 
> 
>       flexible address planning.  Operators need to deploy the solution 
> 
>       based on their own addresses planning. 
> 
>  
> 
>    o  Rationale: The address planning of the network may vary based on the 
> 
>       address scheme of the operator, so the solution MUST support 
> 
>       any addressing scheme.  Operators need to deploy the solution 
> 
>       based on their own addresses planning. 
> 
>  
> 
>  
> 
>    o  Metric:if the solution only works when using a specific address 
> 
>       type, or some specific address value, that is not compliant.  If 
> 
>       it require one or some specific prefixes, that is not compliant. 
> 
>  
> 
>     Metric: 
>     1 – A solution requiring a specific addressing scheme may not be compliant 
>     2 – If a solution does not support any addressing scheme it may not be compliant 
>     3 – Something else?

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Mon, 19 Oct 2020 20:25:24 +0200

Hi,

> Darren and Ron will discuss further offline.

After reading this back I see it's not minuted as clear as it should
have been. Let me try again: as we discussed in the call it is NOT a
requirement for the compression mechanism to use SRH or be backwards
compatible with SRH. Doing that would go beyond the charter of this
design team (this has previously been verified with the SPRING chairs).

As agreed in the call recording in the analysis whether it is backwards
compatible with SRH can be useful to know for a subset of the potential
target audience (the operators who have already deployed SRH). But it
can not be a requirement.

In addition to the minutes: I have given this some thought, and I think
backwards compatibility with SRH can only be a MAY. Both a SHOULD and a
MUST go beyond our charter.

Cheers,
Sander

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 22 Oct 2020 14:37:08 +0800

Hi，Sander，
I think backwards compibility with SRH should be considered as a requirement.  Although only a subset of operators have deployed SRH,  the smooth transition to CompSRv6 is important for them to protect the investment, the design of new solution should consider this point.

Best regards
Chongfeng  
 
From: Sander Steffann
Date: 2020-10-20 02:25
To: srcomp
Subject: Re: [Srcomp] 2020-10-18 Minutes for DT meeting
Hi,

 

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

---

From: Sander Steffann <[email-masked]>
Date: Thu, 22 Oct 2020 12:14:06 +0200

Hi,

> I think backwards compibility with SRH should be considered as a requirement.  Although only a subset of operators have deployed SRH,  the smooth transition to CompSRv6 is important for them to pro…

Sorry, it can not be a requirement. That would go against our charter. As I said: it can be a MAY, nothing stronger.

Cheers,
Sander

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 23 Oct 2020 10:35:34 +0800

Hi, Sander
Where is the charter?  Would you show it?

Chongfeng

From: Sander Steffann
Date: 2020-10-22 18:14
To: xiechf
CC: srcomp

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Fri, 23 Oct 2020 08:19:51 +0200

Hi Chongfeng,

> Where is the charter?  Would you show it?

https://mailarchive.ietf.org/arch/msg/spring/IopJDUcGLo7vU6uZxhQjWQg9Qrs/

My message was sent after discussion with one of the spring chairs, so it's not something I'm making up. I was explicitly told that requiring SRH backwards compatibility was not acceptable.

Cheers,
Sander