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

[Marc Binderberger <[e-mail]>]

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 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


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


Best regards,
Marc




On 2013-05-27, at 10:00 , Bhatia, Manav (Manav) wrote:

> 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
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> 
>>>> 
>> 
>>