Subject: [sfc] 转发: New Version Notification for draft-fu-sfc-topology-01.txt

From: Fu Qiao <[email-masked]>
Date: Wed, 14 Oct 2015 16:57:05 +0800

Hi, all. I have upload a new version of the SFC topology draft. This draft mainly discusses the deployment topology of SFC in the operators' network. Comparing with the SFC architecture, this draft tries to explain the deployment details of SFC in the operator networks.
Your comments are more than welcome:)

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2015年10月14日 16:33
收件人: Qiao Fu; Hui Deng; Joel. Halpern; Joel M. Halpern
主题: New Version Notification for draft-fu-sfc-topology-01.txt

A new version of I-D, draft-fu-sfc-topology-01.txt
has been successfully submitted by Qiao Fu and posted to the
IETF repository.

Name:		draft-fu-sfc-topology
Revision:	01
Title:		The topology of service function chaining
Document date:	2015-10-14
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-fu-sfc-topology-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fu-sfc-topology/
Htmlized:       https://tools.ietf.org/html/draft-fu-sfc-topology-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fu-sfc-topology-01

Abstract:
   This document proposes a deployment topology of Service Function
   Chaining(SFC).  The topology is in accordance with the SFC
   architecture in [I-D.ietf-sfc-architecture].  Currently, such
   architecture only includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, without any instruction for the field deployment.
   It is still difficult to map from the architecture to a real
   deployment of SFC.  In this document, we propose this topology which
   will give instructions for the field deployments.  We further propose
   a VCPE usecase of SFC in the transport network, which explains the
   details of the deployment topology.

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.

The IETF Secretariat

---

From: [email-masked]
Date: Thu, 15 Oct 2015 11:37:40 +0800

Hi Qiao,

  Thanks for your updating.

  In the last sentence of Paragraph 2 in section 2, it mentions Multiple 
SFFs can be deployed after the GW in large scale use cases, so as to avoid 
large volume of traffic returning to the GW continuously. You mean 
multiple GWs or multiple SFFs? I am not very clear how to avoid large 
traffic.
 
  And the next-to-the-last paragraph in section 5 mentions when finishing 
the SFP, the GW will remove the SFC header.... This means the GW is the 
last SFF where the last SF attached in the SFP? But commonly, the GW isn't 
the last SFF, except there are some additional requirements between the 
actually last SFF and the GW. 

  As for the details description in section 6, the traditional CPEs in the 
MPLS-TP network still do what they do now, configuring the configuration 
lines and encapsulating the packets with MPLS labels. The difference is 
that the traditional CPEs forward the packets to the GW to apply SFC, 
rather than forwarding along the MPLS Path. Right? 

  Thanks,

Best Wishes,
Linda Wang

"sfc" <[email-masked]> 写于 2015/10/14 16:57:05:

> Fu Qiao <[email-masked]> 
> 发件人:  "sfc" <[email-masked]>
> 
> 2015/10/14 16:57
> 
> 收件人
> 
> <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> [sfc] 转发: New Version Notification for draft-fu-sfc-topology-01.txt
> 
> Hi, all. I have upload a new version of the SFC topology draft. This
> draft mainly discusses the deployment topology of SFC in the 
> operators' network. Comparing with the SFC architecture, this draft 
> tries to explain the deployment details of SFC in the operator networks.
> Diff:           
https://www.ietf.org/rfcdiff?url2=draft-fu-sfc-topology-01
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Fu Qiao <[email-masked]>
Date: Thu, 15 Oct 2015 14:25:34 +0800

Hi, Cui. Thank you for the comments. Please see the inlines and see if it
explains your questions.

发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年10月15日 11:38
收件人: Fu Qiao
抄送: sfc; [email-masked]
主题: Re: [sfc] : New Version Notification for draft-fu-sfc-topology-01.txt

Hi Qiao, 

  In the last sentence of Paragraph 2 in section 2, it mentions Multiple
SFFs can be deployed after the GW in large scale use cases, so as to avoid
large volume of traffic returning to the GW continuously. You mean multiple
GWs or multiple SFFs? I am not very clear how to avoid large traffic. 

[fq] Actually I think the SFFs are logical instance. They could be GWs in
real deployment. But these GWs are acting as SFFs in the SFC sense.

  And the next-to-the-last paragraph in section 5 mentions when finishing
the SFP, the GW will remove the SFC header.... This means the GW is the last
SFF where the last SF attached in the SFP? But commonly, the GW isn't the
last SFF, except there are some additional requirements between the actually
last SFF and the GW. 

[fq] For this part, I think the SFFs after the GW are actually in the SFC
region. The packets within this region is forwarded according to their SFC
header rather than using its original destination address, that is to say it
is an overlay network. Packets taken off that header will have its original
destination address revealed and should be forwarded to the destination,
which maybe an enterprise branch, for example. In the real deployment in the
operators network, we actually only have one GW for the packets to get in
and out of such region. That’s why I say it should be the GW to take off
the SFC header rather than the last SFF. 

  As for the details description in section 6, the traditional CPEs in the
MPLS-TP network still do what they do now, configuring the configuration
lines and encapsulating the packets with MPLS labels. The difference is that
the traditional CPEs forward the packets to the GW to apply SFC, rather than
forwarding along the MPLS Path. Right? 

[fq] What we are expecting here, is the traditional CPE should build a MPLS
tunnel to the destination, but such tunnel will certainly pass the MPLS-GW.
The GW should be enhanced to apply the SFC. And then the traffic can get
back to the tunnel and get to the destination. We are trying to avoid
complicating the function in the traditional CPE, therefore in this
deployment, no update should be done on the traditional devices. But we will
have to upgrade the GW to support this.

  Thanks, 

Best Wishes, 
Linda Wang 

"sfc" <[email-masked]> 写于 2015/10/14 16:57:05:

> 发件人: [email-masked] [ <mailto:[email-masked]>
mailto:[email-masked]] 
> URL:             <https://www.ietf.org/internet-drafts/draft-fu-sfc->
https://www.ietf.org/internet-drafts/draft-fu-sfc-
> topology-01.txt
> Status:          <https://datatracker.ietf.org/doc/draft-fu-sfc-topology/>
https://datatracker.ietf.org/doc/draft-fu-sfc-topology/
> Htmlized:        <https://tools.ietf.org/html/draft-fu-sfc-topology-01>
https://tools.ietf.org/html/draft-fu-sfc-topology-01
> Diff:
<https://www.ietf.org/rfcdiff?url2=draft-fu-sfc-topology-01>
https://www.ietf.org/rfcdiff?url2=draft-fu-sfc-topology-01

>  <https://www.ietf.org/mailman/listinfo/sfc>

---

From: [email-masked]
Date: Thu, 15 Oct 2015 16:20:20 +0800

Hi Qiao,

 Thanks for your explanation.
 In fact, according to SFC architecture, the last SFF is responsible for 
removing the SFC header and delivering the packet back to the original 
network. However, here you try to let GW to do  the decapsulation. This is 
the conflict. So I mention there may be some additional requirements 
between the last SFF and the GW.

 Thanks,

Best Regards,
Linda Wang

发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年10月15日 11:38
收件人: Fu Qiao
抄送: sfc; [email-masked]
主题: Re: [sfc] : New Version Notification for 
draft-fu-sfc-topology-01.txt
 
Hi Qiao, 

  And the next-to-the-last paragraph in section 5 mentions when finishing 
the SFP, the GW will remove the SFC header.... This means the GW is the 
last SFF where the last SF attached in the SFP? But commonly, the GW isn't 
the last SFF, except there are some additional requirements between the 
actually last SFF and the GW. 
[fq] For this part, I think the SFFs after the GW are actually in the SFC 
region. The packets within this region is forwarded according to their SFC 
header rather than using its original destination address, that is to say 
it is an overlay network. Packets taken off that header will have its 
original destination address revealed and should be forwarded to the 
destination, which maybe an enterprise branch, for example. In the real 
deployment in the operators network, we actually only have one GW for the 
packets to get in and out of such region. That’s why I say it should be 
the GW to take off the SFC header rather than the last SFF. 

  As for the details description in section 6, the traditional CPEs in the 
MPLS-TP network still do what they do now, configuring the configuration 
lines and encapsulating the packets with MPLS labels. The difference is 
that the traditional CPEs forward the packets to the GW to apply SFC, 
rather than forwarding along the MPLS Path. Right? 
[fq] What we are expecting here, is the traditional CPE should build a 
MPLS tunnel to the destination, but such tunnel will certainly pass the 
MPLS-GW. The GW should be enhanced to apply the SFC. And then the traffic 
can get back to the tunnel and get to the destination. We are trying to 
avoid complicating the function in the traditional CPE, therefore in this 
deployment, no update should be done on the traditional devices. But we 
will have to upgrade the GW to support this.

  Thanks, 

Best Wishes, 
Linda Wang

---

From: Fu Qiao <[email-masked]>
Date: Thu, 15 Oct 2015 16:51:21 +0800

Hi, Cui.

Yes, indeed. That’s why I propose this draft. Currently the SFC
architecture is a logical architecture. When it comes to real deployments,
there will be some additional requirements for these logical modules in the
SFC architecture. I would like to specify these additional requirements
through discussion of real deployments in this draft.

发送时间: 2015年10月15日 16:20
抄送: 'sfc'; [email-masked]

Hi Qiao, 

the conflict. So I mention there may be some additional requirements between
the last SFF and the GW. 

 Thanks, 

Best Regards, 
Linda Wang 

发件人: sfc [ <mailto:[email-masked]> mailto:[email-masked]] 代
表 [email-masked]
发送时间: 2015年10月15日 11:38
收件人: Fu Qiao
抄送: sfc; [email-masked]
主题: Re: [sfc] : New Version Notification for draft-fu-sfc-topology-01.txt 
  
Hi Qiao, 

 In the last sentence of Paragraph 2 in section 2, it mentions Multiple SFFs
can be deployed after the GW in large scale use cases, so as to avoid large
volume of traffic returning to the GW continuously. You mean multiple GWs or
multiple SFFs? I am not very clear how to avoid large traffic. 
[fq] Actually I think the SFFs are logical instance. They could be GWs in
real deployment. But these GWs are acting as SFFs in the SFC sense. 

 And the next-to-the-last paragraph in section 5 mentions when finishing the
SFP, the GW will remove the SFC header.... This means the GW is the last SFF
where the last SF attached in the SFP? But commonly, the GW isn't the last
SFF, except there are some additional requirements between the actually last
SFF and the GW. 
[fq] For this part, I think the SFFs after the GW are actually in the SFC
region. The packets within this region is forwarded according to their SFC
header rather than using its original destination address, that is to say it
is an overlay network. Packets taken off that header will have its original
destination address revealed and should be forwarded to the destination,
which maybe an enterprise branch, for example. In the real deployment in the
operators network, we actually only have one GW for the packets to get in
and out of such region. That’s why I say it should be the GW to take off
the SFC header rather than the last SFF. 

 Thanks, 

Best Wishes, 
Linda Wang

---

From: [email-masked]
Date: Thu, 15 Oct 2015 17:23:24 +0800

Hi Qiao,

  Agree with you. There needs additional requirements for SFFs in the SFC 
architecture :)

Best Regards,
Linda, 

Hi, Cui.
Yes, indeed. That’s why I propose this draft. Currently the SFC 
architecture is a logical architecture. When it comes to real deployments, 
there will be some additional requirements for these logical modules in 
the SFC architecture. I would like to specify these additional 
requirements through discussion of real deployments in this draft.

Hi Qiao, 

 Thanks, 

Best Regards, 
Linda Wang 

  
Hi Qiao, 

 Thanks, 

Best Wishes, 
Linda Wang