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

[Marc Binderberger <[e-mail]>]

Hello Nobo,

sorry when I disagree to some extend. We have to address this in parallel. Otherwise we end up with proposals for new usage that fall back into "how to squeeze it into v1" - typically you will avoid de-railing your feature discussion with the generic TLV/v2/whatever extension discussion, for loss of focus on the feature (and loss of progress, amount of time etc).

I do agree that the extension discussion becomes more relevant once the BFD audience sees more cases that won't fit easily into v1. That should not stop us to prepare a good extension story. Doesn't mean this goes to RFC anytime soon :-)


Regards, Marc




On 2013-05-27, at 16:10 , Nobo Akiya (nobo) wrote:

> Hello Marc, Manav,
> 
> As much as I would like to see more pieces to play with, I honestly don't see sufficient reasons to define such (generically speaking).
> 
> No matter how smart _how_ is, we will not get WG consensus without people seeing great value(s).
> 
> We should go back to discussing _if_ we need to define such.
> 
> Regards,
> Nobo
> 
> P.S. Your email is very interesting, I'll have to grab coffee and read this couple of more times.
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Monday, May 27, 2013 6:59 AM
>> To: Bhatia, Manav (Manav)
>> Cc: Jeffrey Haas; Nobo Akiya (nobo); Jeff Haas ([e-mail]); rtg-
>> [e-mail]
>> Subject: Re: The "version" topic (was: Reserved discriminators?)
>> 
>> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>