Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

[Stan Ratliff <[e-mail]>]

On Fri, Apr 22, 2016 at 10:35 AM, Justin Dean <[e-mail]> wrote:

> Speaking as participant.
>
> I kind of like the idea of using the experimental message type space.  We
> only have a limited amount of these message types.  The TLV assignments
> could just use the message type specific space and there isn't an issue
> there.  IANA wouldn't assign a number but I don't see why the document
> couldn't specify the experimental numbers it was going to use so other
> future near term experiential protocols could do the same and generally
> avoid conflict.  If the experiment is successful IANA assignments could be
> made.  Functionally no real difference with protections vs long term usage
> of limited space.
>

+1 here.

Regards,
Stan




>
> Justin
>
> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
> [e-mail]> wrote:
>
>> There's rather a contradiction between the concepts of a definition of a
>> protocol, even Experimental, and experimental space, which usually assumes
>> that the user can do what he or she likes in it.
>>
>> But chewing up messages types (how many, 3?) of which there are
>> relatively few for experimental is long term a problem, although short term
>> not.
>>
>> TLV space is easier in two regards. It's bigger (though the prime real
>> estate of type extension zero isn't) and can have message type specific
>> TLVs.
>>
>> So TLVS can actually be invisible, if that option is chosen. For messages
>> something has to give. Least bad option is again one of those we should
>> discuss, but time ...
>>
>> (To be precise, messages types from 224 are defined in RFC 5444 as "
>> Experimental Use", of which BCP 26 says "Similar to private or local use
>> only, with the  purpose being to facilitate experimentation." The
>> alternative 0-223 space is Expert Review. IANA still thinks the experts are
>> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>>
>> --
>> Christopher Dearlove
>> Senior Principal Engineer
>> BAE Systems Applied Intelligence Laboratories
>> __________________________________________________________________________
>>
>> T:  [phone]  |  E: [e-mail]
>>
>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>> Baddow, Chelmsford, Essex CM2 8HN.
>> www.baesystems.com/ai
>> BAE Systems Applied Intelligence Limited
>> Registered in England & Wales No: 01337451
>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>>
>>
>> -----Original Message-----
>> From: Thomas Heide Clausen [mailto:[e-mail]]
>> Sent: 22 April 2016 14:21
>> To: Dearlove, Christopher (UK)
>> Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
>> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>>
>> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partner
>> or from the internet.
>> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> Follow the 'Report Suspicious Emails' link on IT matters for instructions
>> on reporting suspicious email messages.
>> --------------------------------------------------------
>>
>>
>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
>> [e-mail]> wrote:
>> >
>> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
>> (working assumption for this discussion) you have more liberty.
>> >
>>
>> Yep.
>>
>> Taken somewhat by surprise both by the sudden "rush" and the experimental
>> maturity level, I am wondering (and haven't thought through) about
>> experimental space vs non-experimental (for message types, and consequently
>> for message type specific TLV types).
>>
>> I think that if the AODVv2 experiment specifies the use of Message types
>> from the Experimental message type space without making actual
>> registrations in the IANA registry, AND the use of type specific TLV types,
>> this becomes a non-issue entirely (by design, this is precisely what that
>> experimental space is for)
>>
>> Whereas, as you point out, the alternative is a "can open - worms
>> everywhere" situation that I think time is too short to solve?
>>
>> Thomas
>>
>>
>> > Then you could try specifying it. But with a very good chance of
>> producing something you later decide you should have done differently.
>> >
>> > I honestly don't know which would go down better (or less badly) -
>> "here's a mechanism we haven't really thought through in detail, but at
>> least we've defined one", or "we know the sort of thing we want, and we'll
>> describe it, but rather than produce something not quite right, we'll not
>> go further".
>> >
>> > --
>> > Christopher Dearlove
>> > Senior Principal Engineer
>> > BAE Systems Applied Intelligence Laboratories
>> >
>> __________________________________________________________________________
>> >
>> > T:  [phone]  |  E: [e-mail]
>> >
>> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>> Baddow, Chelmsford, Essex CM2 8HN.
>> > www.baesystems.com/ai
>> > BAE Systems Applied Intelligence Limited
>> > Registered in England & Wales No: 01337451
>> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>> >
>> >
>> > -----Original Message-----
>> > From: Lotte Steenbrink [mailto:[e-mail]]
>> > Sent: 22 April 2016 13:59
>> > To: Mobile Ad Hoc Networks mailing list
>> > Cc: Henning Rogge; Dearlove, Christopher (UK)
>> > Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >
>> > ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partner
>> or from the internet.
>> > Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> > Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> > --------------------------------------------------------
>> >
>> > Hello Christopher,
>> >
>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
>> [e-mail]>:
>> >>
>> >> Just be careful to note that this concept is as currently being
>> discussed (a) specific to AODVv2, and (b) not an application of 7182, which
>> has no knowledge of special TLVs.
>> >>
>> >> This is something we'd want to get right, and need to get right if in
>> any space not specific to ADODVv2, because getting it wrong produces future
>> problems.
>> >
>> > Makes sense.
>> >
>> >> I can see some possible approaches, none is ideal and we're rather out
>> >> of time to specify. But this is experimental, so I think we might be
>> >> able to indicate the shape of the solution without specifying it,
>> >> which would be a different RFC, under a bit less time pressure.
>> >> (Extensions to existing protocols like 7182 would naturally be in
>> >> scope rechartered I think.)
>> >>
>> >> To indicate the range that's open, here are two possible ideas, one of
>> which has an impact now, so needs to be agreed. Note that I'm not
>> suggesting (in fact quite the opposite) defining an extension to 7182 here,
>> rather enabling such an extension, if written, to "do the right thing".
>> >> - We have an extension to 7182 that says "zero out all value octets in
>> protocol specific TLVs. That requires now putting the AODVv2 metric TLV in
>> that space.
>> >
>> > Just to make sure that I understood you correctly– “that space” meaning
>> making the AODVv2 metric TLV protocol specific? (By “the aodvv2 metric tlv”
>> I’m referring to the generic TLV we’ve been talking about on this list
>> earlier this week).
>> >
>> >> - We have an extension to 7182 that adds extra material to the value
>> field that indicates (TBD how, by position with sanity check that this is
>> TLV value perhaps?) which octets are to be zeroed out before the ICV is
>> calculated.
>> >
>> > The way I understand that approach, it wouldn’t warrant any action from
>> AODVv2 besides saying “if you calculate the ICV, set the Metric value to
>> zero” (leaving the nitty gritty of how this would be done in detail to
>> future work)… Is that correct?
>> >
>> >>
>> >> We do not have the time to specify this in an acceptable manner within
>> two weeks though. But the security consideration section could say
>> something along the lines of "this enables the use of an ICV defined to
>> zero out these octets“.
>> >
>> > Okay. :)
>> >
>> > Best regards,
>> > Lotte
>> >
>> >>
>> >> --
>> >> Christopher Dearlove
>> >> Senior Principal Engineer
>> >> BAE Systems Applied Intelligence Laboratories
>> >> ______________________________________________________________________
>> >> ____
>> >>
>> >> T:  [phone]  |  E: [e-mail]
>> >>
>> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
>> Baddow, Chelmsford, Essex CM2 8HN.
>> >> www.baesystems.com/ai
>> >> BAE Systems Applied Intelligence Limited Registered in England & Wales
>> >> No: 01337451 Registered Office: Surrey Research Park, Guildford,
>> >> Surrey, GU2 7YP
>> >>
>> >> -----Original Message-----
>> >> From: manet [mailto:[e-mail]] On Behalf Of Lotte
>> >> Steenbrink
>> >> Sent: 22 April 2016 10:28
>> >> To: Henning Rogge
>> >> Cc: Mobile Ad Hoc Networks mailing list
>> >> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re:
>> >> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
>> >>
>> >> ----------------------! WARNING ! ---------------------- This message
>> originates from outside our organisation, either from an external partner
>> or from the internet.
>> >> Consider carefully whether you should click on any links, open any
>> attachments or reply.
>> >> Follow the 'Report Suspicious Emails' link on IT matters for
>> instructions on reporting suspicious email messages.
>> >> --------------------------------------------------------
>> >>
>> >> *** WARNING ***
>> >> EXTERNAL EMAIL -- This message originates from outside our
>> organization.
>> >>
>> >>
>> >> Hi Henning,
>> >>
>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <[e-mail]>:
>> >>>
>> >>> On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
>> >>> <[e-mail]> wrote:
>> >>>> Hi Thomas,
>> >>>> Can it?! Iirc, the reason why we adopted the “regeneration” language
>> >>>> in the first place is that we’ve been told that whenever one bit in
>> >>>> the message (apart from its header) is changed, the entire thing has
>> to be regenerated.
>> >>>> I’m starting to get the feeling we’ve just been misunderstanding
>> >>>> each other for more than a year. :( Anyway, it seems like we’re
>> >>>> getting close now, so yay.
>> >>>
>> >>> "Modifying" the binary message instead of parsing and generating a
>> >>> new one will be difficult as soon someone writes an extension to
>> >>> AODVv2 that adds more TLVs to the message.
>> >>
>> >> D’oh, right. Yeah, if I remember it correctly, that’s what you
>> explained to me when I got confused about the topic last spring… But– even
>> if a message contains TLVs that the AODVv2 implementation handling it
>> doesn’t understand, it will still be able to recognize the Metric TLV,
>> right? Isn’t that the nifty thing about RFC5444? So, while we really
>> shouldn’t write “before calculating the ICV, set the n-th 4 octets to 0”,
>> we might say “identify the octets that make up the metric value and set
>> those to 0”?
>> >>
>> >> Best regards,
>> >> Lotte
>> >>
>> >>> Henning Rogge
>> >>
>> >> _______________________________________________
>> >> manet mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/manet
>> >> ********************************************************************
>> >> This email and any attachments are confidential to the intended
>> >> recipient and may also be privileged. If you are not the intended
>> >> recipient please delete it from your system and notify the sender.
>> >> You should not copy it or use it for any purpose nor disclose or
>> >> distribute its contents to any other person.
>> >> ********************************************************************
>> >
>> > _______________________________________________
>> > manet mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/manet
>>
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>>
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>