Subject: [sfc] NSH enhancement for SFC loop prevention

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 19:30:56 +0000

Hi All,

The SFC architecture [RF7665] specifies the service function chaining architecture with SF, SFF, and classifier components, which forms the SFC service layer on top of transport networks. NSH [draft ietf-sfc-nsh] defines the SFC encapsulation protocol to facilitate SFC data plane functions. The SFC architecture and NSH are designed so that an SFF receiving an NSH packet from another SFF must not directly forward the packet to another SFF in a SFC domain, i.e. an NSH packets must not traverse through two SFFs in a row.

However, the current NSH protocol does not have an ability to detect this in the data plane if it happens in an environment or by a mis-configuration. If this happens, it can cause a loop among a set of SFFs. Underlying transport can't help to detect this either.  Eric Rosen raised this issue recently (https://mailarchive.ietf.org/arch/msg/sfc/9GLSpNCPnDuGIrfcbMisN1KOYvg). Although we can argue that the given scenario is not valid or not proper, SFC design/implementation should be robust enough to detect such errors whatever caused them.

A simple NSH enhancement can detect this and prevent a loop among SFFs. That is to allocate2 bits from the reserved bits in NSH base header, call it the loop prevention field (LP);  an SFF performs a simple algorithm when receiving an NSH packet as follow:

Taken the LP value from the NSH header on the packet
If LP < 1 then
    LP++;
Else
 Report error;
 Drop the packet;
End if

In addition, a classifier sets LP to zero; and upon receiving an NSH packet, an SFC-aware SF sets the LP to zero.

We propose adding this enhancement to the NSH protocol [draft-ietf-sfc-nsh] to address the issue.

Thanks,
Lucy and Donald

---

From: Dave Dolson <[email-masked]>
Date: Mon, 5 Dec 2016 19:57:11 +0000

Lucy,

"The SFC architecture and NSH are designed so that an SFF receiving an NSH packet from another SFF must not directly forward the packet to another SFF in a SFC domain, i.e. an NSH packets must not traverse through two SFFs in a row."
I did not believe this restriction to be true.

I think you have a good idea, but I would use more than 2 bits, to allow for multiple SFF hops. How about 4 bits?

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|C|HopCnt |R|R|   Length  |    MD Type    | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think this idea will also be important to implement a "transcending trace-route" at the NSH layer, allowing a "TTL expired" from an SFF.
(Or do we need 8 bits for that??  Would 6 bits work?)

Also, I think your idea is backwards compatible because a naïve sender will set the (currently) reserved bits to 0, and a naïve receiver will ignore them.

So I'm in favor of doing it.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, December 05, 2016 2:31 PM
To: [email-masked]
Subject: [sfc] NSH enhancement for SFC loop prevention

Hi All,

Thanks,
Lucy and Donald

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 20:01:22 +0000

Hi Dave,

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, December 05, 2016 1:57 PM
To: Lucy yong; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

Lucy,

"The SFC architecture and NSH are designed so that an SFF receiving an NSH packet from another SFF must not directly forward the packet to another SFF in a SFC domain, i.e. an NSH packets must not traverse through two SFFs in a row."
I did not believe this restriction to be true.
[Lucy] Could you explain why this is not the restriction by SFC, i.e. at which case, SFC needs to send to a set of SFFs in a row?

Lucy

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, December 05, 2016 2:31 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] NSH enhancement for SFC loop prevention

Hi All,

Thanks,
Lucy and Donald

---

From: Ron Parker <[email-masked]>
Date: Mon, 5 Dec 2016 20:39:23 +0000

Strictly speaking, if a local bypass is in effect (SF has opted out of additional packets for the flow and informed SFF appropriately), then an SFF may, indeed, receive a packet from classifier or a predecessor SFF and do nothing more than forward it to another SFF.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, December 5, 2016 2:57 PM
To: Lucy yong <[email-masked]>; [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 20:39:18 +0000

(Resend it with an error correction.)

Hi All,

If LP <= 1 then
    LP++;
Else
 Report error;
 Drop the packet;
End if

Thanks,
Lucy and Donald

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 20:55:36 +0000

Hi Ron,

A good example. For a local bypass, i.e. SF offload, NSH packet may still pass to the SFF that the offload SF attaches to. In this case, the SFF should have a state of the offload; when it happens, it resets the LP to zero and increments SI on the NSH header before forwarding it. If NSH packet skips the SFF that offload SF attaches to, it works as normal.

Lucy

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 05, 2016 2:39 PM
To: Dave Dolson; Lucy yong; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Monday, December 5, 2016 2:57 PM
To: Lucy yong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Dave Dolson <[email-masked]>
Date: Mon, 5 Dec 2016 21:24:31 +0000

Also, this Figure 5, taken from RFC7665, clearly shows two SFF between each SF:

                +---+ +---+ +---+   +---+ +---+ +---+
                |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                +---+ +---+ +---+   +---+ +---+ +---+
                  |     |     |       |     |     |
                  +-----+-----+       +-----+-----+
                        |                   |
                        +                   +
             +---+    +---+     +---+     +---+    +---+
   source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
             +---+    +---+     +---+     +---+    +---+
               +                  +                  +
               |                  |                  |
             +---+              +---+              +---+
             |sf1|              |sf3|              |sf5|
             +---+              +---+              +---+

                         Figure 5: Load Balancing

>From SF1 to sf2 requires transiting two sffs. In the case of local bypass, it would be 3.

If the point is to identify loops, I think a hop limit of 15 would be appropriate, with different per-site policy perhaps.

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 05, 2016 3:39 PM
To: Dave Dolson; Lucy yong; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

   Ron

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 21:34:35 +0000

Dave,

Thank you for showing this. Will that mean that, if sf3 on the fouth sff (left to right) is selected by LB policy, the second SFF has to forward to the NSH packets to the third sff first? Why?

Thanks,
Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, December 05, 2016 3:25 PM
To: Ron Parker; Lucy yong; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

                         Figure 5: Load Balancing

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, December 05, 2016 3:39 PM
To: Dave Dolson; Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: RE: NSH enhancement for SFC loop prevention

   Ron

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Dave Dolson <[email-masked]>
Date: Mon, 5 Dec 2016 21:42:47 +0000

I would expect sff1 could forward directly to sff4 (counting left to right), if so configured.
However, I think in general there are two SFFs between each hop, due to SFs being connected to different SFFs.

Having said that, I think it is useful to think of SPI/SI as an address, and any number of SFFs could be involved in delivering it.
So maybe the operator wants SFF1 to have a simple forwarding table, using SFF2 for all of the next hops.

So my position is that a hop limit seems useful - but it should be more than 3 (2 bits).

-Dave

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, December 05, 2016 4:35 PM
To: Dave Dolson; Ron Parker; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

Dave,

Thanks,
Lucy

                         Figure 5: Load Balancing

   Ron

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 22:03:16 +0000

[Lucy] Sorry, I do not get this. SFC is about a chain of SFs. SFC architecture uses SFF to support SFC implementation. It is not about a chain of SFF.

This enhancement is to mandate that, upon receiving a NSH packet, a SFF has to forward the packet to at least one SF associated to the SFF prior to forwarding the packet to another SFF.

Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, December 05, 2016 3:43 PM
To: Lucy yong; Ron Parker; [email-masked]
Subject: RE: NSH enhancement for SFC loop prevention

-Dave

From: Lucy yong [mailto:[email-masked]]
Sent: Monday, December 05, 2016 4:35 PM
To: Dave Dolson; Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: RE: NSH enhancement for SFC loop prevention

Dave,

Thanks,
Lucy

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, December 05, 2016 3:25 PM
To: Ron Parker; Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: RE: NSH enhancement for SFC loop prevention

                         Figure 5: Load Balancing

   Ron

Lucy,

-Dave

Hi All,

Thanks,
Lucy and Donald

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 5 Dec 2016 17:22:23 -0500

Without taking a stance on the underlying topic, let me see if I can 
help the communication.

Lucy, your text talked about one SFF.  Dave is talking about there 
always beign two SFF.
I believe you are both saying the same thing.  A packet comes from an 
NSH-aware SF (or from an SFC proxy.)  It goes to an SFF(A).  That SFF 
sendsthe packet to another SFF(B).  Which sends the packet to the next 
SF.  Thus, there are two SFF (A and B) in the path.  I believe you 
actually agree on this, but are saying it differently.

We have tended to assume that since this is an overlay, there is no need 
to go through intermediate SFF to get from SFF(A) to SFF(B).  That is 
not explicitly required by the architecture or the NSH document.

I believe Dave is therefore raising the question of whether, if we are 
going to use a mechanism like this, we need to allow an SFF sequence 
longer than two SFF.

I will note that the issue of potential loops in inter-SFF forwarding 
has been discussed on the list before, and no change was adopted at that 
time.

Yours,
Joel

On 12/5/16 5:03 PM, Lucy yong wrote:
> [Lucy] Sorry, I do not get this. SFC is about a chain of SFs. SFC
> architecture uses SFF to support SFC implementation. It is not about a
> chain of SFF.
>
>
>
> This enhancement is to mandate that, upon receiving a NSH packet, a SFF
> has to forward the packet to at least one SF associated to the SFF prior
> to forwarding the packet to another SFF.
>
>
>
> Lucy
>
> / /
>
> / /
>
> / /
>
> *From:*Dave Dolson [mailto:[email-masked]]
> *Sent:* Monday, December 05, 2016 3:43 PM
> *To:* Lucy yong; Ron Parker; [email-masked]
> *Subject:* RE: NSH enhancement for SFC loop prevention
>
>
>
> Having said that, I think it is useful to think of SPI/SI as an address,
> and any number of SFFs could be involved in delivering it.
>
> So my position is that a hop limit seems useful – but it should be more
> than 3 (2 bits).
>
>
>
> -Dave
>
>
>
>
>
>
>
>
>
> *From:*Lucy yong [mailto:[email-masked]]
> *Sent:* Monday, December 05, 2016 4:35 PM
> *To:* Dave Dolson; Ron Parker; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: NSH enhancement for SFC loop prevention
>
>
>
> /Dave,/
>
> / /
>
> /Thank you for showing this. Will that mean that, if sf3 on the fouth
> sff (left to right) is selected by LB policy, the second SFF has to
> forward to the NSH packets to the third sff first? Why?/
>
> / /
>
> / /
>
> /Thanks,/
>
> /Lucy/
>
> / /
>
> / /
>
> *From:*Dave Dolson [mailto:[email-masked]]
> *Sent:* Monday, December 05, 2016 3:25 PM
> *To:* Ron Parker; Lucy yong; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: NSH enhancement for SFC loop prevention
>
>
>
> If the point is to identify loops, I think a hop limit of 15 would be
> appropriate, with different per-site policy perhaps.
>
>
>
>
>
>
>
> *From:*Ron Parker [mailto:[email-masked]]
> *Sent:* Monday, December 05, 2016 3:39 PM
> *To:* Dave Dolson; Lucy yong; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: NSH enhancement for SFC loop prevention
>
>
>
> Strictly speaking, if a local bypass is in effect (SF has opted out of
> additional packets for the flow and informed SFF appropriately), then an
> SFF may, indeed, receive a packet from classifier or a predecessor SFF
> and do nothing more than forward it to another SFF.
>
>
>
>    Ron
>
>
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Dave Dolson
> *Sent:* Monday, December 5, 2016 2:57 PM
> *To:* Lucy yong <[email-masked] <mailto:[email-masked]>>;
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] NSH enhancement for SFC loop prevention
>
>
>
> Lucy,
>
>
>
> “The SFC architecture and NSH are designed so that an SFF receiving an
> NSH packet from another SFF must not directly forward the packet to
> another SFF in a SFC domain, i.e. an NSH packets must not traverse
> through two SFFs in a row.”
>
> I think this idea will also be important to implement a “transcending
> trace-route” at the NSH layer, allowing a “TTL expired” from an SFF.
>
> Also, I think your idea is backwards compatible because a naïve sender
> will set the (currently) reserved bits to 0, and a naïve receiver will
> ignore them.
>
>
>
> So I’m in favor of doing it.
>
>
>
> -Dave
>
>
>
>
>
>
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Lucy yong
> *Sent:* Monday, December 05, 2016 2:31 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] NSH enhancement for SFC loop prevention
>
>
>
> Hi All,
>
>
>
> The SFC architecture [RF7665] specifies the service function chaining
> architecture with SF, SFF, and classifier components, which forms the
> SFC service layer on top of transport networks. NSH [draft ietf-sfc-nsh]
> defines the SFC encapsulation protocol to facilitate SFC data plane
> functions. The SFC architecture and NSH are designed so that an SFF
> receiving an NSH packet from another SFF must not directly forward the
> packet to another SFF in a SFC domain, i.e. an NSH packets must not
> traverse through two SFFs in a row.
>
>
>
> However, the current NSH protocol does not have an ability to detect
> this in the data plane if it happens in an environment or by a
> mis-configuration. If this happens, it can cause a loop among a set of
> SFFs. Underlying transport can’t help to detect this either.  Eric Rosen
> raised this issue recently
> (https://mailarchive.ietf.org/arch/msg/sfc/9GLSpNCPnDuGIrfcbMisN1KOYvg).
> Although we can argue that the given scenario is not valid or not
> proper, SFC design/implementation should be robust enough to detect such
> errors whatever caused them.
>
>
>
> A simple NSH enhancement can detect this and prevent a loop among SFFs.
> That is to allocate2 bits from the reserved bits in NSH base header,
> call it the loop prevention field (LP);  an SFF performs a simple
> algorithm when receiving an NSH packet as follow:
>
>
>
> In addition, a classifier sets LP to zero; and upon receiving an NSH
> packet, an SFC-aware SF sets the LP to zero.
>
>
>
> We propose adding this enhancement to the NSH protocol
> [draft-ietf-sfc-nsh] to address the issue.
>
>
>
> Thanks,
>
> Lucy and Donald
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 5 Dec 2016 22:56:56 +0000

Hi Joel,

Thank you for the explanation. That helps.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, December 05, 2016 4:22 PM
To: Lucy yong; Dave Dolson; Ron Parker; [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Without taking a stance on the underlying topic, let me see if I can help the communication.

Lucy, your text talked about one SFF.  Dave is talking about there always beign two SFF.
I believe you are both saying the same thing.  A packet comes from an NSH-aware SF (or from an SFC proxy.)  It goes to an SFF(A).  That SFF sendsthe packet to another SFF(B).  Which sends the packet to the next SF.  Thus, there are two SFF (A and B) in the path.  I believe you actually agree on this, but are saying it differently.
[Lucy] Yes, we say the same.

We have tended to assume that since this is an overlay, there is no need to go through intermediate SFF to get from SFF(A) to SFF(B).  That is not explicitly required by the architecture or the NSH document.

I believe Dave is therefore raising the question of whether, if we are going to use a mechanism like this, we need to allow an SFF sequence longer than two SFF.
[Lucy] Do we? Could we come out a reasonable use case for the usage? I don't think that the SF offload means it and SFF is not a router.

I will note that the issue of potential loops in inter-SFF forwarding has been discussed on the list before, and no change was adopted at that time.
[Lucy] IMO: NSH is the protocol to run in SFC data plane. It should be responsible to detect a loop problem for the robustness. 

Lucy

Yours,
Joel

On 12/5/16 5:03 PM, Lucy yong wrote:
> However, I think in general there are two SFFs between each hop, due 
> to SFs being connected to different SFFs.
>
>
>
> This enhancement is to mandate that, upon receiving a NSH packet, a 
> SFF has to forward the packet to at least one SF associated to the SFF 
> prior to forwarding the packet to another SFF.
>
>
>
> Lucy
>
> / /
>
> / /
>
> / /
>
> However, I think in general there are two SFFs between each hop, due 
> to SFs being connected to different SFFs.
>
>
>
> Having said that, I think it is useful to think of SPI/SI as an 
> address, and any number of SFFs could be involved in delivering it.
>
> additional packets for the flow and informed SFF appropriately), then 
> an SFF may, indeed, receive a packet from classifier or a predecessor 
> SFF and do nothing more than forward it to another SFF.
>
>
>
>    Ron
>
>
>
>
>
> "The SFC architecture and NSH are designed so that an SFF receiving an 
> through two SFFs in a row."
>
> I think you have a good idea, but I would use more than 2 bits, to 
> allow for multiple SFF hops. How about 4 bits?
>
>
>
> I think this idea will also be important to implement a "transcending 
> trace-route" at the NSH layer, allowing a "TTL expired" from an SFF.
>
> SFC service layer on top of transport networks. NSH [draft 
> ietf-sfc-nsh] defines the SFC encapsulation protocol to facilitate SFC 
> data plane functions. The SFC architecture and NSH are designed so 
> that an SFF receiving an NSH packet from another SFF must not directly 
> forward the packet to another SFF in a SFC domain, i.e. an NSH packets 
> must not traverse through two SFFs in a row.
>
>
>
> SFFs. Underlying transport can't help to detect this either.  Eric 
> Rosen raised this issue recently 
> proper, SFC design/implementation should be robust enough to detect 
> such errors whatever caused them.
>
>
>

---

From: Dave Dolson <[email-masked]>
Date: Mon, 5 Dec 2016 23:19:05 +0000

Yes Joel, I think you've correctly restated my view.

Regarding the need, I think we should look at how hop count can support (transcending) trace-route in addition to loop detection.

‎-Dave

  Original Message
From: Joel M. Halpern
Sent: Monday, December 5, 2016 5:22 PM
To: Lucy yong; Dave Dolson; Ron Parker; [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Tue, 6 Dec 2016 17:32:49 +0000

Hi Dave, Chairs, et al,

How do we progress on this? Will you have some proposal on that?

IMO: this is important for NSH to cover loop prevention. 

Regards,
Lucy
-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Monday, December 05, 2016 5:19 PM
To: Joel M. Halpern; Lucy yong; Ron Parker; [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

‎-Dave

  Original Message
From: Joel M. Halpern

Yours,
Joel

On 12/5/16 5:03 PM, Lucy yong wrote:
> So my position is that a hop limit seems useful – but it should be 
> more than 3 (2 bits).
>
>
>
> -Dave
>
>
>
>
>
>
>
>
>
> SFFs. Underlying transport can’t help to detect this either.  Eric

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 8 Dec 2016 19:00:22 +0000

Joel,

I'm replying to you since you summarized the discussion.  We need to be clear here: NSH defines solely the service path.  But even more importantly, the SFF to SFF to SFF is clearly a misconfiguration that can be prevented at the control plane level.   

Verification of SPI/SI can be used to ensure valid service topology.  For instance, an SFF can perform several checks to ensure that the "right" NSH packet is processed.  As the draft already describes, packets with invalid/incorrect values are discarded.  In addition to that base validation, an SFF can ensure that expected values are received via a given transport overlay.  For example, if an SFF send SPI=100, SI=200 to an SF, then it expects to receive 100/199 back via that transport (implementation dictates how the transport/NSH mapping occurs), any other values will be dropped.  Lastly, the draft mentions that SI=0 can be viewed as a exception case that indicates an error.

As I mentioned above, since NSH only defines the service path, we cannot obviate the role of the network transport overlay.  Loop detection occurs here, many several types of validation can occur ranging from topology checks to NSH to overlay mapping validation.

Adding addtionaly complexy to address this, when several mechanisms already exist is unnecessary.

Paul

> On Dec 5, 2016, at 5:22 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Dave Dolson <[email-masked]>
Date: Thu, 8 Dec 2016 19:15:44 +0000

Paul,
From your note below, only one mechanism addresses the problem of identifying incorrect configuration resulting in forwarding loop: verifying SPI/SI is received on the correct transport.

However, that mechanism itself depends on correct configuration of expected transports per SPI/SI.
In my mind, that's just another mechanism for introducing errors--e.g., blocking traffic when it shouldn't be blocked with faulty ingress rules.
I would go so far as to say that this introduces unnecessary complexity whereas hop-count is a simple and proven mechanism.

I think it's more honest to say, when doing SDN there are hundreds of ways of making forwarding loops, and this is just one more way.

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, December 08, 2016 2:00 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Joel,

Paul

---

From: Lucy yong <[email-masked]>
Date: Thu, 8 Dec 2016 21:31:15 +0000

I agree with Dave, SFC data plane should have a way to detect a loop, not fully rely on control plane to deal with it.  

First of all, could we agree that "SFF to SFF to SFF" is a misconfiguration? 

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Thursday, December 08, 2016 1:16 PM
To: Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Paul,

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, December 08, 2016 2:00 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] NSH enhancement for SFC loop prevention

Joel,

Paul

>> architecture uses SFF to support SFC implementation. It is not about 
>> a chain of SFF.
>> 
>> 
>> 
>> SFF has to forward the packet to at least one SF associated to the 
>> SFF prior to forwarding the packet to another SFF.
>> 
>> 
>> 
>> Lucy
>> 
>> / /
>> 
>> / /
>> 
>> / /
>> 
>> Strictly speaking, if a local bypass is in effect (SF has opted out 
>> of additional packets for the flow and informed SFF appropriately), 
>> then an SFF may, indeed, receive a packet from classifier or a 
>> predecessor SFF and do nothing more than forward it to another SFF.
>> 
>> 
>> 
>>   Ron
>> 
>> 
>> 
>> 
>> 
>> “The SFC architecture and NSH are designed so that an SFF receiving 
>> an NSH packet from another SFF must not directly forward the packet 
>> to another SFF in a SFC domain, i.e. an NSH packets must not traverse 
>> Also, I think your idea is backwards compatible because a naïve 
>> sender will set the (currently) reserved bits to 0, and a naïve 
>> receiver will ignore them.
>> 
>> 
>> 
>> ietf-sfc-nsh] defines the SFC encapsulation protocol to facilitate 
>> SFC data plane functions. The SFC architecture and NSH are designed 
>> so that an SFF receiving an NSH packet from another SFF must not 
>> directly forward the packet to another SFF in a SFC domain, i.e. an 
>> NSH packets must not traverse through two SFFs in a row.
>> 
>> 
>> 
>> mis-configuration. If this happens, it can cause a loop among a set 
>> of SFFs. Underlying transport can’t help to detect this either.  Eric