Subject: Re: [spring] WG Adoption Call for draft-martin-spring-segment-routing-ipv6-use-cases

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Mar 2014 10:29:16 -0700

Alvaro,

> Hi!
> 
> This message officially starts the call for adoption for 
> draft-martin-spring-segment-routing-ipv6-use-cases.
> 
> Please indicate your position about adopting this use cases 
> draft by end-of-day on March 27, 2014.
> 
> http://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-ca
ses
> Thanks!

Section 2.3 (IPv6 Segment Routing in the Data Center) of
draft-martin-spring-segment-routing-ipv6-use-cases talks about using
Segment Routing for service chaining.

Please note that the SFC WG charter calls for the SFC WG to determine
the data plane behavior and the requirements on the control plane
in support of service chaining. Therefore, until the SFC WG determines
the data plane behavior and the control component requirements for
service chaining, presenting service chaining as a use case for IPv6
Segment Routing header is premature.

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Mar 2014 20:20:22 +0100

I disagree.

There is nothing wrong to present a use case for service chaining
either in SPRING WG with
draft-martin-spring-segment-routing-ipv6-use-cases or for that matter
in IDR with draft-patel-raszuk-bgp-vector-routing-01 or
draft-rfernando-l3vpn-service-chaining-03 at present time.

Holding work and proposals till SFC WG will deliver a new data plane
encapsulation and new control plane solution while existing or
shipping protocols are already providing or can be easily extended to
provide service chaining seems rather like artificial politics and not
a real technical IETF argument.

IMO it would be much better if we would all focus on technical details
of the use cases documents and proposed protocol extensions rather
then enforcing serialization delay of work between various WGs.

Regards,
R.

On Mon, Mar 24, 2014 at 6:29 PM, Yakov Rekhter <[email-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 26 Mar 2014 09:49:31 +0000

Hi Yakov,

thanks for the comments. See below.

> Segment Routing header is premature.

as far as I understand, SFC is not mandating any specific dataplane 
but rather use an additional shim header so to be dataplane 
agnostic. 

There are pro's and cons' to that approach but still, it looks to me 
legitimate to address service chaining in the context of a specific 
dataplane (i.e.: without the requirement of being agnostic).

The definition of the use case can be done within spring activity. 
The solution (if one day we get there ;-) may be addressed somewhere 
else. Similarly to what has been done for igp protocol extensions 
for segment routing.

Thanks.
s.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 26 Mar 2014 10:03:58 +0000

> -----邮件原件-----
> 发件人: spring [mailto:[email-masked]] 代表 Stefano Previdi (sprevidi)
> 发送时间: 2014年3月26日 17:50
> 收件人: Yakov Rekhter
> 抄送: Alvaro Retana (aretana); <[email-masked]>
> 主题: Re: [spring] WG Adoption Call for
> draft-martin-spring-segment-routing-ipv6-use-cases
> 
> Hi Yakov,
> 
> >> Please indicate your position about adopting this use cases draft by
> >> end-of-day on March 27, 2014.
> >>
> > the data plane behavior and the requirements on the control plane in
> > support of service chaining. Therefore, until the SFC WG determines
> as far as I understand, SFC is not mandating any specific dataplane but rather
> use an additional shim header so to be dataplane agnostic.
> 
> There are pro's and cons' to that approach but still, it looks to me legitimate to
> address service chaining in the context of a specific dataplane (i.e.: without the
> requirement of being agnostic).

+1

Xiaohu

> The solution (if one day we get there ;-) may be addressed somewhere else.
> Similarly to what has been done for igp protocol extensions for segment routing.
> 
> Thanks.
> s.
> 
> 
> >
> > Yakov.
> >