Hi Chris,

Thanks for your comments also.

On Wed, May 27, 2015 at 12:00 PM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

>  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.
>
>
Like an "address meaning" TLV? And using just one of these TLVs in each
message, mark each address in the address block? I've just found Section C2
in RFC5444 -

Assume the definition of an Address Block TLV with type EXAMPLE1 (and
   no type extension) that has single octet values per address.  There
   are a number of ways in which values a, a, b, and c may be associated
   with the four addresses in the preceding Address Block, where c is a
   default value that can be omitted.

   Examples:

   Using one multivalue TLV to cover all of the addresses:
      *  <tlv-flags> has thasvalue and tismultivalue set (value 20);
      *  <index-start> and <index-stop> are omitted;
      *  <length> = 4 (single-length = 1).
      *  The TLV is then EXAMPLE1 20 4 a a b c (7 octets).


So we would define values a b c d, where "a" represents OrigAddr, "b"
represents TargAddr, "c" represents an unreachable address in RERR,
and "d" represents a PktSource address?


Then separately add TLVs relating to metrics, sequence numbers, etc.?
...and we wouldnt need three kinds of SEQ_NUM TLV for this, we could
just use SEQ_NUM, and have multi-values if necessary.


Did I understand that correctly?


Kind regards,

Victoria.



>
> 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*:  +44 (0)1245 242194  |  *E: *chris.dearlove@baesystems.com
>
> 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
>
>
>
>
>
> *From:* manet [mailto:manet-bounces@ietf.org] *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 <ietf@jiaziyi.com> 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 <
> lotte.steenbrink@fu-berlin.de> 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) <
> chris.dearlove@baesystems.com>:
>
> > 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:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com
> >
> > 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: Henning Rogge [mailto:hrogge@gmail.com]
> > Sent: 13 May 2015 15:11
> > To: Lotte Steenbrink
> > Cc: Dearlove, Christopher (UK); manet@ietf.org
> > 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 <
> lotte.steenbrink@fu-berlin.de> wrote:
> >> Hi Christopher,
> >> thanks for your feedback.
> >>
> >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
> >> <chris.dearlove@baesystems.com>:
> >>
> >> 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
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>