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

From: Mach Chen <[email-masked]>
Date: Fri, 2 Mar 2018 03:34:47 +0000

Hi Loa,

Here are my review comments on draft-farrel-mpls-sfc-03.

Basically, I think the draft is well-written and ready for WG adoption call.  I also have some comments and questions as below:

1. The draft assumes the SF can properly process the MPLS encapsulation, how about the case where SF cannot process MPLS encapsulation? Does the draft intend to cover it? In addition, it assumes that the SF's operation would like: 1)skip the MPLS header, 2) process the payload and 3)return the packet to SFF, right? This seems like a special requirement to the SF,  more clarification text would help the readers to understand the solution.

2.  For the MPLS Swapping option, where the SPI label will be kept unchanged along the path, and the SF label will decremented, this seems not like the normal MPLS label swapping operation. In addition, to keep the SPI label unchanged along the path, it implies that SPI has to be unique within the SFC domain;  how to achieve this given that MPLS label is local significant? 

Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Saturday, February 03, 2018 2:03 PM
> To: Sam Aldrin <[email-masked]>; Mach Chen
> <[email-masked]>; Lizhong Jin <[email-masked]>; Bocci,
> Matthew (Nokia - GB) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: MPLS-RT review of draft-farrel-mpls-sfc
> 
> 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: Fri, 2 Mar 2018 10:29:23 -0000

Mach, thanks for reading.

> 1. The draft assumes the SF can properly process the MPLS encapsulation, how
> about the case where SF cannot process MPLS encapsulation? Does the draft
> intend to cover it? In addition, it assumes that the SF's operation would
like:
> 1)skip the MPLS header, 2) process the payload and 3)return the packet to SFF,
> right? This seems like a special requirement to the SF,  more clarification
text
> would help the readers to understand the solution.

Hmm, Matthew Bocci made a similar comment in his MPLS-RT review (that was not
sent to the list).

My response there was to note that there is no difference in this regard between
the NSH and an MPLS encoding. That is, SFIs that do not recognise the SFC
encoding must be "protected" by an SFC Proxy per the architecture from the SFC
WG. That proxy is semi-stateful in that it strips the SFC encapsulation before
passing the packet to the SFI, and re-imposes the encapsulation when the packet
emerges from the SFI. It might have to take special action if the SFI outputs an
error condition.

FWIW, I would probably build this proxy function into the SFF, but YMMV.

Since two of you have asked, we obviously need to clarify this in the document.
But the bottom line is that this is not different from NSH behavior.

> 2.  For the MPLS Swapping option, where the SPI label will be kept unchanged
> along the path, and the SF label will decremented, this seems not like the
normal
> MPLS label swapping operation. In addition, to keep the SPI label unchanged
> along the path, it implies that SPI has to be unique within the SFC domain;
how to
> achieve this given that MPLS label is local significant?

The SFP identifier is, indeed, domain unique.

It is my view that the SPI should mirror that and also have the same value for
the whole length of the SFP, but actually, that is not necessary. A control
protocol (just like RSVP-TE) could provide the association between the
end-to-end object (the SFP, just like the LSP) and the locally assigned labels.

I don't think that MPLS labels are completely locally significant any more.
Consider upstream assigned labels. And so I have no problem with a central
controller assigning these labels as it has to assign the SFP identifiers
anyway. The controller can then distribute the labels perhaps as an "SDN"
controller might, or maybe using a more sophisticated control plane - please
look at draft-ietf-bess-nsh-bgp-control-plane for an example.

FWIW, the implementation is likely to be "pop, swap, push".

Cheers,
Adrian