Subject: [sfc] draft-xu-sfc-using-mpls-spring-01

From: Dave Dolson <[email-masked]>
Date: Fri, 10 Oct 2014 19:38:41 +0000

Regarding draft-xu-sfc-using-mpls-spring-01,

Sections 3.1 and 3.2 have the same title and similar language.  I think you meant to only use one of them?

Regarding the language, there is this statement?

" Before sending the packet to SF1, the remaining MPLS label
   stack (i.e., a segment list {SID(SF2)}) MUST be stripped.  Upon
   receiving the packet returned from SF1, SFF1 would re-impose the MPLS
   label stack which had been stripped before to the packet,..."

I'm wondering how you envision the SFF could remember what label stack belongs on a packet?
Keep in mind that an SF could inject packets that it creates; it isn't limited to forwarding them.
Keep in mind also that an SF may need to respond to a packet with a packet in the opposite direction (e.g., a firewall may RST in response to a SYN). So the SFF would have to know the label stack for the opposite direction as well.

The only solution I can think of is that there must be a dedicated SF per instance of label stack. I.e., a dedicated SF per service chain instance.

David Dolson
Senior Software Architect, Sandvine Inc.

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 11 Oct 2014 02:12:09 +0000

Hi David,

Thanks a lot for your valuable comments. Please see my response inline.

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Saturday, October 11, 2014 3:39 AM
To: [email-masked]
Subject: [sfc] draft-xu-sfc-using-mpls-spring-01

[Xiaohu] As for the difference between section 3.1 and section 3.2,  the former describes how to encode the SFP (Service Function Path) information while the latter describes who to encode the SFC (Service Function Chain) information.

[Xiaohu] As for how the SFF could remember which label stack belongs to which returned packet, couldn't the mechanism used by the SF-proxy to correlate the SFC headers with the returned packets be used here?

[Xiaohu] Good comments. We will consider them in the future version. By the way, should the packet originated by the SF travel along a certain SFP?

[Xiaohu] Could you please give us a more detailed illustration?

Best regards,
Xiaohu

David Dolson

---

From: Dave Dolson <[email-masked]>
Date: Wed, 15 Oct 2014 19:35:13 +0000

Inline [DDolson]

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Friday, October 10, 2014 10:12 PM
To: Dave Dolson; [email-masked]
Subject: Re: [sfc] draft-xu-sfc-using-mpls-spring-01

Hi David,

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Saturday, October 11, 2014 3:39 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] draft-xu-sfc-using-mpls-spring-01

[Xiaohu] As for how the SFF could remember which label stack belongs to which returned packet, couldn't the mechanism used by the SF-proxy to correlate the SFC headers with the returned packets be used here?
[DDolson] You are right, this is the same problem. The architecture calls this a "local attachment circuit", out of scope. Your document says the label stack is to be stripped without mentioning any sort of local attachment circuit. I believe your document says that simple IP packets can be sent to the SF.

[Xiaohu] Good comments. We will consider them in the future version. By the way, should the packet originated by the SF travel along a certain SFP?
[DDolson] Yes, the path taken by new (RST) packet must take the exact reverse of the path taken by the original packet. This example also applies to a cache that is returning cached content to the client that didn't come from the server.
Example:  client sends SYN; SYN packet goes through a firewall, then to a cache; cache returns SYN-ACK; the SYN-ACK must travel the reverse chain via the firewall before returning to the client.

[Xiaohu] Could you please give us a more detailed illustration?
[DDolson] A packet arrives from the SF to the SFF, and the SFF must choose a label stack to put on it. This can be decided by network interface to choose the "left" or "right" label stack. Therefore only one bidirectional chain can be supported.
However, if the SFF tags the packets with VLANs, and the SF preserves VLANs (by remembering which VLAN a layer4 connection belongs with), VLAN can also be used by the SFF to select the label stack. This would allow an SF to support 4096 bidirectional chains.
The VLAN approach is one example of local attachment circuit allowing a single SF to support multiple chains.

Best regards,
Xiaohu

David Dolson