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

[G Vengada Prasad <[e-mail]>]

Hello all,
One more point that may be worth clarifying here, 
 
>> 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. 
My understanding is that there would be _no_ impact to the v1 sessions due ot the mechanism(s) proposed in the draft - they would continue to work. In other words if device-A supporting (v1 and) v2 type sessions and device-B supporting v1-only were to interop, the common minimum i.e. v1 BFD sessions would continue to work as before. device-A may keep trying (forever?) to establish v2 sessions but not get to Up state for v2 while v1 continues to work as before. Hence there would be no loss of v1 BFD functionality. This applies for any type of BFD session (Single-hop, multi-hop, MPLS label based, VCCV etc).
 
Marc/ Nobo,
 Please correct me if my understanding is inconsistent with the draft.
 
Thanks
Prasad
 
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
>>>>>> 
>>>>> 
>>>>> 
>> 
>> 
 

Regards,
Prasad.