Re: [mpls] RtgDir review: draft-ietf-mpls-sfc-04.txt

[Mach Chen <[e-mail]>]

Hi Deborah,

I am OK with it.

Best regards,
Mach

> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
> Sent: Friday, January 18, 2019 3:46 AM
> To: [e-mail]; Mach Chen <[e-mail]>; rtg-
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> 
> Hi Mach,
> 
> Much thanks for your careful review!
> 
> It is always a difficult tradeoff on how much to add to a draft regarding
> terms/definitions from other RFCs. I've started IETF Last Call.
> 
> Thanks Authors!
> Deborah
> 
> 
> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: Saturday, January 12, 2019 1:51 PM
> To: 'Mach Chen' <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> 
> Hi,
> 
> Thanks for continuing this thread. I hope that by having our discussion we can
> arrive at a solution acceptable to us both.
> 
> > I am still thinking that this may not just be an implementation
> > problem. Looking though the draft again, I feel that the draft will
> > benefit by adding more clarification text.
> >
> > For example, I found the following text (Section 6). This paragraph
> > seems the only "formal" processing rule on the SPI/SI label for the
> swapping case.
> >
> >"
> > o  When a component of the SFC system processes a packet it uses the
> >      SPI Label to identify the SFP and the SI Label to determine to
> >      which SFF or instance of an SF (an SFI) to deliver the packet.
> >      Under normal circumstances (with the exception of branching and
> >      reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the
> >      SPI Label value is preserved on all packets.  The SI Label value
> >      is modified by SFFs and through reclassification to indicate the
> >      next hop along the SFP.
> >"
> >
> > What does the component refer to (classifier, SFF  or SF) ? Can it be an SF?
> > If so, what is the processing rule?  It seems imply that the SF should
> > be SPI/SI aware, the SPI/SI cannot be swapped, popped off. Otherwise
> > the mechanisms defined in this document will not work.
> 
> But this is *exactly* the way the issue is described for the NSH.
> If the SF is NSH-aware, the NSH is not stripped and the SF processes it. If the
> SF is not NSH-aware, then a proxy strips the NSH and reimposes it after the
> SF has completed processing.
> The NSH contains the SPI which is preserved on every packet, and the SI
> which is modified as the packet progresses.
> This processing is mirrored exactly using the two MPLS labels.
> 
> > The last sentence says that "The SI Label value is modified by SFFs",
> > when does a SFF modify the SI Label value?  For example, before
> > sending the packet to an SF or after being received from an SF?  This
> > is not clear in the current draft but. The example section gives some
> > hint on this, that's one of the reasons that I think some of the
> > content should be defined as formal procedures.
> 
> Well, the full sentence is "The SI Label value is modified by SFFs and through
> reclassification to indicate the next hop along the SFP." That means that the
> SI is modified by the SFF when it needs to forward the packet to the next
> hop. And thus we must ask "what constitutes a hop in an SFC?" The answer
> to that is that each SFI is a hop, and we can follow the logic (both from RFC
> 7665 and RFC 8300, and from this draft). The packet is classified and the SFC
> header (MPLS labels or NSH) is added with SI indicating the first SF to execute.
> The packet is sent to the SFF which delivers it to the SI, then the packet is
> returned to the SFF which prepares it for the next hop (which may be
> another local or remote SFI).
> 
> That should be obvious, IMHO, to anyone familiar with RFC 7665 and RFC
> 8300. We could add some text, but I believe it is already clear with an
> understanding of SFC.
> 
> In general, I am not opposed to adding clarifications to drafts: if someone has
> a question, then it is worth making sure that subsequent readers don't have
> identical questions. But here I think we would be encroaching on the
> definitions from the SFC working group, and we shouldn't go further.
> 
> > In addition, section 8:
> >"
> >  When an SFF receives a packet containing an MPLS label stack, it
> >   checks whether it is processing an {SFP, SI} label pair for label
> >   swapping or a {context label, SFI index} label pair for label
> >   stacking.  It then selects the appropriate SFI to which to send the
> >   packet.  When it receives the packet back from the SFI, it has four
> >   cases to consider.
> >
> >   o  If the current hop requires an {SFP, SI} and the next hop requires
> >      an {SFP, SI}, it sets the SI label to the SI value of the current
> >      hop, selects an instance of the SF to be executed at the next hop,
> >      and tunnels the packet to the SFF for that SFI.
> >
> >   o  If the current hop requires an {SFP, SI} and the next hop requires
> >      a {context label, SFI label}, it pops the {SFP, SI} from the top
> >      of the MPLS label stack and tunnels the packet to the SFF
> >      indicated by the context label.
> >"
> >
> > How does an SFF determine "the current hop requires an {SFP, SI} and
> > the next hop requires an {SFP, SI}" or "the current hop requires an
> > {SFP, SI} and the next hop requires a {context label, SFI label} ?
> 
> How the devices are programmed (e.g., a control plane or management
> plane) is out of scope. So, for example, you might have some hops that use
> NSH and some that use MPLS (I'm not saying this is a good idea) and the SFF
> would need to swap between the two encodings, but how the SFF knows
> this is out of scope of this document. Draft-ietf-bess-nsh-bgp-control-plane
> provides a way of doing this, but we didn't want to require that protocol
> mechanism (much though we love this to be *the* solution).
> 
> > Should the "it sets the SI label to the SI value of the current hop,
> > selects an instance of the SF to be executed at the next hop" be
> > changed to " it selects an instance of the SF to be executed at the
> > next hop, sets the SI label to the SI value of the next hop"?
> > The SI label should be set to next hop, right?
> 
> Yes, I think you're right about that confusion. Thanks for catching it.
> 
> Best,
> Adrian
> 
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: Tuesday, January 08, 2019 5:21 AM
> > To: Mach Chen <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> >
> > Hmmm, I think we may disagree on this ☹
> >
> > I'd ask the WG chairs and AD (especially as the review is for the
> > benefit of the
> > AD) to guide the authors.
> >
> > IMHO it is not the place of an IETF spec to tell people how to
> > implement unless the implementation changes the resultant behaviour on
> the wire.
> > From my perspective, this document tells the implementer what
> > black-box behaviour is expected: i.e. what result receiving a packet
> > should have, and what packets to generate.
> >
> > We could describe how to implement, but I can't see how that would be
> > normative. And I think there are plenty of ways to achieve the
> > required behaviour in an optimised way (for example, performing dual-
> label access).
> > We provided section 14 to give guidance that implementation using
> > existing hardware could be possible, but we didn't want to imply that
> > this was *the* way to implement.
> >
> > Best,
> > Adrian
> >
> > -----Original Message-----
> > From: Mach Chen <[e-mail]>
> > Sent: 07 January 2019 03:52
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> >
> > Hi Adrian,
> >
> > Thanks for your reply!
> >
> > See some response inline...
> >
> > > -----Original Message-----
> > > From: Adrian Farrel [mailto:[e-mail]]
> > > Sent: Sunday, January 06, 2019 5:03 AM
> > > To: Mach Chen <[e-mail]>; [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]
> > > Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> > >
> > > Hi Mach,
> > >
> > > Thanks for your careful review.
> > >
> > > > Minor Issues:
> > > > *	Section 13 says:
> > > > "
> > > >   b.  When the packet arrives at SFFa it strips any labels associated
> > > >       with the tunnel that runs from the classifier to SFFa.  SFFa
> > > >       examines the top labels and matches the SPI/SI to identify that
> > > >       the packet should be forwarded to SFa.  The packet is forwarded
> > > >       to SFa unmodified.
> > > >
> > > >   c.  SFa performs its designated function and returns the packet to
> > > >       SFFa.
> > > >
> > > >   d.  SFFa modifies the SI in the lower label stack entry (to 254) and
> > > >       uses the SPI/SI to look up the forwarding instructions.  It sends
> > > >       the packet with two label stack entries:
> > > >"
> > > > From above text, it seems that an SFF will have different process
> > > >for a
> > > packet that
> > > > has the same SPI/SI.
> > > >  1) if a packet is received from a previous SFF, it will match the
> > > > SPI/SI
> > > and determine
> > > >  to where the packet will be sent.
> > > >  2) if a packet is received from an SF, it will directly modify
> > > > the inner
> > > label, and then
> > > > by matching the new SPI/SI to determine to where the packet will
> > > > be
> > sent.
> > > >
> > > > Is this the intention ? If so, how does an SFF determine whether a
> > > > packet
> > > is from an
> > > > SFF or from SF?
> > >
> > > You have understood the processing correctly.
> > > In fact, the same situation exists with NSH processing: the SFF is
> > > expected to "know" whether the packet has arrived from the previous
> > > SFF
> > or from the SF.
> > >
> > > There are probably two answers:
> > > Firstly, it is entirely possible that the SFF and SF are co-resident.
> > > That is, they form part of the same implementation, possibly being
> > separated by an API.
> > > In this case, of course, the question does not arise.
> > > Secondly, it is reasonable to expect that the SFs are attached to
> > > the SFF by dedicated tunnels or ports (indeed, SFs are port-attached
> > > in the legacy service function world) so that a packet arriving on a
> > > line interface (from another SFF) is easily distinguished from one
> > > that arrives from an SF. (You might think about port-attached L3VPNs
> > > to help
> > clarity how this could work).
> >
> > If so, it's better to add some text to clarify this. Given the current
> > text, it implies that it could be determined just by matching the SPI/SI.
> >
> > >
> > > > In addition, how does an SFF apply the swap and/or pop operations
> here.
> > > E.g., when an SFF looks up the SPI,
> > > > it matches an item in a local table; what operation (swap or pop)
> > > > will
> > > apply to the SPI label? According to " The
> > > > packet is forwarded to SFa unmodified." It seems implies that
> > > > there is no
> > > any operation will be applied. If so,
> > > > this will not align with the MPLS.
> > >
> > > I think you should also look at this in the manner of a L3VPN. That
> > > is, the top label is popped to derive the context, the forwarding
> > > label is looked up within the context and swapped, and the context
> > > label is re-imposed as the packet is forwarded.
> > >
> > > Of course, there are optimisations on how an SFF might implement
> > > this, but we don't need to describe those. What we know is that the
> > > VPN-like approach can be made to work with existing PEs.
> >
> > As above, it's better to add some text to make it clearer.
> >
> > >
> > > > If the above issues exist, the " context/SF" case has the similar issues.
> > >
> > > Hope I have explained why this is not an issue.
> > >
> > > Now, we could debate why we have not made these answers more clear
> > > in the text.
> > > The first thing is that we are not trying to make any changes to the
> > > architecture used for NSH, so we did not feel we should go into
> > > explanations about how the SF/SFF relationship works.
> > > Additionally, we did not feel that (beyond the short section 14) we
> > > should tell people how to implement. The purpose of the document is
> > > to describe wire formats.
> >
> > IMHO, it may not be enough if just describing the wire formats, the
> > operations/process on the "formats" are necessary to make it an
> > implementable and interoperable protocol.
> >
> > Although Section 13 is listed as a worked example, I personally think
> > that they are necessary procedures. I'd suggest to change it to more
> "formal"
> > section, e.g., Procedures.
> >
> > Best regards,
> > Mach
> >
> > >
> > > Best,
> > > Adrian
>