Subject: [mpls] I send my second question on draft-farrel-mpls-sfc-02.txt according to co-chair's request

From: Xuxiaohu <[email-masked]>
Date: Tue, 14 Nov 2017 06:57:41 +0000

Hi all,

My second question is what's the difference between the second MPLS-based SFC approach (draft-farrel-mpls-sfc-02.txt) and the MPLS-SR-based SFC approach (draft-xu-mpls-service-chaining) from the technology perspective.

Best regards,
Xiaohu

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Nov 2017 07:07:03 -0000

Hi,

Yes, good question.

Both drafts describe a label stacking approach where two labels are used at each
hop.
The major difference is in how metadata is handled.
draft-xu-mpls-service-chaining uses an NSH at the bottom of the stack to
encapsulate the metadata. This has the benefit of re-using an existing
mechanism/encoding and also the benefit of placing the metadata in the same
packet as the user data. There are also some drawbacks as mentioned in the SFC
meeting: the particular concerns are about packet size and disruption,
encapsulation rules (is a control word used to make it clear that the NSH is
there and prevent accidental inspection of the NSH?), and interpretation of the
other NSH fields (e.g., what does the SI field in the NSH mean? what happens if
the NSH TTL is zero).

Do you see any other differences?

Adrian

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: 14 November 2017 06:58
> To: [email-masked]
> Subject: [mpls] I send my second question on draft-farrel-mpls-sfc-02.txt
> according to co-chair's request
> 
> Hi all,
> 
> My second question is what's the difference between the second MPLS-based
> SFC approach (draft-farrel-mpls-sfc-02.txt) and the MPLS-SR-based SFC approach
> (draft-xu-mpls-service-chaining) from the technology perspective.
> 
> Best regards,
> Xiaohu
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 14 Nov 2017 07:12:20 +0000

________________________________________
发件人: Adrian Farrel [[email-masked]]
发送时间: 2017年11月14日 15:07
收件人: Xuxiaohu; [email-masked]
主题: RE: [mpls] I send my second question on draft-farrel-mpls-sfc-02.txt according to co-chair's request

Hi,

Yes, good question.

[Xiaohu] Thanks a lot for your clarification about the difference.

[Xiaohu] Another difference I noticed that you rename the node segment label as context label :)

Best regards,
Xiaohu

Adrian

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Nov 2017 07:30:07 +0000

In general, there is a 3rd approach which should be added to the discussion here. The 3rd approach is doing all in the control plane and use MPLS/SPRING as a way to get from one SFF to another. Example: https://tools.ietf.org/html/draft-ietf-bess-service-chaining-03

Can we discuss why complicating the data plane for this is a good idea and what value it brings over doing it in control plane.

Irrespective of this we will need a way to encapsulate NSH with MPLS transport and how we signal, this irrespective of the above

On 14/11/2017, 15:12, "mpls on behalf of Xuxiaohu" <[email-masked] on behalf of [email-masked]> wrote:

    
    Hi,
    
    Yes, good question.

    

    Best regards,
    Xiaohu
    
    Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Nov 2017 07:30:48 -0000

> [Xiaohu] Another difference I noticed that you rename the node segment label

Oh yes.
Actually, there are two good reasons for that. The first is to reach parity with
the encoding for the label swapping approach. The second is to observe that
there would be other interpretations of an exposed context label (i.e., when an
SFF pops the two labels and finds the next "context label" that might be a node
segment label and it might be something else).

Oh, by the way, anycast sids may be pretty handy in SFC.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Nov 2017 08:16:37 -0000

Agree with you about "NSH in MPLS" encapsulation. Needs specification.

The control plane discussion is (I think) and SR vs swapping discussion. The CP can be used for NSH or MPLS swapping (noting that NSH is a swapping paradigm).

The CP can (and should) be used to describe what happens at each hop (i.e., NSH, MPLS, foo). IIRC that is in the BESS draft.

And you may note that I support the BESS draft :-)

A

> From: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:[email-masked]]
> Sent: 14 November 2017 07:30
> To: Xuxiaohu; [email-masked]; [email-masked]
> Subject: Re: [mpls] 答复: I send my second question on draft-farrel-mpls-sfc-
> 02.txt according to co-chair's request
> 
> In general, there is a 3rd approach which should be added to the discussion here.
> The 3rd approach is doing all in the control plane and use MPLS/SPRING as a way
> to get from one SFF to another. Example: https://tools.ietf.org/html/draft-ietf-
> bess-service-chaining-03
> 
> Can we discuss why complicating the data plane for this is a good idea and what
> value it brings over doing it in control plane.
> 
> Irrespective of this we will need a way to encapsulate NSH with MPLS transport
> and how we signal, this irrespective of the above
>

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Nov 2017 08:44:46 +0000

So, for you is there a driver to add complexity in MPLS data plane other than supporting NSH?
I am not advocating we add complexity for adding NSH either, but I am advocating to support it.

On 14/11/2017, 16:35, "Adrian Farrel" <[email-masked]> wrote:

    

    A

---

From: John E Drake <[email-masked]>
Date: Tue, 14 Nov 2017 09:08:20 +0000

Wim,

As Adrian indicated in today's meeting, we support carrying the [SPI, SI] in an MPLS label stack, label swapping, as well as SR, label stacking;  this is the other significant difference between the two proposals, and as Jim G indicated, label swapping is consistent w/ the SFC architecture.

Adrian and I expect that label swapping will be the normal mode of operation and that label stacking may be used on an exception basis, e.g., when the classifier wants to force a given flow through a specific SFI multiple hops away from it along a given chain.  T

Yours Irrespectively,

John

> From: mpls [mailto:[email-masked]] On Behalf Of Henderickx, Wim

> (Nokia - BE/Antwerp)

> Sent: Tuesday, November 14, 2017 3:45 AM

> To: [email-masked]; 'Xuxiaohu' <[email-masked]>; [email-masked]

> So, for you is there a driver to add complexity in MPLS data plane other than

> supporting NSH?

> I am not advocating we add complexity for adding NSH either, but I am

> advocating to support it.

> On 14/11/2017, 16:35, "Adrian Farrel" <[email-masked]<mailto:[email-masked]>> wrote:

>     The control plane discussion is (I think) and SR vs swapping discussion. The CP

> can be used for NSH or MPLS swapping (noting that NSH is a swapping

> paradigm).

>     The CP can (and should) be used to describe what happens at each hop (i.e.,

> NSH, MPLS, foo). IIRC that is in the BESS draft.

>     > To: Xuxiaohu; [email-masked]<mailto:[email-masked]>; [email-masked]

>     > Subject: Re: [mpls] 答复: I send my second question on draft-farrel-mpls-

> sfc-

>     > In general, there is a 3rd approach which should be added to the discussion

> here.

>     > The 3rd approach is doing all in the control plane and use MPLS/SPRING as

> a way

>     > to get from one SFF to another. Example:

> https://urldefense.proofpoint.com/v2/url?u=https-

> 3A__tools.ietf.org_html_draft-2Dietf-

> 2D&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-

> ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-

> s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-

> TxQr9wwEHuwu4v3EU&s=5X6EVC6TLkBryVLNm1VcsLUTNE2zCISkWtNe6TNLO

> nk&e=

>     > Can we discuss why complicating the data plane for this is a good idea and

> what

>     > Irrespective of this we will need a way to encapsulate NSH with MPLS

> transport

>     > On 14/11/2017, 15:12, "mpls on behalf of Xuxiaohu" <mpls-

> [email-masked] on

>     > behalf of [email-masked]<mailto:[email-masked]>> wrote:

>     >     主题: RE: [mpls] I send my second question on draft-farrel-mpls-sfc-

> 02.txt

>     >     Both drafts describe a label stacking approach where two labels are used

> at

>     > each

>     >     mechanism/encoding and also the benefit of placing the metadata in the

> same

>     >     packet as the user data. There are also some drawbacks as mentioned in

> the

>     > SFC

>     >     encapsulation rules (is a control word used to make it clear that the NSH

> is

>     >     there and prevent accidental inspection of the NSH?), and interpretation

> of the

>     >     other NSH fields (e.g., what does the SI field in the NSH mean? what

> happens if

>     >     [Xiaohu] Another difference I noticed that you rename the node segment

> label

>     > as context label :)

>     >     > Subject: [mpls] I send my second question on draft-farrel-mpls-sfc-

> 02.txt

>     >     > My second question is what's the difference between the second

> MPLS-

>     > based

>     >     > SFC approach (draft-farrel-mpls-sfc-02.txt) and the MPLS-SR-based SFC

>     > approach

>     >     > https://urldefense.proofpoint.com/v2/url?u=https-

> 3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scb

> fh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-

> s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-

> TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc

> 5Odo&e=

>     >     https://urldefense.proofpoint.com/v2/url?u=https-

> 3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scb

> fh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-

> s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-

> TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc

> 5Odo&e=

> [email-masked]<mailto:[email-masked]>

> https://urldefense.proofpoint.com/v2/url?u=https-<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>

> 3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scb<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>

> fh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>

> s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>

> TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>

> 5Odo&e<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=TYoynxFX9bmnJhyeyfTExidaK-TxQr9wwEHuwu4v3EU&s=T2HVZ3h8n8MKrvFWyWTo7sMkG0xy0LzjLMMwlHc5Odo&e>=

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 14 Nov 2017 13:32:49 +0000

Thx, I believe we should start with the basic MPLS encap on NSH even w/o SPI, SI mapping and then enhance if required. Use the CP as much as possible besides this

From: John E Drake <[email-masked]>
Date: Tuesday, 14 November 2017 at 17:08
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Xuxiaohu' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [mpls] 答复: I send my second question on draft-farrel-mpls-sfc-02.txt according to co-chair's request

Wim,

Yours Irrespectively,

John