Subject: [RTG-DIR] RtgDir review: draft-ietf-manet-nhdp-11.txt

From: Stig Venaas <[email-masked]>
Date: Mon, 08 Mar 2010 14:30:36 -0800

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-manet-nhdp-11.txt
Reviewer: Stig Venaas
Review Date: March 8, 2010
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:

The document is well written and I see no major issues with the
specification. Although the first minor issue may be important,
but I may be missing something. There are also some minor concerns
like message size and interoperability.

Minor Issues:

In S4.1:
    Each MANET interface:

    o  Is configured with one or more network addresses.  All addresses
       represented by these network addresses MUST be unique to this
       router at least within its 2-hop neighborhood.  All such addresses
       MUST be unique to this MANET interface, except that an address can
       be used by more than one MANET interface on the same router if
       those MANET interfaces are "isolated" from each other (no MANET
       interface on another router can hear or be heard by two MANET
       interfaces using overlapping network addresses).

This definition seems less strict than what is in last paragraph of 6
(right before 6.1). That says also "one to and one from".

I'm wondering if this definition is strict enough. Do you want to allow
a topology like the below where there are two links connecting neighbors
A and B where A uses the same address "a" on both links?

     a --
    A     B -- C
     a --

Wouldn't then B send messages to C containing "a" twice? Would that be
correctly processed by C? Wouldn't C basically treat them as the same
announcement twice. And if say one of them is removed, remove both until
the next update?

In S5.1:
    This protocol specifies HELLO messages, which are included in packets
    as defined by [RFC5444].  These packets may be sent either using the
    "manet" protocol number or the "manet" well-known UDP port number, as
    specified in [RFC5498].

Should implementations listen for both? Should it be configurable which
one to listen too? Are there possible interoperability issues?

In S9.3
    2.  Any Neighbor Tuples whose N_neighbor_addr_list contains the added
        network address, are removed.

Is it OK if it contains an overlapping address? That is if some Tuple
has a N_neighbor_addr_list with an element that overlaps this address,
or vice versa.

In S11.1:

    If any such network addresses have been added to these Information
    Bases since the last HELLO message was sent on this MANET interface,
    or if their status (as indicated by these TLVs and the Values they
    associate with that network address) have changed since that network
    address was last reported on this MANET interface, then that network
    address, and the indicated TLVs, MUST be included in the HELLO
    message.

May not this be too much to fit in a single message?

The document should perhaps discuss whether messages should be within
the link MTU? Or is fragmentation OK? Is it better to send a large Hello
(which may be fragmented) to get new information out fast than to split
the info in different Hellos? In general when the info is not changed,
then I assume it should be split. But if a router has many local
addresses to include, then more bandwidth is used with multiple hello's
compared to a single large fragmented one. At least I think some
considerations/discussion would be good.

Nits:

Definition of Network Address in Section 2:

    Network Address  An address plus an associated prefix length.  This
                  ^^^
missing -

The definition of Heard in Section 2 is:
    Heard  - A MANET interface of router X is considered heard on a MANET
       interface of a router Y if the latter can receive traffic from the
       former.

I'm not sure what "traffic" is here. As in receiving Hello messages?
Maybe there is a more precise term?

Definition in Section 2: c = d  is a comparison operator

Might it be better for unordered lists to define it as "c contains d and
d contains c"? And for addresses as, "c overlaps d and d overlaps c"?

End of S4.2:
    received in a HELLO message is considered valid.  Appendix F
    illustrates some example two hop topologies and how they correspond
Two-hop?                    ^^^^^^^
    to information in the Information Bases.

In S4.3.2
       corresponding Link Set and the Neighbor Information Base.  Note
       that when determining whether to include information in a HELLO
       message, the sender MUST consider all times up to the latest time
       when it may send its next HELLO message on this MANET interface.

What does this mean? Can it be formulated more clearly? I can guess, but
it's at best unclear.

In S7.1:
    L_HEARD_time  is the time until which the MANET interface of the
       1-hop neighbor would be considered heard if not considering link
       quality;

I guess this means it is heard until L_HEARD_time expires, but I think
it may be read as "time until it would become heard". That after waiting
L_HEARD_time, it will be considered heard. Maybe this could be
formulated in a less confusing way? Say "time for which" would for me be
much clearer than "time until which". I'm not a native English speaker
though, but it will be read by many other non-native speakers as well.

This may apply to other places where it says "time until which" too.

In S9:
   the the Interface Information Base and the Neighbor Information Base.
^^^^^^

In S12.1:
    o  The address length as specified in the Message Header is not equal
       to the length of the addresses used by this router.

Shouldn't this be worded differently for a router supporting both IPv4
and IPv6, that is, the router uses addresses of multiple lengths.

Stig

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 23 Mar 2010 22:50:34 +0100

Dear Stig,

Thank you for your review. We have updated the document to accommodate  
your remarks, and expect to submit this shortly.

Please see below for detailed comments to your review.

On Mar 8, 2010, at 23:30 PM, Stig Venaas wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this  
> draft. The Routing Directorate seeks to review all routing or  
> routing-related drafts as they pass through IETF last call and IESG  
> review. The purpose of the review is to provide assistance to the  
> Routing ADs. For more information about the Routing Directorate,  
> please see http://www.ietf.org/iesg/directorate/routing.html
>
> Although these comments are primarily for the use of the Routing  
> ADs, it would be helpful if you could consider them along with any  
> other IETF Last Call comments that you receive, and strive to  
> resolve them through discussion or by updating the draft.
>

Done - we have tightened 4.1 to be in line with section 6, both in  
content and in style.

> A and B where A uses the same address "a" on both links?

The answer to the above is "it depends": if B has a single interface,  
then this configuration is prohibited by the text above (section 6 and  
section 4.1). If B has two different interfaces, each of which "sees  
only one of a, but not both", then it is an allowed configuration  
because "it works" (there would be, for an interface of b, be no  
ambiguity of which "a" was heard).

> announcement twice.

No. Section 11.1, numbered bullet point 2 precludes this by the  
"...and which has not already been included..." test-clause for  
inclusion. B would send it once, and C would process them correctly.

> And if say one of them is removed, remove both until
> the next update?

If B has two interfaces (the allowable configuration above), and one  
of the "a" is removed from A, then the link set for the corresponding  
interface of B would reflect this. The neighbor set of B would still  
record "a" as a neighbor (which it would be via the other interface of  
B).

In other words, the protocol would handle this situation correctly.

> one to listen too? Are there possible interoperability issues?

NHDP will operate correctly over either. RFC5498 leaves the option of  
which to chose (either or both) open. It is the authors opinion that a  
deployment would chose to run either over an UDP port number or over a  
protocol number (but not both concurrently, although nothing in this  
protocol specification would preclude correct operation also in this  
case).

A slightly more complete answer is, that there were some members in  
the WG expressing a preference for using an UDP port, and some other  
members preferring using protocol numbers, for when running [MANET]  
protocols -- and RFC5498 was published without arbitrating this issue.

As this protocol runs as an instance of RFC5444, this is furthermore  
not an issue that NHDP can address in isolation.

> has a N_neighbor_addr_list with an element that overlaps this address,

Done. Very good catch, thanks! Section 9.3 had some lingering wording  
surviving from before the "contains" and "overlapping" terminology was  
introduced -- we have adapted 9.3 to clean this up.

> considerations/discussion would be good.

Done. We have (i) changed the MUST to SHOULD and (ii) added an  
explanatory paragraph addressing the issue you mention above.

>   Network Address  An address plus an associated prefix length.  This

Done.

> Maybe there is a more precise term?

Done. Good point - we addressed it by replacing "traffic" by "control  
messages, according to this specification," in order to avoid forward- 
references, as at this point in the specification "HELLO messages"  
have not yet been introduced or defined.

> d contains c"? And for addresses as, "c overlaps d and d overlaps c"?

For unordered lists, agreed -- and done.

For addresses, the "overlaps" operator is symmetric, i.e., if "c  
overlaps d" then it is always true that "d overlaps c" -- and so this  
cannot be used for defining equality. We have therefore retained the  
original text on this point.

>   to information in the Information Bases.

Done. Removed "two hop" and retained "... some example topologies and  
how they correspond ...."

However, as a follow-on from this issue, we have rendered consistent  
"2-hop" and "1-hop" usage (there were a couple of lingering "two hop"  
and "one hop" mentions left).

> What does this mean? Can it be formulated more clearly? I can guess,  

Duly noted -- tt's difficult to be both concise and clear at the same  
time on this. We have tried to rewrite that paragraph -- hoping that  
it is clearer (albeit a bit more verbose) in the new version

> This may apply to other places where it says "time until which" too.

We cannot say "the time for which" as that would imply an interval,  
whereas "the time until which" refers to an exact instance (moment) of  
time in the future.

The best alternative we have been able to come up with is "the time up  
to which" - in your opinion, is that clearer?

>  the the Interface Information Base and the Neighbor Information Base.

Done (outch).

> and IPv6, that is, the router uses addresses of multiple lengths.

We have discussed this in great detail. The bottom line is, that mixed- 
mode operation is a complicated beast -- notably, how would an IPv4- 
aware router deal with receiving a HELLO message containing IPv6  
addresses (and how would an IPv4 router send HELLO messages containing  
both IPv4 and IPv6 addresses, not knowing how to map v4 to v6). The  
"obvious way of doing it" might just work fine by "not breaking NHDP"  
-- but cause fundamentally useless information to be propagated among  
the NHDP routers (and, possibly, used by whatever other protocols  
interacting with NHDP).

We prefer to keep the restriction as is stated above: pick an address  
family (we recommend v6 :-)  ), and stick with it. Should a need for  
mixed-mode operation arise, a protocol extension to NHDP can be  
developed, lifting that restriction (and likely engaging in also how  
to do proper v6-v4 NAT etc).

We believe that having a restriction in place causing routers *not*  
implementing such an extension to reject participating in a mixed- 
family network to be the safer approach.

Mange takk for din hjelp, Stig,

Thomas

---

From: Stig Venaas <[email-masked]>
Date: Tue, 30 Mar 2010 10:04:59 -0700

Hi

> Please see below for detailed comments to your review.

OK, please see my comments below then.

>> Although these comments are primarily for the use of the Routing ADs, 
>> it would be helpful if you could consider them along with any other 
>> IETF Last Call comments that you receive, and strive to resolve them 
>> through discussion or by updating the draft.
>>

Good

> No. Section 11.1, numbered bullet point 2 precludes this by the "...and 
> which has not already been included..." test-clause for inclusion. B 
> would send it once, and C would process them correctly.

Ah, of course!

> If B has two interfaces (the allowable configuration above), and one of 
> the "a" is removed from A, then the link set for the corresponding 
> record "a" as a neighbor (which it would be via the other interface of B).
> 

Thanks, got it.

> protocol specification would preclude correct operation also in this case).
> 
> A slightly more complete answer is, that there were some members in the 
> WG expressing a preference for using an UDP port, and some other members 
> preferring using protocol numbers, for when running [MANET] protocols -- 
> and RFC5498 was published without arbitrating this issue.
> 
> As this protocol runs as an instance of RFC5444, this is furthermore not 
> an issue that NHDP can address in isolation.

OK

> introduced -- we have adapted 9.3 to clean this up.

Looks good now.

> explanatory paragraph addressing the issue you mention above.

New text looks reasonable.

> messages, according to this specification," in order to avoid 
> forward-references, as at this point in the specification "HELLO 
> messages" have not yet been introduced or defined.

Good.

> original text on this point.

You are right of course :)

> time on this. We have tried to rewrite that paragraph -- hoping that it 
> is clearer (albeit a bit more verbose) in the new version

Yes, it became rather verbose, but should be clear now.

> to which" - in your opinion, is that clearer?

Yes, that is clearer, and also much better than my suggestion.

> We have discussed this in great detail. The bottom line is, that 
> mixed-mode operation is a complicated beast -- notably, how would an 
> IPv4-aware router deal with receiving a HELLO message containing IPv6 
> "obvious way of doing it" might just work fine by "not breaking NHDP" -- 
> but cause fundamentally useless information to be propagated among the 
> NHDP routers (and, possibly, used by whatever other protocols 
> interacting with NHDP).
> 
> developed, lifting that restriction (and likely engaging in also how to 
> do proper v6-v4 NAT etc).
> 
> implementing such an extension to reject participating in a mixed-family 
> network to be the safer approach.

OK

> Mange takk for din hjelp, Stig,

:)

Rev 12 looks good to me then,

Stig