Subject: [sfc] Loop prevention

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Feb 2017 11:13:56 -0500

(This is my paraphrase of the discussion.  I am posting it in my role as 
co-chair.  This is intended to promote discussion.  It is not the 
resolution.)

On the list and at the interim meeting there has been discussion of the 
fact that the SI does not serve to prevent or detect loops strictly 
among SFF.  At the interim, Adrian also observed that a reclassifier can 
produce loops and it would be highly desirable to have a way to detect 
those.

The following describes an approach to solving this problem that was 
discussed at the interim meeting.  We would like WG feedback on this, as 
if adopted it needs to go into the NSH document.
Some of the details are under-specified.  If the WG likes the approach, 
we can fill in those details.

The goal is to add a TTL field that can be decremented (or, if the WG 
prefers, increment) at every SFF and reclassifier.  It is not sued for 
forwarding, but only to detect loops.

In order to allow for large deployments, the interim felt that 6 bits of 
TTL field was enough.  So where to get the bits?

The proposal is to take the six unused flag bits, and turn them into a 
TTL field.

Then, in order to have some flag bits for future use, we take the upper 
bits (4? 3? 5?) of the corrent MD-type field and use those for flag bits 
for any new flags.

We then had a discussion on how this works with existing devices.  As 
noted in earlier discussions, we are not seeking to make those devices 
compliant, but to enable easier transition and limited interoperability.

THe first observation is that as long as none of the new flag bits are 
used, any existing device that examines the MD type field as an octet 
will understand the value.  Eventually, we expect that we will need to 
use those flags.  We hope that devices will be upgraded before then. 
And if not, well, things happen.

The harder question is how to handle the TTL with non-upgraded devices. 
Obviously, they will not adjust it.  Which is unfortunate as it reduces 
protection.  But it is not fatal.  Also, as these are flags already 
expected to be ignored on reception (like most IETF reserved fields), we 
believe that no existing implementation will break if the TTL is set.

There is one further compatibility issue.  What if the ingress 
classifier that creates the NSH header does not know how to set it. 
There seem to be two possibilities.  One is to say that we could up from 
0.  As such, existing implementations will set it correctly.  This 
works.  But it is contrary to conventional practice.  The other choice 
is to count down, but declare that 1 is expiration, and 0 means 
not-counting.  This is more limiting.

Opinions?
Thanks,
Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 7 Feb 2017 17:22:22 +0100

Joel,

I’m in favor of loop prevention along the lines that we discussed in
Westford. With specific regard to:

There is one further compatibility issue.  What if the ingress classifier
> that creates the NSH header does not know how to set it. There seem to be
> two possibilities.  One is to say that we could up from 0.  As such,
> existing implementations will set it correctly.  This works.  But it is
> contrary to conventional practice.  The other choice is to count down, but
> declare that 1 is expiration, and 0 means not-counting.  This is more
> limiting.
>
> I’m in favor of starting from zero and counting up, for maximal backwards
compatibility. Consistency to prior practice for its own sake is a poor
argument unless there’s a good technical reason for it, such as ease of
implementation.

Cheers,
Andy

PS To quote Emerson, consistency is the hobgoblin of little minds.

---

From: David Mozes <[email-masked]>
Date: Tue, 7 Feb 2017 17:15:34 +0000

Count down TTL and compare to 0  is how most of not all of the Applications  behave today

From: sfc [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] Loop prevention

Joel,

I’m in favor of loop prevention along the lines that we discussed in Westford. With specific regard to:

There is one further compatibility issue.  What if the ingress classifier that creates the NSH header does not know how to set it. There seem to be two possibilities.  One is to say that we could up from 0.  As such, existing implementations will set it correctly.  This works.  But it is contrary to conventional practice.  The other choice is to count down, but declare that 1 is expiration, and 0 means not-counting.  This is more limiting.
I’m in favor of starting from zero and counting up, for maximal backwards compatibility. Consistency to prior practice for its own sake is a poor argument unless there’s a good technical reason for it, such as ease of implementation.

Cheers,
Andy

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Feb 2017 17:32:21 +0000

To be precise, I’d like to propose this behavior by SFFs:
if(TTL !=0) then
    set TTL = TTL - 1
    if(TTL ==0) then drop
endif

This should be done when forwarding NSH (vs. receiving) to allow a packet with TTL==1 to be received at the path terminus without dropping it.

As Joel suggested, 0 means “not counting”.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of David Mozes
Sent: Tuesday, February 07, 2017 12:16 PM
To: Andrew G. Malis; Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] Loop prevention

Joel,

Cheers,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 7 Feb 2017 18:32:10 +0100

David,

Back in the 60s or 70s, that may have been the easiest way to implement,
say, IP TTL, and everything else followed. However, is increment and
compare to all ones any more difficult these days?

Cheers,
Andy

On Tue, Feb 7, 2017 at 6:15 PM, David Mozes <[email-masked]> wrote:

> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Andrew G. Malis
> *Sent:* Tuesday, February 07, 2017 6:22 PM
> *To:* Joel M. Halpern <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [sfc] Loop prevention
>
>
>
> Joel,
>
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 7 Feb 2017 18:39:37 +0100

Dave,

I agree that works, but it’s slight more complicated logic and could
potentially allow more packets to loop, those from early implementations
that don’t know how to start TTL from any value other than zero. Starting
from zero would allow loop checking for packets originating from early
implementations.

Cheers,
Andy

On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson <[email-masked]> wrote:

> This should be done when forwarding NSH (vs. receiving) to allow a packet
> with TTL==1 to be received at the path terminus without dropping it.
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *David Mozes
> *Sent:* Tuesday, February 07, 2017 12:16 PM
> *To:* Andrew G. Malis; Joel M. Halpern
> *Cc:* [email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Tue, 7 Feb 2017 18:08:06 +0000

… which would be the following, checking for TTL=0 only *after* decrementing (zero being a valid value on the wire):

    set TTL = TTL - 1     // unsigned 6-bit math; underflow from 0-->0x3f is expected
    if(TTL ==0) then drop

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 12:40 PM
To: Dave Dolson
Cc: David Mozes; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Loop prevention

Dave,

I agree that works, but it’s slight more complicated logic and could potentially allow more packets to loop, those from early implementations that don’t know how to start TTL from any value other than zero. Starting from zero would allow loop checking for packets originating from early implementations.

Cheers,
Andy

On Tue, Feb 7, 2017 at 6:32 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
To be precise, I’d like to propose this behavior by SFFs:
if(TTL !=0) then
    set TTL = TTL - 1
    if(TTL ==0) then drop
endif

-Dave

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Mozes
Sent: Tuesday, February 07, 2017 12:16 PM
To: Andrew G. Malis; Joel M. Halpern
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Loop prevention

From: sfc [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 07, 2017 6:22 PM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Loop prevention

Joel,

Cheers,
Andy

---

From: Alia Atlas <[email-masked]>
Date: Tue, 7 Feb 2017 13:14:05 -0500

[no hats]

To support a uniform tunnel mode or to get an initial TTL, it is common to
copy the
TTL from the header being encapsulated (if it has one).  Granted that there
will already
be round-off special considerations if 6 bits instead of 8 bits are used,
but this is another
aspect to consider when deciding whether to count down or up - along with
the principal
of least surprises.

Regards,
Alia

On Tue, Feb 7, 2017 at 1:08 PM, Dave Dolson <[email-masked]> wrote:

> … which would be the following, checking for TTL=0 only **after**
> decrementing (zero being a valid value on the wire):
>
>
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Tuesday, February 07, 2017 12:40 PM
> *To:* Dave Dolson
> *Cc:* David Mozes; Joel M. Halpern; [email-masked]
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>
>

---

From: David Mozes <[email-masked]>
Date: Tue, 7 Feb 2017 18:34:13 +0000

If you speak on “ALU” compare is the same these days as on 60-70  since  in the HW you will do
If (( all-x) == 0 )  today as well .
If you speak on TCAM compare it is possible .However you are limit yourself..

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 7:32 PM
To: David Mozes <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [sfc] Loop prevention

David,

Back in the 60s or 70s, that may have been the easiest way to implement, say, IP TTL, and everything else followed. However, is increment and compare to all ones any more difficult these days?

Cheers,
Andy

On Tue, Feb 7, 2017 at 6:15 PM, David Mozes <[email-masked]<mailto:[email-masked]>> wrote:
Count down TTL and compare to 0  is how most of not all of the Applications  behave today

Joel,

Cheers,
Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 10:22:24 -0000

Dave D has it right, I think.

IIRC two tests are done today anyway.
1. Does the received packet have TTL == 0
2. Would decrementing the TTL take it to 0

Obviously h/w vendors can comment, but I believe it is possible to fork on these results.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 10:27:25 -0000

Hey Joel,
 
Thanks for this write-up.
 
For those (like me)-: who need pictures, I think this represents the
conversation
 
     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|    TTL    |   Length  |    MD Type    |R|R|R|R| Proto |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
There was a second conversation that turns out to be not quite orthogonal: Do we
need the C bit?
 
If that goes away, we could have...
 
      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|     TTL     |   Length  |    MD Type    |R|R|R|R| Proto |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
[I do solemnly swear and pledge not to re-open the discussion about why the
length field can't start on a byte boundary ;-0 ]
 
Adrian
 
> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 07 February 2017 16:14
> To: [email-masked]
> Subject: [sfc] Loop prevention
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 8 Feb 2017 12:21:53 +0100

Dave D.,

This solution works for me. It provides backwards compatibility and keeps
decrementers happy! :-)

Cheers,
Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 8 Feb 2017 09:30:05 -0500

One clarification.  The proposal is to take the bits (shown as 4 R bits) 
from the MD Type field, not from the next Proto field.  Next Proto could 
easily need more than 16 values.  MD-Type currently has two values, and 
while it may need a few more, 8 or 16 would seem more than plenty.

Yours,
Joel

On 2/8/17 5:27 AM, Adrian Farrel wrote:
> There was a second conversation that turns out to be not quite
> orthogonal: Do we need the C bit?
>
>
>
> [I do solemnly swear and pledge not to re-open the discussion about why
> the length field can't start on a byte boundary ;-0 ]
>
>
>
> Adrian
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 8 Feb 2017 16:10:45 -0000

Correct.
 
You see, there is value to a figure :-)
 
  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|    TTL    |   Length  |R|R|R|R|MD Type|     Proto     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Adrian
 
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 08 February 2017 14:30
> To: [email-masked]; [email-masked]