Hi Martin,
Thanks a lot for your suggestions.
Design team will discuss them and feedback you soon.
We also hope WG members can discuss the comments together.
A quick question, do you think whether Address Aggregation requirement has been covered
by existed "4.2.4. SID summarization" ?
B.R.
Weiqiang Cheng
-----邮件原件-----
发件人: spring [mailto:[email protected]] 代表 Martin Horneffer
发送时间: 2021年4月7日 20:47
收件人: [email protected]
主题: [spring] operator requirements for
draft-srcompdt-spring-compression-requirement
Dear srcomp dt, and spring wg,
thanks a lot for the enormous effort to collect and describe all the
requirements for compression mechanisms, and for already starting the
analysis! A true work of merit.
From an operator’s point of view I would like to add two
requirements that I believe to be crucial to any kind of new
overarching
architecture: address management and address aggregation.
In my eyes, SRv6 does have the great potential to allow a new
architectures that span many still separate network domains (access,
aggregation, backbone, service areas, etc) and greatly simplify and
streamline their operation. However, in order to allow this in an
already existing operator environment, I really see these two points
as essential.
This probably has already been covered by Dirk’s mail below, and I
tried to make the point during the IETF109 session, but probably
wasn’t clear enough. I haven’t seen any discussion of it yet.
In any case I tried to find a wording that might be suitable for
addition to the requirements document. There are of course many ways
to tackle the issue, and this is just one attempt. Please let me know
what you think of it.
Best regards,
Martin
Proposed additions for draft-srcompdt-spring-compression-requirement:
4.3.4. Number Resource Management
Description: The compression mechanism SHOULD fit into existing
IPv6 address structures. It SHOULD NOT require management of a new
kind of number resource that needs to be coordinated for all network
domains that potentially could be connected to each other. Network
domains rather take existing parts of their address space to provide
their local functions, while staying fully interoperable with all other domains.
Rationale: In larger organizations different network domains (e.g.
access, aggregation, backbone, service areas) are managed by different
organizational units. Number resources such as IP addresses and
numeric identifiers must be organized in a way, that a) makes sure
that every network domain gets enough resources (e.g. address space)
to meet its needs, and b) conflicts between domains are prevented.
Network operators have solved this problem for resources such as IPv4
and IPv6 addresses already and can relatively easily base new
technology on this. On the other hand introducing new types of number
resources might impose serious costs on all affected organizational
units and thus seriously impede the introduction of the related technology.
Metric: The compression mechanism fits into existing IPv6 address
structures. It does not require management of a new kind of number
resource that needs to be coordinated for all network domains that are
potentially involved.
4.3.5. Address Aggregation
Description: The compression mechanism MUST support address
aggregation between network domains. It SHOULD support address
aggregation within a domain.
Rationale: In larger organizations with multiple network domains
and related organizational units it is effectively impossible to
exactly foresee and plan the accumulated scale requirements for any
reasonable future. Domain overarching architectures will fail if they
do not apply serious aggregation of addresses at least at the borders
between network domains.
Metric: The compression mechanism allows address aggregation at
least between network domains, and at as many additional levels as possible.
Am 19.11.20 um 16:46 schrieb Dirk Steinberg:
Hello SPRING WG,
I have read the SRComp design team requirements draft and would like
to comment.
I truly believe that a SID compression scheme MUST integrate into the
existing SRv6 framework. Otherwise it does not make much sense, or
said another way, it will not be a SID compression scheme for SRv6 at
all but another animal altogether.
SID compression should be used where the use case justifies it, i.e.
strict path TE inside a given domain. Inter-Domain usage of SRv6,
especially end systems in data centers, may have different
requirements and thus decide to use uncompressed SRv6 SIDs. It is
important that a SID list that describes a service that spans across
multiple domains be able to contain both compressed and uncompressed SIDs.
Consequently, the same CP needs to support both compressed and
uncompressed SIDs.
I am currently working on an architecture based on SRv6 for different
domains within a carrier network. These domains have different
requirements and also different hardware capabilities that may lead
to different designs for each subnetwork. But all these domains/
subnetworks must be able to interoperate seamlessly based on SRv6
standards, regardless of whether SID compression is used or not.
Therefore I strongly agree that Appendix A should be part of the draft.
I would also like to suggest another requirement:
IMHO the single biggest advantage that SRv6 has compared to MPLS is
aggregation (route summarization), something that is absolutely not
possible with MPLS labels (SIDs).
Aggregation (CIDR) is the very technology that has enabled the
Internet to scale and to become the worldwide internetwork that it is today.
In retrospect I believe the omission of aggregation has been the
biggest design mistake in MPLS -- but back then there were a lot of
other factors and the idea to use a very short tag for forwarding.
After all Tag Switching and MPLS were inspired from ATM and within
this context aggregation made no sense.
Consequently I propose to add to the draft the requirement that the
SID compression scheme MUST be compatible with aggregation, i.e. it
must be possible to express the reachability of a given set of SIDs
(maybe in some domain or data center) using a summary prefix.
Thanks and Cheers
Dirk
On Thu, Nov 19, 2020 at 3:21 PM Ahmed Bashand
<[email protected] <mailto:[email protected]>> wrote:
I also agree that the requirements in Appendix A should be part of
the draft. Having of existing standard as a basis greatly simplifies
the development and deployment of any compression scheme
Thanks
Ahmed
On 11/19/20 12:58 AM, Ran Pang(联通集团中国联通研究院-本部) wrote:
Hi Weiqiang and WG,
I read the draft and agree with the requirements specified in it.I
think the requirements in Appendix A should be part of the draft
in the next version.
China Unicom is working on a network evolution plan for SRv6
now, and we have done some field trials based on SRv6. In order
to maintain the continuity of the functionality, we suggest the
solution based on the SRv6 standards.
Best regards,
Pang Ran
*From:* 程伟强 <mailto:[email protected]>
*Date:* 2020-11-15 23:27
*To:* spring <mailto:[email protected]>
*CC:* srcomp <mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*Subject:* [spring] Fw:New Version Notification for
draft-srcompdt-spring-compression-requirement-01.txt
Hi Group,
SR compression design team have submitted a new version of
compression requirement draft.
Main changes as follows:
- added 3 items about scalibility with agreement within the
design team
- added an appendix including 3 items without without
unanimous consensus within the design team
- some minor text issue fixed
Please review it and let us know your comments.
BTW: We will have 1-hour session for the design team topic on
Friday and welcome to join us.
B.R.
Weiqiang on behalf of design team
----邮件原文----
发件人：internet-drafts <[email protected]>
<mailto:[email protected]>
收件人：Weiqiang Cheng <[email protected]>
<mailto:[email protected]>,Sander Steffann
<[email protected]> <mailto:[email protected]>,SJM Steffann
<[email protected]> <mailto:[email protected]>
抄 送: (无)
发送时间：2020-11-15 22:58:57
主题：New Version Notification for draft-srcompdt-spring-
compression-requirement-01.txt
A new version of I-D,
draft-srcompdt-spring-compression-requirement-01.txt
has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.
Name: draft-srcompdt-spring-compression-requirement
Revision: 01
Title: Compressed SRv6 SID List Requirements
Document date: 2020-11-13
Group: Individual Submission
Pages: 13
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7ATXRBN2$
<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7ATXRBN2$
>
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7M9jO-ce$
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7M9jO-ce$
>
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J806DzC$
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J806DzC$
>
Htmlized:
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7Eg9aWme$
<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7Eg9aWme$
>
Diff:
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7EcayS0S$
<https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft
-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6m
tnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7EcayS0S$ >
Abstract:
This document specifies requirements for solutions to compress SRv6
SID lists.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at
tools.ietf.org
<https://urldefense.com/v3/__http://tools.ietf.org__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J2cGsU_$
>.
The IETF Secretariat
Subject：New Version Notification for draft-srcompdt-spring-
compression-requirement-01.txt
A new version of I-D,
draft-srcompdt-spring-compression-requirement-01.txt
has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.
Name: draft-srcompdt-spring-compression-requirement
Revision: 01
Title: Compressed SRv6 SID List Requirements
Document date: 2020-11-13
Group: Individual Submission
Pages: 13
URL:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7ATXRBN2$
<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7ATXRBN2$
>
Status:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7M9jO-ce$
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7M9jO-ce$
>
Htmlized:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J806DzC$
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J806DzC$
>
Htmlized:
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7Eg9aWme$
<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7Eg9aWme$
>
Diff:
https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7EcayS0S$
<https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft
-srcompdt-spring-compression-requirement-01__;!!NEt6yMaO-gk!SNyuGL6m
tnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7EcayS0S$ >
Abstract:
This document specifies requirements for solutions to compress SRv6
SID lists.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at
tools.ietf.org
<https://urldefense.com/v3/__http://tools.ietf.org__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7J2cGsU_$
>.
The IETF Secretariat
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到
[email protected] <mailto:[email protected]>，即可以退
订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have
received this email in error please notify us immediately by
e-mail. Please reply to [email protected]
<mailto:[email protected]> ,you can unsubscribe from this
mail. We will immediately remove your information from send
catalogue of our.
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7PPLHTA7$
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7PPLHTA7$
>
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT44uwuB7PPLHTA7$
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/sp
ring__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xU
IT44uwuB7PPLHTA7$ >
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spr
ing__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUI
T44uwuB7PPLHTA7$
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
ng__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT4
4uwuB7PPLHTA7$
_______________________________________________
spring mailing list
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
ng__;!!NEt6yMaO-gk!SNyuGL6mtnTD5qWeH8hJgq91G4IFFoVFBFLjNUue7RPq-5xUIT4
4uwuB7PPLHTA7$
