[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

<https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03>

   - 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.

<https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-06>

Regards, <https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01>

Greg

On Sat, Jan 30, 2021 at 2:20 PM Adrian Farrel <adrian@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-bounces@ietf.org> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-chairs@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
>