Hi Linda,
You mentioned that:
"Is there any draft identifying the gaps between virtual partitioning of
physical network and end to end Network Slicing? "
In fact, draft-peng-teas-network-slicing has a detailed discussion on this
gaps, see section "5. Overview of Existing Identifiers".
Although draft-peng-teas-network-slicing assumes the creation of a virtual
topology per slice in the network, leading to scalability issues, that can be
addressed with the combination of draft-bestbar-teas-ns-packet.
Note that SID per slice allocation by draft-peng-teas-network-slicing is
resource-aware SID defined in draft-ietf-spring-resource-aware-segments.
Although we all know that SID is allocated with associated resource within the
context of slice requirements, draft-ietf-spring-resource-aware-segments makes
the concept clear. Please don't use this concept to oppose other documents.
Regards,
PSF
原始邮件
发件人：LindaDunbar
收件人：Greg Mirsky;Adrian Farrel;
抄送人：James Guichard;spring;spring-cha...@ietf.org;
日 期 ：2021年02月05日 04:27
主 题 ：Re: [spring] When we have multiple proposals addressing the same problem
[Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Greg,
Thank you very much for listing all those drafts related to Network Slicing.
But some of the drafts are only describing virtual partitioning of physical
networks and methods to guarantee their end to end quality. Those virtual
partitioning of one physical networks using tags (MPLS, VLAN, RT, etc.) have
been deployed for decades.
Is there any draft identifying the gaps between virtual partitioning of
physical network and end to end Network Slicing? In 3GPP, a Network Slice
includes the capabilities to manage, control and orchestrate the subset of
network resources independently from other Network Slices.
Linda Dunbar
From: spring <spring-boun...@ietf.org> On Behalf Of Greg Mirsky
Sent: Wednesday, February 3, 2021 4:02 PM
To: Adrian Farrel <adr...@olddog.co.uk>
Cc: James Guichard <james.n.guich...@futurewei.com>; spring <spring@ietf.org>;
spring-cha...@ietf.org
Subject: [spring] When we have multiple proposals addressing the same problem
[Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]
Dear All,
I've edited the subject though left the original line in place to indicate the
relationship between threads of discussion.
Several comments already have referenced *bestbar* drafts that, in my
understanding of them, propose a different solution to the problem addressed in
draft-dong-spring-sr-for-enhanced-vpn. The situation when more than a single
technical solution being offered is not unusual, probably that is what one can
expect at IETF. And I think that "let's ensure that this is solid technical
work while allowing the market to decide whether it is better than others" is
very reasonable and removes non-technical considerations from a WG AP (or LC).
If we use that paradigm, other solutions, for example, *bestbar* drafts, would
be considered for adoption and, if adopted, progress on the Standards track. If
that is what the WG decides to do, standardize sound technical solutions, no
matter how many, then, by all means, I support it. What I feel uneasy about is
if adopting one proposal would create a situation preventing standardization of
other solutions. The WG faced a similar problem just recently and a design team
has been formed with a clear task and deliverables. Perhaps another design team
can be formed to work to analyze the problem and proposed solutions? I've
attempted to capture what seems to be relevant to the problem:
related to the data plane
https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03
https://tools.ietf.org/html/draft-peng-teas-network-slicing-04
https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01
https://tools.ietf.org/html/draft-bestbar-spring-scalable-ns-00
https://tools.ietf.org/html/draft-decraene-mpls-slid-encoded-entropy-label-id-00
https://tools.ietf.org/html/draft-dong-6man-enhanced-vpn-vtn-id-02
https://tools.ietf.org/html/draft-filsfils-spring-srv6-stateless-slice-id-02
related to the control plane extensions:
https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-06
https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01
https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-02
https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-05
https://tools.ietf.org/html/draft-dong-lsr-sr-enhanced-vpn-04
https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-02
https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt-02
https://tools.ietf.org/html/draft-zhu-idr-bgpls-sr-vtn-flexalgo-00
https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-srv6-01
https://tools.ietf.org/html/draft-dong-idr-bgpls-sr-enhanced-vpn-02.
Regards,
Greg
On Sat, Jan 30, 2021 at 2:20 PM Adrian Farrel <adr...@olddog.co.uk> wrote:
Thanks, Jim,
I’ve been following the enhanced VPN work in TEAS and I see it as a key piece
of the network slicing work.
It’s time that we had some protocol solutions that serve the VPN framework, and
this is a suitable starting point. I like that it is not specifying additional
protocol widgets but has looked at what we already have and is pointing up ways
to use those tools to deliver new function.
I see Robert’s point about the resource reservation aspects of traffic
engineering applied to an SR network, but this is not an insurmountable
problem. The question might be asked, “Why would you want to do that?” but that
is a question that (as Yakov would have said) the market can decide. It seems
that there are a couple of vendors and a couple of operators who have an
interest.
So I think we should adopt this draft and see whether we can turn it into
something that has great utility.
Cheers,
Adrian
From: spring <spring-boun...@ietf.org> On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org
Cc: spring-cha...@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:
This message starts a 2 week WG adoption call for
https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending
February 10th 2021.
After review of the document please indicate support (or not) for WG adoption
to the mailing list and if you are willing to work on the document, please
state this explicitly. This gives the chairs an indication of the energy level
of people in the working group willing to work on this document. Please also
provide comments/reasons for your support (or lack thereof) as this is a
stronger way to indicate your (non) support as this is not a vote.
Thanks!
Jim, Bruno & Joel
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
