Subject: [manet] Comments on rfc5444-usage

From: Jiazi YI <[email-masked]>
Date: Tue, 19 Apr 2016 15:05:26 +0200

Hi,

I just had a review on the rfc5444-usage draft (-03).

I think the draft is in good shape and easy to understand (I need to note
here that I haven been working with RFC5444 in the past a few years, so I
don't have a pair of fresh eyes on it).

section 4.2,

bullet 1:

 Messages MAY also be forwarded by their owning protocol.
>       It is strongly RECOMMENDED that messages are not modified in the
>       latter case.

I have mentioned this in another thread, regarding the reactive protocol. I
think it's OK to put a RECOMMEND/SHOULD here (probably not "strongly"?),
but it would be great if we can put a few words explaining the tradeoffs.

bullet 5:

> If requested by a protocol, the multiplexer SHOULD, and otherwise
>       MAY, include a Packet Sequence Number in the packet.

Although it's a MAY/SHOULD here, I think we need to be clear that the
existence of packet sequence number must be consistent, i.e., the
multiplexer must not add #seq in this transmission, and omit the #seq in
the next transmission (because of MTU limitation, etc.).

still section 4.2:

The demultiplexer MUST remove any TLVs added to the message by the
>       multiplexer.  The message MUST be passed on to the protocol
>       exactly as received from (another instance of) the protocol.

How a demultiplexer know if a TLV is added by another multiplexer,
especially we have different implementations? Is there any flag or signals
that we can count on?

section 4.5:

   A message (excluding the Message Header) can thus be represented by
>    two, possibly multivalued, maps:
>    o  Message: (extended type) -> (length, value)
>    o  Address: (address, extended type) -> (length, value)

Why only extended type here (which is optional)? What about the tlv-type?

And one more question:
Is it possible to build relationship between two addresses in the address
block? For example, we have
    - address-A, address-B, address-C with tlv-type-X,
    - address-D, address-E, address-F with tlv-type-Y.

Can we set up a relation saying that address-A is related to address-D,
address-E? For example, the gateway A supports source address with prefix
D, E?
We can do so by encoding the addresses as data in TLVs, but it seems that
it's not recommended.

regards

Jiazi

---

From: Henning Rogge <[email-masked]>
Date: Tue, 19 Apr 2016 17:05:57 +0200

On Tue, Apr 19, 2016 at 3:05 PM, Jiazi YI <[email-masked]> wrote:
> think it's OK to put a RECOMMEND/SHOULD here (probably not "strongly"?), but
> it would be great if we can put a few words explaining the tradeoffs.

I think this paragraph has been written in terms of "protocol
independent forwarding of messages", based on the message header.

What AODVv2 is doing is to generate a new message mostly based on the
old message.

> multiplexer must not add #seq in this transmission, and omit the #seq in the
> next transmission (because of MTU limitation, etc.).

the multiplexer is the only one that can verify the MTU limitations
anyways, especially if a message is forwarded.

Because of this a protocol should not make messages too large, they
must fit into the smallest MTU in the whole Mesh (including packet
level overhead).

> especially we have different implementations? Is there any flag or signals

it cannot know.

> Why only extended type here (which is optional)? What about the tlv-type?

This is the TLV type we are talking about

a message contains a mapping from (extended TLV type) to (TLV length, TLV value)

>     - address-D, address-E, address-F with tlv-type-Y.

there is no syntactic way to do this... you can only do this on
semantic level by defining a TLV that announce "pairs/groups" of
addresses with its value. And its not nice to parse.

> address-E? For example, the gateway A supports source address with prefix D,
> E?

That is exactly what I am doing in my source-IP based routing
extension for OLSRv2.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 Apr 2016 09:14:17 +0000

Excellent point about consistency of packet sequence numbers. I think that after the MAY add, we should have an if added MUST clause.

With regard to the how to know if add by multiplexer. I think that would mainly be by extension - is this an extension to the multiplexer (then the multiplexer should remove). There’s a slight issue over 7182, but there it’s really an implementation issue. And this is really for the benefit of 7182. Will think about wording.

Extended type has been discussed in another couple of emails. This means extended type, not type extension, but actually 5444 almost but not quite calls this a full type. (It’s defined by a symbolic name, not that phrase.) So we should switch to full type and add a  comment to terminology. And maybe check if we’ve used extended type elsewhere (I mean other RFCs). If so comment sometimes referred to as extended type, if not, not.

To relate say three addresses symmetrically, we could create an association TLV, various designs being possible. For example TLV type (or full type) indicates association meaning, if necessary TLV value is the group number. We considered this in NHDP where we report addresses of neighbours, but discard the (available) information about which of those addresses belong to which neighbour. But we decided not to add it as no one had a need for it. With of course the option to add if that changed (hasn’t done so as far as I know).

If you want an asymmetric relationship, that’s messier. Though anything could be done if you try hard enough. I think if someone has a case, let’s lay out the properties needed and brainstorm best way to represent. That might turn out to be address in value, which isn’t easily compressible (there are constraints on design). And if the addresses are different sizes (e.g. IP and MAC - though there needs to be a good case for that - or IPv4 and IPv6) then there isn’t an alternative (that I can see).

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

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

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:[email-masked]] On Behalf Of Jiazi YI
Sent: 19 April 2016 14:05
To: manet
Subject: [manet] Comments on rfc5444-usage

*** 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>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hi,

I think the draft is in good shape and easy to understand (I need to note here that I haven been working with RFC5444 in the past a few years, so I don't have a pair of fresh eyes on it).

section 4.2,

bullet 1:

I have mentioned this in another thread, regarding the reactive protocol. I think it's OK to put a RECOMMEND/SHOULD here (probably not "strongly"?), but it would be great if we can put a few words explaining the tradeoffs.

bullet 5:

Although it's a MAY/SHOULD here, I think we need to be clear that the existence of packet sequence number must be consistent, i.e., the multiplexer must not add #seq in this transmission, and omit the #seq in the next transmission (because of MTU limitation, etc.).

still section 4.2:

How a demultiplexer know if a TLV is added by another multiplexer, especially we have different implementations? Is there any flag or signals that we can count on?

section 4.5:

And one more question:
Is it possible to build relationship between two addresses in the address block? For example, we have
    - address-A, address-B, address-C with tlv-type-X,
    - address-D, address-E, address-F with tlv-type-Y.

Can we set up a relation saying that address-A is related to address-D, address-E? For example, the gateway A supports source address with prefix D, E?
We can do so by encoding the addresses as data in TLVs, but it seems that it's not recommended.

regards

Jiazi

********************************************************************
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.
********************************************************************