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

[Marc Binderberger <[e-mail]>]

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