Hi Jim, (Wonders why Wim and Jim. Anyone called Tim want to comment?)
> 3. Support for SFs that do not handle MPLS > > There is, in our opinion no difference between an SF that does not handle > the > NSH in RFC 8300 and an SF that does not handle MPLS in this document. Both > need to use an SFC Proxy as described in this document. > > Jim> from the SF perspective yes as it has no clue what is being used between > SFFs. However, this is IMHO not a true statement from an SFF perspective; > consider metadata as an example. Yes I know you can cobble together a nice > long > label stack to try and mimic NSH behavior but seriously I do not see this as > a viable > solution and even if it was it would not be normal MPLS forwarding behavior so > would not work for brownfield. Same comment for MPLS-SR FWIW. Thanks for the kind words about cobbling ;-) Actually, as you'll see in the draft, a "long stack" is not used, but also (as noted in the draft and as previously discussed) our approach sacrifices "per packet" metadata. The problem with an SFC proxy and metadata, as I see it is that there has to be some *other* mechanism to get metadata to an SF that is not SFC-aware. That may be a set additional parameters on an RPC, or it may be some other control/management plane mechanism. But note well that PNFs legacy typically don't have any way to receive metadata before the work of your working group, and VNFs (again prior to your working group) relied on a special understanding between router and VNF if metadata was to be available. So, clearly the NSH under the SFC architecture offers the richest functional approach. But to restate what I just said to Wim, this is about bridging towards an NSH capable world without upgrading the whole network. We can achieve the basic function well, the moderate function with some effort, and the very advanced function not at all. When you see the next version to the document, could you look to see whether we could make that point more clearly (I think we put in txt about compromise and trade-offs after we last discussed this with you, but you are probably more sensitised to the point than we are, so we would welcome your eyes). Thanks, Adrian _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
