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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 5 Jan 2019 21:03:05 -0000

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).

> 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.

> 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.

Best,
Adrian

---

From: Mach Chen <[email-masked]>
Date: Mon, 7 Jan 2019 03:51:34 +0000

Hi Adrian,

Thanks for your reply!

See some response inline...

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, January 06, 2019 5:03 AM
> To: Mach Chen <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> 
> Hi Mach,
> 
> 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.
> 
> 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.

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.

> 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
> 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. 

> Now, we could debate why we have not made these answers more clear in
> the text.
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 7 Jan 2019 21:20:41 -0000

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 <[email-masked]> 
Sent: 07 January 2019 03:52
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt

Hi Adrian,

Thanks for your reply!

Best regards,
Mach

---

From: Mach Chen <[email-masked]>
Date: Thu, 10 Jan 2019 07:10:19 +0000

Hi Adrian,

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. 

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.

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} ?

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?

Best regards,
Mach

> Sent: Tuesday, January 08, 2019 5:21 AM
> 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
> 
> > 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.
> >
> > 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.
> > 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.
> 
> >
> > 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
> > 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Jan 2019 18:51:28 -0000

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. 
>
>"  
> 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.

> 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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 17 Jan 2019 19:46:04 +0000

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 <[email-masked]> 
Sent: Saturday, January 12, 2019 1:51 PM
To: 'Mach Chen' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt

Hi,

> 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.
>
>"  
> 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.

> 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.

> 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} ?

> 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"?

Best,
Adrian

> 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.
> 
> 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
> 
> > > by matching the new SPI/SI to determine to where the packet will 
> > > be
> sent.
> > >
> > 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
> 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.
> 
> >
> > 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.
> 
> > Now, we could debate why we have not made these answers more clear 
> > in the text.
> > should tell people how to implement. The purpose of the document is 
> > to describe wire formats.
> 
> 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"

---

From: Mach Chen <[email-masked]>
Date: Fri, 18 Jan 2019 01:37:24 +0000

Hi Deborah,

I am OK with it.

Best regards,
Mach

> From: BRUNGARD, DEBORAH A [mailto:[email-masked]]
> Sent: Friday, January 18, 2019 3:46 AM
> To: [email-masked]; Mach Chen <[email-masked]>; rtg-
> [email-masked]
> 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
> 
> 
> Thanks for continuing this thread. I hope that by having our discussion we can
> arrive at a solution acceptable to us both.
> 
> 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.
> 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:
> >"
> 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).
>