Hello Joe,

We aren't claiming that the effects described in the draft are new.
But they are relevant to IP.  Moreover, as other people have said, this
internet draft was motivated in response to recurring problems that
were noticed in other working groups.

After reviewing PILC, I find that there is not much overlap with our
draft.  Much of PILC could be understood as proposing techniques
suggested for improvement of upper layers, not explaining the
problems at the lower layers.  If people understand the kinds of
problems that may be encountered over wireless links, they are less
likely to make the mistakes that have caused problems up until now.
That's not to say anything negative about PILC -- it's a tremendous
document that was very rewarding to read again.  The lack of
broadcast capability described in PILC could be seen as the main
area of overlap with our document.

The word "subnet" does not appear in our document, and that is
intentional.  We were motivated to identify effects that really do
matter for multihop communications.  Yes, these effects are due to
the characteristics of wireless media below IP, and IP does not need
to change in order to operate properly.  But these effects do have an
impact on IP routing, and that was the main motivation for us to
develop the document.  I think the effects are far more subtle and
worthy of careful explanation compared to simply unplugging an
Ethernet.

In fact, we do not propose any techniques for dealing with the
problems.  Our intended scope is far, far narrower than the broad
scope of PILC.

Regards,
Charlie P.





On 1/19/2015 1:45 PM, Joe Touch wrote:
+1

A link layer that cannot reach all its members isn't a link layer - it's multiple link layers that need interconnection. That's what routers are for.

Full multihop reachability is common in link layers that are complete.

Again, it'd be useful to show something the RFCs haven't already described. Otherwise this would be better served by a collection of existing approaches.

Joe


On Jan 19, 2015, at 1:00 PM, Templin, Fred L <[email protected] <mailto:[email protected]>> wrote:

As I understand it, your draft is trying to establish the notion of a multi-hop link but

that is not architecturally correct – I think that was the point of the PILC comment.

Instead of a multi-hop “link”, what you have is a multi-hop “subnetwork” with

link segments joined together by subnetwork routing protocols. To establish

a link in the normal sense, configure an NBMA tunnel virtual overlay over the

subnetwork. IPv6 ND and DHCPv6 then work as-expected.

Thanks – Fred

[email protected] <mailto:[email protected]>

*From:*[email protected] <mailto:[email protected]> [mailto:[email protected]] *On Behalf Of *Emmanuel Baccelli
*Sent:* Monday, January 19, 2015 12:36 PM
*To:* Joe Touch
*Cc:* Templin, Fred L; Brian E Carpenter; Alexandru Petrescu; [email protected] <mailto:[email protected]> *Subject:* Re: [Int-area] About draft-baccelli-manet-multihop-communication-04

Hi Joe,

PILC is a great ref that should be cited indeed. Another relevant ref is RFC 5889. One of the recommendations that RFC boils down to: *do not* use on-link prefixes *at all* on interfaces to multi-hop wireless networks -- the subject of the draft we discuss now.

The reason is: there is no planned structure at link-layer and you cannot guarantee anything in terms of connectivity over such wireless interfaces -- which does not however mean that these interfaces are useless!

In short: this is not yet another simple case of NBMA. Ergo the need for this draft.

Best,

Emmanuel

On Fri, Jan 16, 2015 at 9:58 PM, Joe Touch <[email protected] <mailto:[email protected]>> wrote:

    FYI, there's an RFC explaining all this already: 3819

    Joe


    On 1/16/2015 12:04 PM, Templin, Fred L wrote:
    > +1
    >
    >> -----Original Message-----
    >> From: Int-area [mailto:[email protected]
    <mailto:[email protected]>] On Behalf Of Brian E Carpenter
    >> Sent: Friday, January 16, 2015 11:16 AM
    >> To: Alexandru Petrescu; [email protected]
    <mailto:[email protected]>
    >> Subject: Re: [Int-area] About
    draft-baccelli-manet-multihop-communication-04
    >>
    >> Alex,
    >>
    >>> but to improve the layers below IP such as to have IP run
    unmodified.
    >>
    >> In the general case that is impossible, because the SDO that
    develops
    >> the lower layer isn't interested. If the lower layer is
    intrinsically
    >> NBMA then for sure ARP or ND+DAD will not work as designed. If
    the lower
    >> layer doesn't support a physical MTU of at least 1280 IPv6
    will not work
    >> as designed. So in the general case both an adaptation layer
    and an
    >> NBMA solution are required. And as you know, there are other
    "Ethernet"
    >> assumptions that don't apply in a low-power wireless scenario.
    >>
    >> Of course the goal is "IP over Everything" but that isn't the
    same as
    >> "Everything must be like Ethernet", which you seem to imply.
    >>
    >> In fact when you read draft-baccelli-manet-multihop-communication
    >> (and imagine what its security section will say when it's been
    >> written), I think the conclusion is that a great many things have
    >> to change, not in the IP packet format, but in the ecosystem
    >> currently provided by ARP/DHCP or RA/ND/DAD/SLAAC/DHCPv6.
    >>
    >>   Brian
    >>
    >> _______________________________________________
    >> Int-area mailing list
    >> [email protected] <mailto:[email protected]>
    >> https://www.ietf.org/mailman/listinfo/int-area
    >
    > _______________________________________________
    > Int-area mailing list
    > [email protected] <mailto:[email protected]>
    > https://www.ietf.org/mailman/listinfo/int-area
    >

    _______________________________________________
    Int-area mailing list
    [email protected] <mailto:[email protected]>
    https://www.ietf.org/mailman/listinfo/int-area



_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to