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

[Lizhong Jin <[e-mail]>]

Hi Adrian, see inline below. Thanks.

Lizhong

On Thu, Mar 1, 2018 at 12:36 AM, Adrian Farrel <[e-mail]> 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:[e-mail]] *On Behalf Of *Lizhong Jin
> *Sent:* 28 February 2018 15:53
> *To:* Loa Andersson; mpls
> *Cc:* [e-mail]; [e-mail]
> *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<[e-mail]> <[e-mail]> 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: [e-mail]
> Senior MPLS Expert
> Huawei Technologies (consultant)     phone: [phone]
>
>