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

[Marc Binderberger <[e-mail]>]

Hello Shahram,

I learned meanwhile that Nobo plans to come out with a new draft in the near future (*), which would as a side effect also cover the redundancy.

Your comment is absolutely valid and we better put the new draft on the table before discussing the "what" and "why".

> May be just a single flag in the header

A kingdom for some header space for new flags! :-)


Thanks for your feedback,
best regards,
Marc

(*: no questions please, no sneak preview - we all just wait for Nobo's submission ;-)





On 2013-05-28, at 20:51 , Shahram Davari wrote:

> Hi,
> 
> Before going any further I suggest whoever is proposing this to write a requirements drafts so that we can better evaluate what is needed and why it is required. The next step after that is to evaluate the solutions. May be just a single flag in the header is all that is required or may be a new version is needed.
> 
> Thanks
> Shahram
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Nobo Akiya (nobo)
> Sent: Monday, May 27, 2013 9:50 AM
> To: Marc Binderberger
> Cc: Jeff Haas ([e-mail]); [e-mail]
> Subject: RE: The "version" topic (was: Reserved discriminators?)
> 
> Hello Marc,
> 
> If we conclude on extension without knowing usage requirements, we are at risk of defining it incorrectly. And we don't want to over-design to accommodate many possibilities either. IMO, it's ok to discuss, it's not ok to conclude, and "prepare" ... depends on what you mean.
> 
> "address this in parallel" will be more beneficial if there was at least one solid usage requirement.
> 
> Regards,
> Nobo
> 
>> -----Original Message-----
>> From: Marc Binderberger [mailto:[e-mail]]
>> Sent: Monday, May 27, 2013 10:58 AM
>> To: Nobo Akiya (nobo)
>> Cc: Bhatia, Manav (Manav); Jeffrey Haas; Jeff Haas ([e-mail]); rtg-
>> [e-mail]
>> Subject: Re: The "version" topic (was: Reserved discriminators?)
>> 
>> 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
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>> 
> 
> 
>