Re: RE: AD request / L2 Triggers Chapter Statement

> Personally, I think it's a terrible mistake for these devices to use
> an IP-based protocol for this purpose.  802 is (currently) agnostic
> with respect to network layer protocols, and I think this is a very
> good property.  In particular, 802 defines a family of Spanning Tree
> messages used to eliminate loops in an 802 network.  These are,
> naturally enough, not based on IP.  I see no reason that this related
> feature should be a special thing that only IP can use.
>
> What happens if I'm running OSI over my 802 network?  Such a thing is
> not completely unheard of.
>
> What happens if I *don't* want to give my bridges separate IP
> addresses?  What are the security implications?  What security
> protocols are defined for this exchange?
>

Agreed, particularly with the security issue. Some of their proposals
for security would be massively suboptimal for Mobile IP handover.

> Yes.  However, it's a general 802 problem.  The fact that it bothers
> some people in particular for this one application doesn't mean that a
> special solution for this one case is warranted.
>

The problem with this particular application is that there is some
desire on the part of hardware vendors and service providers for a
standard so that the handover time can be reduced for VoIP and other
realtime media. As is usual in standards work, there is a need for an
interoperable standard to facilitate products. Most of this need is
being expressed in the 802.11 committee, but the technical clue about
what works for MIP resides in IETF, IMHO.

> Really?  In that case, something is horribly broken.  There's nothing
> at all in PPP that gives you such an absurd link establishment delay.
> If it takes you more than 4 or 5 round-trip-times to establish a PPP
> link (typically an order of milliseconds for most *usable* link
> technologies, not seconds), then you have some serious implementation
> bugs to worry about first.
>

It doesn't all have to do with PPP (though there is an issue of
transferring PPP state on handover that is common with other wireless
protocols that use PPP, like 3GPP2). For VoIP applicaitons, L2 and L3
handover must complete within 40 milliseconds.

> Requirements documents are never standards-track.

Agreed.

> If this is done, *please* address the general problem: notification of
> remote L2 failure in 802-based protocols.  Solving the problem for one
> particular case is (in my opinion) a very bad thing to do.
>

Possible, but there are very specific requirements on wireless handover
involving information that must be made available. These might not apply
in the general case. But this is an issue for IEEE and not IETF, as you
mention later.


> Fortunately, that message already exists, at least for IP: see RFC
> 1868.
>
> It's not ICMP, though.  Is that a necessary feature?
>

RFC 1868 won't work for handover. The new access point must also provide
the MAC address (for 802.11) of the old access point.

In addition, there's also a need for this kind of signaling in IPv6,
hence the interest in ICMP. An extension to ARP might be acceptable for
IPv4, however. This could be a topic of discussion for the BOF/WG.

> Some appear to me to be so, but that's quite beside the point.
>
> The point is whether or not these things actually belong in the IETF.
> I don't think that the IETF owns the IEEE protocols, nor that the IETF
> should set out to modify the IEEE protocols.  IETF participants who
> have particular 802-related hobbyhorses certainly ought to be involved
> in the IEEE to get those protocols changed to taste.
>

I quite agree that the IEEE (or 3GPP for that matter) work should be
done in IEEE (or 3GPP). The issue seems to me whether:

a) The IETF is the right place for a non-standards track requirements
document embodying IETF concensus on what is needed for fast Mobile IP
handover from Layer 2 for future designers of wireless link protocols,

b) Whether there is need for some form of standard IP protocol (ICMP,
ARP extension, other?) to provide a non-L2 specific way of providing
this information.

            jak




_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/