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

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

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

> -----Original Message-----
> From: Marc Binderberger [mailto:[e-mail]] 
> Sent: Monday, May 27, 2013 12:33 PM
> To: Bhatia, Manav (Manav)
> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas 
> ([e-mail]); [e-mail]; 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
> 
> 
> 
> On 2013-05-27, at 6:50 , Bhatia, Manav (Manav) wrote:
> 
> > 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
> >>>> 
> >>> 
> >>> 
> 
>