Re: [manet] RFC 5444 translation tables

Hi,

there is one major and one minor problem with "no TLVs attached to address".

The minor problem is that it forces the AODV2 parser to be aware of
ALL possible TLVs. Normally each protocol does only need to care about
the TLVs it uses itself, but in this case you need to make sure there
is no other unknown TLV.

The major problem is that the "no TLV" mechanism blocks any extension
related to the address. What if we want a cryptographic signature
attached to RERR unreachable addresses in the future? Or some other
additional data? This would force a break of compatibility with the
current draft.

Because of these two reasons the protocol should always have a TLV
that gives an address a meaning, this way it can ignore any unknown
TLVs attached to the address AND ignore addresses which have no known
TLVs, which makes extensions much easier.

Henning Rogge

On Wed, May 27, 2015 at 11:23 AM, Victoria Mercieca
<vmercieca0@gmail.com> wrote:
> 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.  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
>>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>