Subject: Re: [mpls] MPLS-RT review of draft-farrel-mpls-sfc

From: Lizhong Jin <[email-masked]>
Date: Wed, 28 Feb 2018 23:52:46 +0800

Hi all,

This is an alternative for SFC implementation in MPLS network. Since it is WG adoption, not last call, basically I believe the document is ready for adoption.

And I have one concern to the solution regarding the metadata. There is no per packet metadata like NSH, which will surely bring some restriction to the applications. I know some SFC application even does not require metadata, but I did one development of SFC application using per-packet metadata (strictly saying, it is per-flow) which is of course not under MPLS infrastructure.

If possible, could authors add a section to describe what kind of capability this approach could achieve, and what could not compared with NSH. With that context, the operators could understand better, and easier to decide which solution to deploy.

Regards

Lizhong

On 2/3/2018 14:02，Loa Andersson<[email-masked]> wrote：

Matthew, Lizhong, Sam, and Mach,

You have been selected as MPLS-RT reviewers for draft-farrel-mpls-sfc.

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational networks),
and is the document technically sound?

We are interested in knowing whether the document is ready to be
considered for WG adoption (ie, it doesn't have to be perfect at this
point, but should be a good start). Please remember that it often is
easier to progress the document when it has become a working group
document. All comments in the MPLS-RT review needs to be addressed,
but please think carefully about whether a comment is gating the
adoption or could just as easily be addressed after the adoption.

Reviews should be sent to the document authors, WG co-chairs and WG
secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what
needs to be resolved before adopting it as a working group document, and
what can wait until the document is a working group document and the
working group has the revision control.

Are you able to review this draft by February 28, 2018? Please respond
whether you are available to do the review in a timely fashion.

Thanks, Loa
(as MPLS WG co-chair)
--

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Feb 2018 16:36:00 -0000

Thanks Lizhong,
 
We could certainly look at adding more discussion on the scope of applicability. We don't want to get into a competitive discussion wrt NSH, but since NSH naturally has more functionality, we could highlight what you cannot do in MPLS.
 
I'm curious about your implementation. You say "using per-packet metadata (strictly saying, it is per-flow)". What I read there is that the metadata for packets on a flow was constant, but that you had multiple flows mixed together so that an SF that received a packet looked at the metadata carried by the packet rather than hashing to find the flow and then looking up the metadata. Do I have this right?
 
If I have understood you, then this is the same as the function in MPLS although there is an additional indirection. That is, each packet can carry a pointer to its per flow metadata allowing multiple flows to be mixed and avoiding the need for an SF to have to work out the specific flow through hashing. 
 
However, true per-packet metadata allows the value of the metadata to vary on every packet. An example of this might be a CRC on the packet. NSH supports this, but our proposal does not.
 
Cheers,
Adrian
 
From: mpls [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: 28 February 2018 15:53
To: Loa Andersson; mpls
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] MPLS-RT review of draft-farrel-mpls-sfc
 
Hi all,
 
Regards
Lizhong
On 2/3/2018 14:02， <mailto:[email-masked]> Loa Andersson<[email-masked]> wrote： 
Matthew, Lizhong, Sam, and Mach,

Thanks, Loa
(as MPLS WG co-chair)
--

---

From: Lizhong Jin <[email-masked]>
Date: Thu, 1 Mar 2018 11:30:02 +0800

Hi Adrian, see inline below. Thanks.

Lizhong

On Thu, Mar 1, 2018 at 12:36 AM, Adrian Farrel <[email-masked]> wrote:

> Thanks Lizhong,
>
>
>
> We could certainly look at adding more discussion on the scope of
> applicability. We don't want to get into a competitive discussion wrt NSH,
> but since NSH naturally has more functionality, we could highlight what you
> cannot do in MPLS.
>
>
>
> I'm curious about your implementation. You say "using per-packet metadata
> (strictly saying, it is per-flow)". What I read there is that the metadata
> for packets on a flow was constant, but that you had multiple flows mixed
> together so that an SF that received a packet looked at the metadata
> carried by the packet rather than hashing to find the flow and then looking
> up the metadata. Do I have this right?
>
[Lizhong] Are you referring the flow identifier as metadata? The flow
identifier is only one of the metadata, and there is some other information
required to be carried between SFs, e.g., some classification result to the
next SF

>
>
> If I have understood you, then this is the same as the function in MPLS
> although there is an additional indirection. That is, each packet can carry
> a pointer to its per flow metadata allowing multiple flows to be mixed and
> avoiding the need for an SF to have to work out the specific flow through
> hashing.
>
[Lizhong] The indirection approach introduce additional per-flow state
configuration on SF, the table of metadata programmed by in-band/out-band
message. There will be more aspects need to be investigated, e.g., table
synchronization across all related SFs. While for some SF with NSH
approach, per-flow state maintenance is not required, and there is no
synchronization problem.
But the interesting thing is, if there are two many metadata required, an
indirection approach is preferred. So in some design, a mixed solution is
applied. The most frequent info is carried with packet, and also with an
metadata index to get less frequent info.

>
>
> However, true per-packet metadata allows the value of the metadata to vary
> on every packet. An example of this might be a CRC on the packet. NSH
> supports this, but our proposal does not.
>
[Lizhong] yes, and per packet info may also include timestamp, CRC checking
results, etc.

>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* mpls [mailto:[email-masked]] *On Behalf Of *Lizhong Jin
> *Sent:* 28 February 2018 15:53
> *To:* Loa Andersson; mpls
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls] MPLS-RT review of draft-farrel-mpls-sfc
>
>
>
> Hi all,
>
> This is an alternative for SFC implementation in MPLS network. Since it is
> WG adoption, not last call, basically I believe the document is ready for
> adoption.
>
> And I have one concern to the solution regarding the metadata. There is no
> per packet metadata like NSH, which will surely bring some restriction to
> the applications. I know some SFC application even does not require
> metadata, but I did one development of SFC application using per-packet
> metadata (strictly saying, it is per-flow) which is of course not under
> MPLS infrastructure.
>
> If possible, could authors add a section to describe what kind of
> capability this approach could achieve, and what could not compared with
> NSH. With that context, the operators could understand better, and easier
> to decide which solution to deploy.
>
>
>
> Regards
>
> Lizhong
>
> On 2/3/2018 14:02，Loa Andersson<[email-masked]> <[email-masked]> wrote：
>