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

["Adrian Farrel" <[e-mail]>]

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