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

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

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

> -----Original Message-----
> From: Marc Binderberger [mailto:[e-mail]] 
> Sent: Monday, May 27, 2013 1:03 PM
> To: Bhatia, Manav (Manav)
> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas 
> ([e-mail]); [e-mail]
> Subject: Re: The "version" topic (was: Reserved discriminators?)
> 
> 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
> 
> 
> > 
> > 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
> >>>>>> 
> >>>>> 
> >>>>> 
> >> 
> >> 
> 
>