Re: [manet] RFC 5444 translation tables

["Dearlove, Christopher (UK)" <[e-mail]>]

Actually, you save I think two bytes not having a target address. For significant loss of extensibility.

Two bytes?

Currently you can have a valueless TLV. It needs a single address index, no length or value.
Instead you can have a TLV with two values for the two address types. Using a multivalue TLV it needs no indices, a single byte length (2) and two value bytes.

Extensibility? You can add additional addresses with other meanings in future extensions. You can use the 254 unallocated (or 253, having an UNSPECIFIED value of 255 as in RFC 7188 is also a good idea) values for this in some cases.

It is also compatible with existing generic 5444 parsers approaches.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP


From: manet [mailto:[e-mail]] On Behalf Of Victoria Mercieca
Sent: 27 May 2015 10:24
To: Jiazi YI
Cc: manet
Subject: Re: [manet] RFC 5444 translation tables


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Jiazi, and thanks for your comments,

This is part of an ongoing discussion. The current draft implies that because there are two addresses in a RREQ, then if one is marked as OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other address must be TargAddr. i.e in a RREQ, we can interpret an address without an associated TLV as TargAddr. By doing it this way, we save the length of the TLV we might have associated with TargAddr. Further, this applied to other messages - the meaning of an unmarked address is deduced from the message type. For RREP, an address without an associated TLV is OrigAddr. For RERR, all unmarked addresses are unreachable destinations. In RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiate from the unreachable addresses.

If in future, we decided to add an new type of address into a message for some reason, that address MUST have a TLV associated with it to differentiate. That makes sense anyway, we would want to indicate what the new address means.

The question is, is this acceptable? If not, maybe we have to accept adding a TLV to each of these messages so that there are no addresses without associated any Address Block TLVs.

Also, the order of addresses in the Address Block doesn't matter in either case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section 8, page 46):
"The addresses in an Address Block may appear in any order, and values
   in an Address Block TLV must be associated with the correct address
   in the Address Block.  To indicate which address each value is
   associated with, the AODVv2 message representation uses lists where
   the order of the addresses in the AddressList matches the order of
   values in the other lists, e.g., SeqNumList in a RERR."
Is this unclear?

Kind regards,
Victoria.


On Tue, May 26, 2015 at 12:19 AM, Jiazi YI <[e-mail]<mailto:[e-mail]>> wrote:
If I understand well, we still need the existence and the order in the address block, to identify the usage of addresses?

For example, section 8.1:

8.1.3<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-8.1.3>.  Address Block





   A RREQ contains two Addresses, OrigAddr and TargAddr, and each

   address has an associated prefix length.



        +-------------------------+------------------------------+

        | Data Elements           | Address Block                |

        +-------------------------+------------------------------+

        | OrigAddr/OrigPrefixLen  | <address> + <prefix-length>  |

        | TargAddr/TargPrefixLen  | <address> + <prefix-length>  |

        +-------------------------+------------------------------+



We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only address block TLV for TargAddr (TargSeqNum) is optional. It means if we don't have the TargSeqNum TLV, according to RFC5444, we won't be able to know what's the TargAddr.



best



Jiazi





On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,
FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses all comments made in this thread. Any feedback is very welcome!

Regards,
Lotte

Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>>:

> I don't have time to look at this today, but Henning's suggestion looks good.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> __________________________________________________________________________
>
> T:  [phone]<tel:%2B44%20%280%291245%20242194>  |  E: [e-mail]<mailto:[e-mail]>
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai<http://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: Henning Rogge [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: 13 May 2015 15:11
> To: Lotte Steenbrink
> Cc: Dearlove, Christopher (UK); [e-mail]<mailto:[e-mail]>
> Subject: Re: [manet] RFC 5444 translation tables
>
> ----------------------! 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 Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <[e-mail]<mailto:[e-mail]>> wrote:
>> Hi Christopher,
>> thanks for your feedback.
>>
>> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
>> <[e-mail]<mailto:[e-mail]>>:
>>
>> There is a style question that all existing TLVs have names like
>> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don’t think
>> IANA enforce such issues, and different people will have different
>> opinions on the importance of consistent style. (Naming can matter,
>> we’re spending cycles on an ID just about TLV names.)
>>
>>
>>
>> Absolutely. In your opinion, would it suffice to adjust the current
>> names stylistically (see attached file), or do some names need extra
>> work in terms of clarification or consistency? (I was just wondering
>> if METRIC should be edited to make clear that it is not directly
>> related to LINK_METRIC...)
>
> Maybe the name "PATH_METRIC" would make sense for the new TLV... this describes the usage of the TLV very well.
>
> Henning Rogge
> ********************************************************************
> 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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet