Subject: Reserved discriminators?

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 15 May 2013 01:13:03 +0000

Dear BFD WG Members,

[paste from redundancy thread]
> Could we use discriminators ... I admit I ruled this out as we have only zero
> as a reserved value, otherwise it's up to the implementation how it assigns
> the value and the peer just reflects the discriminator back. We could start to
> define additional reserved discriminator values, e.g. 0xFFFFFFFF as the
> "shadow zero" but the problem remains that a v1-only implementation may
> see this discriminator value as a valid one (i.e. it's in use).
[snip]

Placing aside the redundancy discussion aside  ...

I'm curious what people think about reserving a range of discriminators of special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF).

That would certainly create more "lego pieces" for BFD, at the cost of sacrificing simplicity.

If majority thinks this is a good idea, then we should roll out a draft reserving them. Then people can propose ideas to (try to) grab a value from reserved range.

If majority thinks this is a bad idea, well, this email will make a good archive :)

Regards,
Nobo

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 May 2013 10:48:11 -0400

> If majority thinks this is a bad idea, well, this email will make a good archive :)

One minor point opposing this is the base RFC 5880 doesn't give much idea
for reserving discriminators.  The recommendations are effectively to
randomize them for security purposes and thus for implementations that don't
understand such reserved values, we have a very small space where a PRNG
could pick something in that range and confuse a speaker that is expecting
this to be reserved.

The usual joys of updating specs after the fact.

As a final point, apparently some implementations make use of reserved
ranges internally to provide for internal demultiplexing beyond "this is
just a random value".  Implementors with some strategies may have issue.
They should obviously speak up on this thread. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 May 2013 11:07:57 -0400

> I'm curious what people think about reserving a range of discriminators of special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF).

To take this up again specifically in the context of redundancy, blanketly
reserving discriminators for sessions may not work.  But perhaps if your
question was a bit more narrowly focused on the issue of session
boot-strapping, we may have a different possibility.

BFD procedure for bringing up a session from the Down state requires a Your
Discriminator value of 0.  For backward compatibility purposes, we cannot
change that.

But, if the reserved value was used *only* for the context of telling the
remote side "this is your redundant connection", and some reserved value was
used in Down state for Your Discriminator to help with de-multiplexing (e.g.
1 or 0xffffffff), that would be sufficient.

We still have a possibility of colliding with existing sessions if the
remote side makes use of the reserved value.  Bumping the version number is
an obvious fix but if we're going to that extent we need to think more
carefully about the full work we'd want under such a rev.

-- Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 May 2013 20:08:05 +0000

Jeff, Nobo, Marc and all,

Regarding Jeff's note that "apparently some implementations make use of reserved ranges internally to provide for internal demultiplexing beyond "this is just a random value"":

I am aware of some HW-assisted BFD implementations that use the discriminator as the address of data block keeping the session parameters in the HW assist.

I suspect this has a good potential for conflicting with the additional reserved discriminator values.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Jeffrey Haas [[email-masked]]
Sent: Wednesday, May 15, 2013 4:48 PM
To: Nobo Akiya (nobo)
Cc: Jeff Haas ([email-masked]); [email-masked]; Marc Binderberger (mbinderb)
Subject: Re: Reserved discriminators?

-- Jeff

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 15 May 2013 21:45:27 +0000

Hello Sasha,

Many thanks for chiming.

If "your discriminator" of zero(0) is special cased from mapping to data block, or maps to data block containing special instructions, then am I correct to assume that additional reserves of "certain range" can also be special cased with few more instructions?

Regards,
Nobo

> -----Original Message-----
> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Wednesday, May 15, 2013 4:08 PM
> To: Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas ([email-masked]); [email-masked]; Marc Binderberger
> (mbinderb); Ajit Ranganathan
> Subject: RE: Reserved discriminators?
> 
> Regarding Jeff's note that "apparently some implementations make use of
> reserved ranges internally to provide for internal demultiplexing beyond
> "this is just a random value"":
> 
> I am aware of some HW-assisted BFD implementations that use the
> discriminator as the address of data block keeping the session parameters in
> the HW assist.
> 
> > I'm curious what people think about reserving a range of discriminators of
> special purpose (ex: 0xFFFFFF00 - 0xFFFFFFFF).
> >
> > If majority thinks this is a good idea, then we should roll out a draft
> reserving them. Then people can propose ideas to (try to) grab a value from
> reserved range.
> >
> randomize them for security purposes and thus for implementations that
> don't understand such reserved values, we have a very small space where a
> PRNG could pick something in that range and confuse a speaker that is
> expecting this to be reserved.
> 
> ranges internally to provide for internal demultiplexing beyond "this is just
> a random value".  Implementors with some strategies may have issue.
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us by
> e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 16 May 2013 00:07:35 +0200

Hello Sasha and Nobo,

I know about two vendors who "route" the BFD packets inside the distributed architecture based on the discriminator.

So agree, such a reserved discriminator range needs careful considerations and cannot be too large.

Anyway, lets try, it may be useful for v2 :-)

Regards, Marc

On 2013-05-15, at 23:45 , Nobo Akiya (nobo) wrote:

>> (mbinderb)

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 17 May 2013 15:35:32 +0000

Hello Jeff, et al,

> remote side "this is your redundant connection", and some reserved value
> was used in Down state for Your Discriminator to help with de-multiplexing
> (e.g.

Correct, that was my thoughts. Let's say reserved value one(1) was used for shadow session bootstrapping purpose. Value one(1) of shadow is equivalent of value zero(0) of primary. If "your discriminator == 1" is received on a node which understands this, then it is to map to shadow session. De-multiplex success.

- Benefit of the redundancy concept is seen more on distributed systems or a system having at least two cards (ex: 2 route processor cards) which BFD can run actively.
- Benefit of the redundancy concept is also seen more on those BFD sessions which aren't tied to specific physical interfaces (ex: multihop, logical/virtual interfaces). 
- Redundancy concept is applicable to both SW and HW based BFD.

Scope of use case has limitations, in terms of system architecture as well as BFD type, but for those that this applies to, I still do see great benefits.

> We still have a possibility of colliding with existing sessions if the remote
> side makes use of the reserved value.  Bumping the version number is an
> obvious fix but if we're going to that extent we need to think more carefully
> about the full work we'd want under such a rev.

I still do not see any implementations which cannot support few more reserved discriminators. But a node speaking to another which doesn't support added reserved discriminator range can certainly cause undesired collision. And I agree that bumping the version number would solve this easily.

Regards,
Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 26 May 2013 15:18:42 +0200

Hello everyone,

sorry for me delayed response.

Taking a step back. If we would write RFC5880 today then we probably would have reserved a small number of discriminators, e.g. the first 8 or 16 values.  But RFC5880 is since 3 years out, the underlying draft is even much older. The statement in the Spec is effectively: dear implementor, beside the zero value do what you like with this value.  We cannot claim back parts of the number space without risking problems.

This is why I tend more and more to have clean separation, be it a new IP/UDP port like BFD-on-lags or be it a new version number. The latter faces, I think, largely a psychological problem :-)

Independent if Nobo and me can convince this audience about the redundancy concept we propose - working on it - I do see more (private) ideas that cover BFD sessions in a general sense, i.e. cover the various RFCs, single-, multi-hop, with/withou label and so on.  In all cases I see people spending time to "fiddle about the bits" of the BFD v1 and the IP header. Smart stuff but somehow crazy how wicked the new definitions become, not to mention the difficulties for implementations and for interop.

Yes, we have a limited number of versions available. Let me throw this idea at the BFD audience: the base v2 header would look like this:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1 0| Subtype |   TBD, depending on Subtype   |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       My Discriminator                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Your Discriminator                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...                                                           |

The subtype (the former Diag field) would allow for 32 new definitions. Actually I do not hope myself we define so many variations ;-) but it opens up room that we do not have with the version field alone.

To emphasize: defining a v2 header does not mean v1 is obsolete. BFD v1 works great, I'm not trying to replace it and whenever it can be used it must be used.

For the other fields above, just quickly my thoughts (if we want to dive deeper into this I better write a draft to discuss):

- length field remains in it's position, for ease of implementation

- of course I keep the discriminator concept - or it wouldn't be BFD anymore ;-) and I keep them again at the same position (the coders of NP, FPGA etc never have enough cycles or gates. And these fields are used "in hardware")

- not obvious here but I would define a relatively strict upper size limit. I'm not proposing a generic TLV format, based on the difficulties I know about implementing really fast I/O it is better to have fixed formats, IMHO.

Feedback is very welcome. And yes, I have mixed emotions myself to let the genie out of the bottle :-)

Thanks & Regards,
Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 May 2013 04:37:22 +0000

Hi Marc,

We usually do a version change when there is a very very substantial upgrade to the protocol - a kind that's usually non backward compatible.

If we really want to introduce newer fields to the packet while being backward compatible then the best approach imo is this:

You stuff whatever additional information you want in a special BFD data block immediately at the end of the BFD packet. Don't include the length of this additional BFD block in the BFD header. Instead, account for this in the IPv4/IPv6 header length.

   +---------------------+ --        
   | IP Header           | ^      
   | Length = HL+X+Y     | | Header Length 
   |                     | v               
   +---------------------+ --             
   | BFD  Header         | ^      
   | Length = X          | |      
   |.....................| | X    
   |                     | |      
   | BFD  Data           |      
   |                     | v      
   +---------------------+ --     
   |                     | ^
   | BFD Data Block      | Y
   |                     | v
   +---------------------+ --

How this additional BFD data block will be used is beyond the scope of the discussion right now. You could define that to be TLV encoded for ensuring easy extensibility.

Implementations can either implicitly figure out the presence of the BFD data block by looking at the packet lengths in the headers or can explicitly be indicated in the BFD header.

If people think it's a worthwhile idea to pursue then this can be quickly drafted.

Cheers, Manav

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Marc Binderberger
> Sent: Sunday, May 26, 2013 6:49 PM
> Cc: Jeff Haas ([email-masked]); [email-masked]
> Subject: The "version" topic (was: Reserved discriminators?)
> 
> Hello everyone,
> 
> Taking a step back. If we would write RFC5880 today then we 
> probably would have reserved a small number of 
> discriminators, e.g. the first 8 or 16 values.  But RFC5880 
> is since 3 years out, the underlying draft is even much 
> older. The statement in the Spec is effectively: dear 
> implementor, beside the zero value do what you like with this 
> value.  We cannot claim back parts of the number space 
> without risking problems.
> 
> This is why I tend more and more to have clean separation, be 
> it a new IP/UDP port like BFD-on-lags or be it a new version 
> number. The latter faces, I think, largely a psychological problem :-)
> 
> Independent if Nobo and me can convince this audience about 
> the redundancy concept we propose - working on it - I do see 
> more (private) ideas that cover BFD sessions in a general 
> sense, i.e. cover the various RFCs, single-, multi-hop, 
> with/withou label and so on.  In all cases I see people 
> spending time to "fiddle about the bits" of the BFD v1 and 
> the IP header. Smart stuff but somehow crazy how wicked the 
> new definitions become, not to mention the difficulties for 
> implementations and for interop.
> 
> 
> Yes, we have a limited number of versions available. Let me 
> throw this idea at the BFD audience: the base v2 header would 
> look like this:
> 
>     0                   1                   2                   3
> The subtype (the former Diag field) would allow for 32 new 
> definitions. Actually I do not hope myself we define so many 
> variations ;-) but it opens up room that we do not have with 
> the version field alone.
> 
> To emphasize: defining a v2 header does not mean v1 is 
> obsolete. BFD v1 works great, I'm not trying to replace it 
> and whenever it can be used it must be used.
> 
> For the other fields above, just quickly my thoughts (if we 
> want to dive deeper into this I better write a draft to discuss):
> 
> - of course I keep the discriminator concept - or it wouldn't 
> be BFD anymore ;-) and I keep them again at the same position 
> (the coders of NP, FPGA etc never have enough cycles or 
> gates. And these fields are used "in hardware")
> 
> - not obvious here but I would define a relatively strict 
> upper size limit. I'm not proposing a generic TLV format, 
> based on the difficulties I know about implementing really 
> fast I/O it is better to have fixed formats, IMHO.
> 
> 
> Feedback is very welcome. And yes, I have mixed emotions 
> myself to let the genie out of the bottle :-)
> 
> 
> Thanks & Regards,
> Marc
> 
> 
> 
> >> But, if the reserved value was used *only* for the context 
> of telling 
> >> the remote side "this is your redundant connection", and some 
> >> reserved value was used in Down state for Your 
> Discriminator to help 
> >> with de-multiplexing (e.g.
> > Correct, that was my thoughts. Let's say reserved value 
> one(1) was used for shadow session bootstrapping purpose. 
> Value one(1) of shadow is equivalent of value zero(0) of 
> primary. If "your discriminator == 1" is received on a node 
> which understands this, then it is to map to shadow session. 
> De-multiplex success.
> > 
> > - Benefit of the redundancy concept is seen more on 
> distributed systems or a system having at least two cards 
> (ex: 2 route processor cards) which BFD can run actively.
> > - Benefit of the redundancy concept is also seen more on 
> those BFD sessions which aren't tied to specific physical 
> interfaces (ex: multihop, logical/virtual interfaces). 
> > Scope of use case has limitations, in terms of system 
> architecture as well as BFD type, but for those that this 
> applies to, I still do see great benefits.
> > 
> >> We still have a possibility of colliding with existing sessions if 
> >> the remote side makes use of the reserved value.  Bumping 
> the version 
> >> number is an obvious fix but if we're going to that extent 
> we need to 
> >> think more carefully about the full work we'd want under 
> such a rev.
> > 
> > I still do not see any implementations which cannot support 
> few more reserved discriminators. But a node speaking to 
> another which doesn't support added reserved discriminator 
> range can certainly cause undesired collision. And I agree 
> that bumping the version number would solve this easily.
> > 
> > Regards,
> > Nobo
> > 
> 
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 May 2013 04:50:46 +0000

Alternatively, we can use the "Authentication Present" bit in the header to carry this additional block.

Once draft-ietf-bfd-generic-crypto-auth-04 becomes a standard we will never consume any more bits in the Auth Type as this draft introduces a Key ID mechanism. This means that Auth Type values beyond 8 are available to be used for other mechanisms.

We could for instance define value 8 meaning a BFD data block. This can then be TLV encoded.

This is again an example of how BFD can be extended while remaining completely backward compatible -- without bumping the version of BFD.

Cheers, Manav

> [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
> Sent: Monday, May 27, 2013 10:07 AM
> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo)
> Subject: RE: The "version" topic (was: Reserved discriminators?)
> 
> Hi Marc,
> 
> We usually do a version change when there is a very very 
> substantial upgrade to the protocol - a kind that's usually 
> non backward compatible.
> 
> If we really want to introduce newer fields to the packet 
> while being backward compatible then the best approach imo is this:
> 
> You stuff whatever additional information you want in a 
> special BFD data block immediately at the end of the BFD 
> packet. Don't include the length of this additional BFD block 
> in the BFD header. Instead, account for this in the IPv4/IPv6 
> header length.
> 
> How this additional BFD data block will be used is beyond the 
> scope of the discussion right now. You could define that to 
> be TLV encoded for ensuring easy extensibility.
> 
> Implementations can either implicitly figure out the presence 
> of the BFD data block by looking at the packet lengths in the 
> headers or can explicitly be indicated in the BFD header.
> 
> probably 
> > would have reserved a small number of discriminators, e.g. 
> the first 8 
> > or 16 values.  But RFC5880 is since 3 years out, the 
> underlying draft 
> > is even much older. The statement in the Spec is effectively: dear 
> > implementor, beside the zero value do what you like with 
> this value.  
> > We cannot claim back parts of the number space without risking 
> > problems.
> > 
> > This is why I tend more and more to have clean separation, 
> be it a new 
> > IP/UDP port like BFD-on-lags or be it a new version number. 
> The latter 
> > faces, I think, largely a psychological problem :-)
> > 
> > Independent if Nobo and me can convince this audience about the 
> > redundancy concept we propose - working on it - I do see more 
> > (private) ideas that cover BFD sessions in a general sense, 
> i.e. cover 
> > the various RFCs, single-, multi-hop, with/withou label and 
> so on.  In 
> > all cases I see people spending time to "fiddle about the 
> bits" of the 
> > BFD v1 and the IP header. Smart stuff but somehow crazy how 
> wicked the

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 27 May 2013 09:02:44 +0200

Hello Manav,

all fine and good - but I really don't understand this avoidance of a version change while we start looking for "ways to extend" that all have the one or other limit. What is the problem of thinking this straight forward: you have a change - forget "substantial" - or even a re-interpretation in the header, then it _is_ a new version.

Programming-wise this is clean, you have a well-defined indicator that this packet needs a different treatment. Nothing to conclude, not depending on IP header length - BFD per se is not IP related - and the right place is really the BFD header itself when your idea is for the many BFD usages (IP, IP-less).

The "backwards compatible" header I put in my last email was just the very few first fields. The rest may look very different. Even when the rest of the header would have the same size of an v1 header but I interpret them differently, then that's not v1 anymore.

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 May 2013 07:17:06 +0000

Hi Marc,

Backward incompatibility is HUGE issue (especially since BFD is usually done in HW)! :) The BFD version 2 would only work when all participating devices have upgraded to the new version. All currently deployed routers will drop these packets as they would consider the version field as invalid. So, there must be a very sound reason for taking such a drastic and a radical step - I don't think we have heard any that warrants such a significant change!

With my proposal you can incrementally add newer extensions as the earlier boxes would simply ignore this extended data block that carries the new stuff.

If youre not comfortable with adding stuff after the BFD payload then we can always take up an Auth Type (say 9) which can then be used to carry all the other interesting stuff.

Cheers, Manav

> From: Marc Binderberger [mailto:[email-masked]] 
> Sent: Monday, May 27, 2013 12:33 PM
> To: Bhatia, Manav (Manav)
> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas 
> ([email-masked]); [email-masked]; Marc Binderberger
> Subject: Re: The "version" topic (was: Reserved discriminators?)
> 
> Hello Manav,
> 
> all fine and good - but I really don't understand this 
> avoidance of a version change while we start looking for 
> "ways to extend" that all have the one or other limit. What 
> is the problem of thinking this straight forward: you have a 
> change - forget "substantial" - or even a re-interpretation 
> in the header, then it _is_ a new version.
> 
> Programming-wise this is clean, you have a well-defined 
> indicator that this packet needs a different treatment. 
> Nothing to conclude, not depending on IP header length - BFD 
> per se is not IP related - and the right place is really the 
> BFD header itself when your idea is for the many BFD usages 
> (IP, IP-less).
> 
> The "backwards compatible" header I put in my last email was 
> just the very few first fields. The rest may look very 
> different. Even when the rest of the header would have the 
> same size of an v1 header but I interpret them differently, 
> then that's not v1 anymore.
> 
> 
> Regards, Marc
> 
> 
> 
> > Alternatively, we can use the "Authentication Present" bit 
> in the header to carry this additional block.
> > 
> > Once draft-ietf-bfd-generic-crypto-auth-04 becomes a 
> standard we will never consume any more bits in the Auth Type 
> as this draft introduces a Key ID mechanism. This means that 
> Auth Type values beyond 8 are available to be used for other 
> mechanisms.
> > 
> > This is again an example of how BFD can be extended while 
> remaining completely backward compatible -- without bumping 
> the version of BFD.
> > 
> > Cheers, Manav
> > 
> substantial 
> >> upgrade to the protocol - a kind that's usually non backward 
> >> compatible.
> >> 
> while being 
> >> backward compatible then the best approach imo is this:
> >> 
> special BFD 
> >> data block immediately at the end of the BFD packet. Don't include 
> >> the length of this additional BFD block in the BFD header. 
> Instead, 
> >> account for this in the IPv4/IPv6 header length.
> >> 
> >> How this additional BFD data block will be used is beyond 
> the scope 
> >> of the discussion right now. You could define that to be 
> TLV encoded 
> >> for ensuring easy extensibility.
> >> 
> >> Implementations can either implicitly figure out the 
> presence of the 
> >> BFD data block by looking at the packet lengths in the 
> headers or can 
> >> explicitly be indicated in the BFD header.
> >> 
> >>> Yes, we have a limited number of versions available. Let me throw 
> >>> this idea at the BFD audience: the base v2 header would look like 
> >>> this:
> >>> 
> >>>    0                   1                   2                   3
> >>>   |                       My Discriminator                
>         |
> >>>   |                      Your Discriminator               
>         |
> >>>   | ...                                                   
>         |
> >>> variations ;-) but it opens up room that we do not have with the 
> >>> version field alone.
> >>> 
> obsolete. BFD 
> >>> v1 works great, I'm not trying to replace it and whenever 
> it can be 
> >>> used it must be used.
> >>> 
> >>> For the other fields above, just quickly my thoughts (if 
> we want to 
> >>> dive deeper into this I better write a draft to discuss):
> >>> 
> >>> - of course I keep the discriminator concept - or it 
> wouldn't be BFD 
> >>> anymore ;-) and I keep them again at the same position 
> (the coders 
> >>> of NP, FPGA etc never have enough cycles or gates. And 
> these fields 
> >>> are used "in hardware")
> >>> 
> upper size 
> >>> limit. I'm not proposing a generic TLV format, based on the 
> >>> difficulties I know about implementing really fast I/O it 
> is better 
> >>> to have fixed formats, IMHO.
> >>> 
> >>> 
> primary. If 
> >>> "your discriminator == 1" is received on a node which understands 
> >>> this, then it is to map to shadow session.
> >>> De-multiplex success.
> >>>> 
> interfaces 
> >>> (ex: multihop, logical/virtual interfaces).
> >>> architecture as well as BFD type, but for those that this applies 
> >>> to, I still do see great benefits.
> >>>> 
> >>> few more reserved discriminators. But a node speaking to another 
> >>> which doesn't support added reserved discriminator range can 
> >>> certainly cause undesired collision. And I agree that bumping the 
> >>> version number would solve this easily.
> >>>> 
> >>>> Regards,
> >>>> Nobo
> >>>> 
> >>> 
> >>> 
> 
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 27 May 2013 09:33:28 +0200

Hello Manav,

> Backward incompatibility is HUGE issue

that's why I talk about a version increase - not that the incompatibility must be automatically a huge issue - to cleanly separate things.

> (especially since BFD is usually done in HW)! :)

I have hardware implementations in mind as well. Exactly because you are potentially less flexible in "hacking something in" it's important to separate things.

Besides: "usually" ... then we would see more really fast BFD implementations out there, something that just started really. No, 50msec interval is not really fast ;-)

> The BFD version 2 would only work when all participating devices have upgraded to the new version.

There is still this misunderstanding that v2 means we deprecate v1. We don't. What we talk are new features. They will of course only work in an interoperable way when all participants in the setup support it - this has nothing to do with version numbers.

> All currently deployed routers will drop these packets as they would consider the version field as invalid.

Exactly that is the beauty, yes. If someone does not implement a new feature then please please drop the packet. 

> So, there must be a very sound reason for taking such a drastic and a radical step - I don't think we have heard any that warrants such a significant change!

Manav, there is no reason naming this "drastic", "radical" or whatever. When we introduce a new UDP port then equipment not supporting it is dropping these packets too as no one is listening to it. Haven't seen any such comments in such a case
(and yes, when you can do it with a new UDP port plus v1 then we go with v1. Not all cases can be covered this way though)

> With my proposal you can incrementally add newer extensions as the earlier boxes would simply ignore this extended data block that carries the new stuff.

Wrong. If the length is not correct then the packet is likely dropped. If the packet is not dropped then you are in an undefined area and can only hope for a "reasonable" behaviour. Exactly such an undefined area is what I want to avoid. Nor is processing of the new packet what you want in all cases.

> If youre not comfortable with adding stuff after the BFD payload then we can always take up an Auth Type (say 9) which can then be used to carry all the other interesting stuff.

what has this to do with auth?  This is what I name a "hack", sorry. It's exactly my problem, we "work around" instead of addressing a problem straight forward.
(I'm not surprised you bring up auth as this is an area you heavily work on ;-)

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 27 May 2013 08:00:20 +0000

Hi Marc,

The "hack" that I have suggested already exists in OSPF!:) You can read RFC 5613 for more sordid details. There are vendors that are shipping code supporting this. I wager that if they were able to work around the IP length issues in OSPF, then doing the same in BFD will not be too difficult!

Would it help if 5880bis redefines the "Auth Present" bit as "BFD data block", where BFD data block is TLV encoded. The first 8 type values would indicate that a certain kind of authentication scheme is employed. The other values would mean something else.

Cheers, Manav

> Sent: Monday, May 27, 2013 1:03 PM
> ([email-masked]); [email-masked]
> that's why I talk about a version increase - not that the 
> incompatibility must be automatically a huge issue - to 
> cleanly separate things.
> 
> I have hardware implementations in mind as well. Exactly 
> because you are potentially less flexible in "hacking 
> something in" it's important to separate things.
> 
> Besides: "usually" ... then we would see more really fast BFD 
> implementations out there, something that just started 
> really. No, 50msec interval is not really fast ;-)
> 
> 
> > The BFD version 2 would only work when all participating 
> devices have upgraded to the new version.
> 
> There is still this misunderstanding that v2 means we 
> deprecate v1. We don't. What we talk are new features. They 
> will of course only work in an interoperable way when all 
> participants in the setup support it - this has nothing to do 
> with version numbers.
> 
> 
> > All currently deployed routers will drop these packets as 
> they would consider the version field as invalid.
> 
> Exactly that is the beauty, yes. If someone does not 
> implement a new feature then please please drop the packet. 
> 
> 
> > So, there must be a very sound reason for taking such a 
> drastic and a radical step - I don't think we have heard any 
> that warrants such a significant change!
> 
> Manav, there is no reason naming this "drastic", "radical" or 
> whatever. When we introduce a new UDP port then equipment not 
> supporting it is dropping these packets too as no one is 
> listening to it. Haven't seen any such comments in such a 
> case (and yes, when you can do it with a new UDP port plus v1 
> then we go with v1. Not all cases can be covered this way though)
> 
> 
> > With my proposal you can incrementally add newer extensions 
> as the earlier boxes would simply ignore this extended data 
> block that carries the new stuff.
> 
> Wrong. If the length is not correct then the packet is likely 
> dropped. If the packet is not dropped then you are in an 
> undefined area and can only hope for a "reasonable" 
> behaviour. Exactly such an undefined area is what I want to 
> avoid. Nor is processing of the new packet what you want in all cases.
> 
> 
> > If youre not comfortable with adding stuff after the BFD 
> payload then we can always take up an Auth Type (say 9) which 
> can then be used to carry all the other interesting stuff.
> 
> what has this to do with auth?  This is what I name a "hack", 
> sorry. It's exactly my problem, we "work around" instead of 
> addressing a problem straight forward.
> avoidance of a 
> >> version change while we start looking for "ways to extend" 
> that all 
> >> have the one or other limit. What is the problem of thinking this 
> >> straight forward: you have a change - forget "substantial" 
> - or even 
> >> a re-interpretation in the header, then it _is_ a new version.
> >> 
> >> Programming-wise this is clean, you have a well-defined indicator 
> >> that this packet needs a different treatment.
> >> Nothing to conclude, not depending on IP header length - 
> BFD per se 
> >> is not IP related - and the right place is really the BFD header 
> >> itself when your idea is for the many BFD usages (IP, IP-less).
> >> 
> >> The "backwards compatible" header I put in my last email 
> was just the 
> >> very few first fields. The rest may look very different. Even when 
> >> the rest of the header would have the same size of an v1 
> header but I 
> >> interpret them differently, then that's not v1 anymore.
> >> 
> >> 
> >> Regards, Marc
> >> 
> >> 
> >> 
> >>>> If people think it's a worthwhile idea to pursue then 
> this can be 
> >>>> quickly drafted.
> >>>> 
> >>>> Cheers, Manav
> >>>>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 27 May 2013 12:58:54 +0200

Hello Manav,

oh I'm sure for every proposal you will find someone who did this already ;-)

The point would be really that BFD is not restricted to IP and you would need to make sure the transport mechanism always has some length field.

But I don't think we need this because ...

> Would it help if 5880bis redefines the "Auth Present" bit as "BFD data block", where BFD data block is TLV encoded. The first 8 type values would indicate that a certain kind of authentication sche…

... this would be a much cleaner approach. As written in our private communication I still think that the version approach is a better fit, at least for cases where you don't need or don't want all the v1 fields. Such a proposal then describes how to not use such fields, where to deviate from v1 ... practically you _do_ describe a new version (if you definition of version isn't too strict) but with the risk of some implementations stumbling as it's still a v1 packet.

Now the version approach is based on one assumption: that implementations do check the version field. Due to the BFD history with v0 and v1 I have taken this for granted

Anyway, I'm glad we have the discussion. And I hope for more opinions :-)

Best regards,
Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 27 May 2013 14:10:06 +0000

Hello Marc, Manav,

As much as I would like to see more pieces to play with, I honestly don't see sufficient reasons to define such (generically speaking).

No matter how smart _how_ is, we will not get WG consensus without people seeing great value(s).

We should go back to discussing _if_ we need to define such.

Regards,
Nobo

P.S. Your email is very interesting, I'll have to grab coffee and read this couple of more times.

> Sent: Monday, May 27, 2013 6:59 AM
> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas ([email-masked]); rtg-
> [email-masked]
> The point would be really that BFD is not restricted to IP and you would
> need to make sure the transport mechanism always has some length field.
> 
> > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data
> block", where BFD data block is TLV encoded. The first 8 type values would
> indicate that a certain kind of authentication scheme is employed. The
> other values would mean something else.
> 
> 
> ... this would be a much cleaner approach. As written in our private
> communication I still think that the version approach is a better fit, at least
> for cases where you don't need or don't want all the v1 fields. Such a
> proposal then describes how to not use such fields, where to deviate from
> v1 ... practically you _do_ describe a new version (if you definition of
> version isn't too strict) but with the risk of some implementations stumbling
> as it's still a v1 packet.
> 
> Now the version approach is based on one assumption: that
> implementations do check the version field. Due to the BFD history with v0
> and v1 I have taken this for granted
> 
> 
> > The "hack" that I have suggested already exists in OSPF!:) You can read RFC
> 5613 for more sordid details. There are vendors that are shipping code
> supporting this. I wager that if they were able to work around the IP length
> issues in OSPF, then doing the same in BFD will not be too difficult!
> >
> > Would it help if 5880bis redefines the "Auth Present" bit as "BFD data
> block", where BFD data block is TLV encoded. The first 8 type values would
> indicate that a certain kind of authentication scheme is employed. The
> other values would mean something else.
> >
> > Cheers, Manav
> >
> >> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas ([email-masked]);
> >> [email-masked]
> >> incompatibility must be automatically a huge issue - to cleanly
> >> separate things.
> >>
> >> I have hardware implementations in mind as well. Exactly because you
> >> are potentially less flexible in "hacking something in" it's
> >> important to separate things.
> >>
> >> implementations out there, something that just started really. No,
> >> 50msec interval is not really fast ;-)
> >>
> >>
> >> There is still this misunderstanding that v2 means we deprecate v1.
> >> We don't. What we talk are new features. They will of course only
> >> work in an interoperable way when all participants in the setup
> >> support it - this has nothing to do with version numbers.
> >>
> >>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 27 May 2013 16:58:18 +0200

Hello Nobo,

sorry when I disagree to some extend. We have to address this in parallel. Otherwise we end up with proposals for new usage that fall back into "how to squeeze it into v1" - typically you will avoid de-railing your feature discussion with the generic TLV/v2/whatever extension discussion, for loss of focus on the feature (and loss of progress, amount of time etc).

I do agree that the extension discussion becomes more relevant once the BFD audience sees more cases that won't fit easily into v1. That should not stop us to prepare a good extension story. Doesn't mean this goes to RFC anytime soon :-)

Regards, Marc

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 27 May 2013 16:49:33 +0000

Hello Marc,

If we conclude on extension without knowing usage requirements, we are at risk of defining it incorrectly. And we don't want to over-design to accommodate many possibilities either. IMO, it's ok to discuss, it's not ok to conclude, and "prepare" ... depends on what you mean.

"address this in parallel" will be more beneficial if there was at least one solid usage requirement.

Regards,
Nobo

> Sent: Monday, May 27, 2013 10:58 AM
> To: Nobo Akiya (nobo)
> Cc: Bhatia, Manav (Manav); Jeffrey Haas; Jeff Haas ([email-masked]); rtg-
> [email-masked]
> sorry when I disagree to some extend. We have to address this in parallel.
> Otherwise we end up with proposals for new usage that fall back into "how
> to squeeze it into v1" - typically you will avoid de-railing your feature
> discussion with the generic TLV/v2/whatever extension discussion, for loss
> of focus on the feature (and loss of progress, amount of time etc).
> 
> I do agree that the extension discussion becomes more relevant once the
> BFD audience sees more cases that won't fit easily into v1. That should not
> stop us to prepare a good extension story. Doesn't mean this goes to RFC
> anytime soon :-)
> 
> 
> Regards, Marc
> 
> 
> 
> 
> > As much as I would like to see more pieces to play with, I honestly don't
> see sufficient reasons to define such (generically speaking).
> >
> >> rtg- [email-masked]
> >> The point would be really that BFD is not restricted to IP and you
> >> would need to make sure the transport mechanism always has some
> length field.
> >>
> >> block", where BFD data block is TLV encoded. The first 8 type values
> >> would indicate that a certain kind of authentication scheme is
> >> employed. The other values would mean something else.
> >>
> >>
> >> communication I still think that the version approach is a better
> >> fit, at least for cases where you don't need or don't want all the v1
> >> fields. Such a proposal then describes how to not use such fields,
> >> where to deviate from
> >> v1 ... practically you _do_ describe a new version (if you definition
> >> of version isn't too strict) but with the risk of some
> >> implementations stumbling as it's still a v1 packet.
> >>
> >> implementations do check the version field. Due to the BFD history
> >> with v0 and v1 I have taken this for granted
> >>
> >>
> >> 5613 for more sordid details. There are vendors that are shipping
> >> code supporting this. I wager that if they were able to work around
> >> the IP length issues in OSPF, then doing the same in BFD will not be too
> difficult!
> >>>
> >> block", where BFD data block is TLV encoded. The first 8 type values
> >> would indicate that a certain kind of authentication scheme is
> >> employed. The other values would mean something else.
> >>>
> >>> Cheers, Manav
> >>>
> >>>> I have hardware implementations in mind as well. Exactly because
> >>>> you are potentially less flexible in "hacking something in" it's
> >>>> Exactly that is the beauty, yes. If someone does not implement a
> >>>> new feature then please please drop the packet.
> >>>>
> >>>>
> >>>> drastic and a radical step - I don't think we have heard any that
> >>>> warrants such a significant change!
> >>>>
> >>>> supporting it is dropping these packets too as no one is listening
> >>>> to it. Haven't seen any such comments in such a case (and yes, when
> >>>> you can do it with a new UDP port plus v1 then we go with v1. Not
> >>>> all cases can be covered this way though)
> >>>>
> >>>>
> >>>> as the earlier boxes would simply ignore this extended data block
> >>>> that carries the new stuff.
> >>>>
> >>>> dropped. If the packet is not dropped then you are in an undefined
> >>>> area and can only hope for a "reasonable"
> >>>> behaviour. Exactly such an undefined area is what I want to avoid.
> >>>> Nor is processing of the new packet what you want in all cases.
> >>>>
> >>>>
> >>>> payload then we can always take up an Auth Type (say 9) which can
> >>>> then be used to carry all the other interesting stuff.
> >>>>
> >>>>>> very few first fields. The rest may look very different. Even
> >>>>>> when the rest of the header would have the same size of an v1
> >>>> header but I
> >>>>>> standard we will never consume any more bits in the Auth Type as
> >>>>>> this draft introduces a Key ID mechanism. This means that Auth
> >>>>>> Type values beyond 8 are available to be used for other
> >>>>>> mechanisms.
> >>>>>>>
> >>>>>> remaining completely backward compatible -- without bumping the
> >>>>>> version of BFD.
> >>>>>>>
> >>>>>>> Cheers, Manav
> >>>>>>>
> >>>>>>>>> more
> >>>>>>>>>>> the remote side "this is your redundant connection", and
> >>>>>>>>>>> some reserved value was used in Down state for Your
> >>>>>>>>> Discriminator to help

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 28 May 2013 18:51:54 +0000

Hi,

Before going any further I suggest whoever is proposing this to write a requirements drafts so that we can better evaluate what is needed and why it is required. The next step after that is to evaluate the solutions. May be just a single flag in the header is all that is required or may be a new version is needed.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Monday, May 27, 2013 9:50 AM
To: Marc Binderberger
Cc: Jeff Haas ([email-masked]); [email-masked]
Subject: RE: The "version" topic (was: Reserved discriminators?)

Hello Marc,

Regards,
Nobo

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 29 May 2013 15:32:05 +0200

Hello Shahram,

I learned meanwhile that Nobo plans to come out with a new draft in the near future (*), which would as a side effect also cover the redundancy.

Your comment is absolutely valid and we better put the new draft on the table before discussing the "what" and "why".

> May be just a single flag in the header

A kingdom for some header space for new flags! :-)

Thanks for your feedback,
best regards,
Marc

(*: no questions please, no sneak preview - we all just wait for Nobo's submission ;-)