RE: The "version" topic (was: Reserved discriminators?)

["Bhatia, Manav (Manav)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Bhatia, Manav (Manav)
> Sent: Monday, May 27, 2013 10:07 AM
> To: Marc Binderberger; Jeffrey Haas; Nobo Akiya (nobo)
> Cc: Jeff Haas ([e-mail]); [e-mail]
> 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.
> 
>    +---------------------+ --        
>    | 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
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Marc Binderberger
> > Sent: Sunday, May 26, 2013 6:49 PM
> > To: Jeffrey Haas; Nobo Akiya (nobo)
> > Cc: Jeff Haas ([e-mail]); [e-mail]
> > Subject: The "version" topic (was: Reserved discriminators?)
> > 
> > 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
> > 
> > 
> > 
> > On 2013-05-17, at 17:35 , Nobo Akiya (nobo) wrote:
> > 
> > > Hello Jeff, et al,
> > > 
> > >> 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.
> > > 
> > > 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
> > > 
> > 
> >