Subject: New version for draft-ashesh-bfd-stability now available

From: Ashesh Mishra <[email-masked]>
Date: Wed, 22 Oct 2014 10:01:33 -0700

Dear BFD WG,

The 01 version of the BFD Stability draft is now published and available.

https://tools.ietf.org/html/draft-ashesh-bfd-stability-01

Summary of changes from version 00:

1. The draft now only addresses BFD frame loss detection. There has been
growing demand from the industry on having such capability and the
consensus of the design team for this draft is to use a NULL-Auth TLV with
sequence numbers.

2. All references to timestamps are now removed, but the space in the TLV
is now set to "Reserved for Future". This will allow flexibility for this
idea to grow in the future, while allowing existing and future
implementations to be interoperable.

As a result, the draft is now tiny and shouldn't take long for the forum to
review :)

We'd appreciate comments from the WG.

BR,
Ashesh

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 22 Oct 2014 21:08:18 -0700

Hello Ashesh & authors,

starting with a nitpick

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref
   target="RFC2119">RFC 2119</xref>.

Something went wrong with all the "<" and ">" in the xref ;-)

What I wonder is this: what happens when the sequence number wraps? With the 
ever faster BFD intervals we have

2^32 * 3.3msec = 164 days
2^32 * 10msec  = 497 days

at least I wouldn't rule out such stable networks and routers.

Theoretically wrapping back to 0 could - according to the draft - reset the 
logic even if there is a packet loss, e.g. lets say the packet with sequence 
2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrapping 
back to 1 after reaching 2^32 - 1 ?

For the auth TLV you write:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Auth Type   |   Auth Len    |  Auth Key ID  |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved for Future                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved for Future                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

   Auth Type: The Authentication Type, which in this case is <IANA
   assigned> (Null Authentication).

   Auth Len: The length of the Authentication Section, in bytes.  Set to
   12.

   Auth Key ID: The Authentication Key ID in use for this packet.  This
   MUST be set to zero on transmit, and ignored on receipt.

   Reserved: This byte MUST be set to zero on transmit, and ignored on
   receipt.

RFC5880 has this generic form:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Auth Type   |   Auth Len    |    Authentication Data...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Auth Len

      The length, in bytes, of the authentication section, including the
      Auth Type and Auth Len fields.

Your definition of "Auth Len" does not seem to match RFC5880? Should the 
value be 16 in your case?
And why do you define the "Auth Key ID"?  Will there be potential future 
plans for it?  Otherwise you could just extend the "Reserved" field to 16 
bit. If you have future plans, I think it would be useful to mention this 
fact, so implementors are prepared.

Best regards,
Marc

---

From: Santosh P K <[email-masked]>
Date: Thu, 23 Oct 2014 09:18:10 +0000

Hello Marc,
    Thanks for your comments. Please see inline comments. 

>What I wonder is this: what happens when the sequence number wraps? With the ever faster BFD intervals we have

>Theoretically wrapping back to 0 could - according to the draft - reset the logic even if there is a packet loss, e.g. lets say the packet with sequence
>2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrapping back to 1 after reaching 2^32 - 1 ?

This is good point. I agree that we should add more details on sequence number wrapping.  I see few options to address this. 

1. Use of two reserve bits (Just like P/F) to indicate/negotiate that sequence number has wrapped, so that other end still keeps account of Lost packet.  Keeping sequence number unsigned integer. 
2.  Lollipop sequence number. This means we need to use signed integer for sequence number and start with 0 or -1. 
3. Any other suggestions? 

> And why do you define the "Auth Key ID"?  Will there be potential future plans for it?  Otherwise you could just extend the "Reserved" field to 16 bit. If you have future plans, I think it would be useful to mention this fact, so implementors are prepared.

Auth Key id might not be required as this is NULL auth. 

Thanks
Santosh P K 

What I wonder is this: what happens when the sequence number wraps? With the ever faster BFD intervals we have

Theoretically wrapping back to 0 could - according to the draft - reset the logic even if there is a packet loss, e.g. lets say the packet with sequence
2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrapping back to 1 after reaching 2^32 - 1 ?

       0                   1                   2                   3

   where:

    0                   1                   2                   3

   Auth Len

Your definition of "Auth Len" does not seem to match RFC5880? Should the value be 16 in your case?
And why do you define the "Auth Key ID"?  Will there be potential future plans for it?  Otherwise you could just extend the "Reserved" field to 16 bit. If you have future plans, I think it would be useful to mention this fact, so implementors are prepared.

Best regards,
Marc

On Wed, 22 Oct 2014 10:01:33 -0700, Ashesh Mishra wrote:
> 1. The draft now only addresses BFD frame loss detection. There has 
> been growing demand from the industry on having such capability and 
> the consensus of the design team for this draft is to use a NULL-Auth 
> TLV with sequence numbers.
> 
> 2. All references to timestamps are now removed, but the space in the 
> TLV is now set to "Reserved for Future". This will allow flexibility 
> for this idea to grow in the future, while allowing existing and 
> future implementations to be interoperable.
> 
> As a result, the draft is now tiny and shouldn't take long for the 
> forum to review :)
>

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 23 Oct 2014 16:29:30 +0200 (CEST)

>> Theoretically wrapping back to 0 could - according to the
>> draft - reset the logic even if there is a packet loss,
>> e.g. lets say the packet with sequence 2^32 - 1 is
>> missing. Maybe you want a "lollipop" sequence instead,
>> wrapping back to 1 after reaching 2^32 - 1 ?
> 
> This is good point. I agree that we should add more details on
> sequence number wrapping.  I see few options to address this.
> 
> 1.  Use of two reserve bits (Just like P/F) to
>     indicate/negotiate that sequence number has wrapped, so
>     that other end still keeps account of Lost packet.  Keeping
>     sequence number unsigned integer. 
> 2.  Lollipop sequence number. This means we need to use signed
>     integer for sequence number and start with 0 or -1.

Without having delved into the specifics of this case, may I
suggest "Serial number arithmetic" or "Seqeuence Number
Arithmetic", ref. RFC 1982?

Regards,

- Håvard

---

From: Santosh P K <[email-masked]>
Date: Thu, 23 Oct 2014 14:57:18 +0000

Havard,
   Thanks a lot. We will take a look at RFC 1982.

Thanks
Santosh P K 

-----Original Message-----
From: Havard Eidnes [mailto:[email-masked]] 
Sent: Thursday, October 23, 2014 8:00 PM
To: Santosh P K
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: New version for draft-ashesh-bfd-stability now available

>> Theoretically wrapping back to 0 could - according to the draft - 
>> reset the logic even if there is a packet loss, e.g. lets say the 
>> packet with sequence 2^32 - 1 is missing. Maybe you want a "lollipop" 
>> sequence instead, wrapping back to 1 after reaching 2^32 - 1 ?
> 

Without having delved into the specifics of this case, may I suggest "Serial number arithmetic" or "Seqeuence Number Arithmetic", ref. RFC 1982?

Regards,

- Håvard

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 24 Oct 2014 10:29:53 -0400

Ashesh,

Thanks for the update.

> As a result, the draft is now tiny and shouldn't take long for the forum to

A question I have for the working group is the management considerations for
this mechanism.  The mechanism is appropriate for determining if there's
observable loss of BFD packets, but not recommendations as to what
information should be gathered for such loss.

Would the WG benefit from a management framework for this mechanism?  These
days that probably means a yang module, but this is also potentially
amenable to an extension of the BFD MIB.

Secondary note: This mechanism theoretically could work on any meticulous
authentication scheme.  The major considerations against that are:
- The reserved space kept against further statistics.
- The overhead of meticulous authentication when actual cryptographic checks
  are performed.  (There was supposed to be a proposal for making those
  checks more reasonable coming soon. :-)

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 26 Oct 2014 13:05:20 -0700

Mahesh Jethanandani
[email-masked]

> On Oct 24, 2014, at 7:29 AM, Jeffrey Haas <[email-masked]> wrote:
> 

[With BFD YANG design group hat on]

Yes, the design group can include this in their management framework.

[With BFD YANG design group hat off]

>  checks more reasonable coming soon. :-)

The loss of BFD frames by itself would not cause an overhead per the proposed changes (yes the proposal is pending) because there would be no state change.