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

["Nobo Akiya (nobo)" <[e-mail]>]

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