Subject: [mobile-ip] [Fwd: Warning: could not send message for past 4 hours]

From: Rajeev Koodli <[email-masked]>
Date: Thu, 13 Sep 2001 15:53:02 -0700

Subject: Warning: could not send message for past 4 hours
From: Mail Delivery Subsystem <[email-masked]>
To: <[email-masked]>
Date: Thu, 13 Sep 2001 15:16:11 -0700 (PDT)

    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Thu, 13 Sep 2001 11:06:01 -0700 (PDT)
from patan.Central.Sun.COM [129.147.5.43]

   ----- The following addresses had transient non-fatal errors -----
<[email-masked]>

   ----- Transcript of session follows -----
<[email-masked]>... Deferred: Connection refused by sunroof.eng.sun.com.
Warning: message still undelivered after 4 hours
Will keep trying until message is 3 days old

Subject: Re: [mobile-ip] New BETH Draft
From: Rajeev Koodli <[email-masked]>
To: [email-masked]
Date: Thu, 13 Sep 2001 11:05:57 -0700

Hello James,

thanks for your comments. I guess was not clear enough in separating the concerns
regarding link-layer triggers. I suppose you can identify two kinds. First, in
response to an existing L2 event, one could generate a trigger internally to effect
a L3 action. For instance, an implementation may generate Proxy Router Solicitation
in response to scanning and detecting a new AP that the MN wishes to connect to.
This is internal to a host, such as a MN, and I guess this is what Pat was
referring to. Second, a new Layer 2 trigger (message ?) between two different
entities (such as a MN and an AR) could also be defined. But, this would perhaps
require standardization. This latter form of a trigger is perhaps needed to
indicate, e.g.,  that a MN has moved away from an AR. [In shared media, are there
link triggers available to indicate termination of link connectivity ?  Also, in
dedicated links, an AP may know that a MN has terminated link connectivity, but a
new trigger is still needed between the AP and the AR (in the general) case to
indicate to the AR of the MN's movement]

So, my concern is regarding those kinds that require standardization. Would it be
possible to clearly identify those triggers that are implementation-specific and
those that require standardization ? If BETH has only implementation-specific
triggers, that would be fine.  However, it has to be clearly identified and stated.
It must also identify what triggers need standardization of their own, if any.

Hope this is clearer.

Regards,

-Rajeev

James Kempf wrote:

> Hi Rajeev,
>
> Responses in line.
>
> >
> >
> >> As agreed upon in London, unless there are any further changes needed,
> >> I'd like to move forward with Gopal on incorporating the draft
> >> into the body of draft-ietf-mobileip-fast-mipv6-02.txt.
> >>
> >
> >I have some concerns with this. As I understand, please correct me if I am
> >wrong, BETH
> >relies on link-layer triggers to establish the bi-directional tunnel. The
> >link-layer triggers are
> >
> >- not standarized. Who will do the standardization ?
> >- not implemented (I guess since there is no standard). Any comments ?
> >
>
> As you know, there is a draft ongoing that is working toward defining
> abstract triggers.  These naturally need to be implemented for specific
> link layers, but the whole point of making them abstract is to
> remove the fast handoff specification from dependence on a specific
> link layer. Naturally, it is up to specific groups that control
> link layer specifications to work toward standardizing the triggers
> for their link layers. As Pat pointed out in his response, a system vendor
> may choose to implement the triggers as events on a particular platform
> instead, in which case, there would be no interoperability implications.
>
> >Given this dependence, having BETH as a part of FMIPv6 raises the following
> >issues
> >
> >- how can we implement FMIPv6 with BETH ?
> >- how can we test inter-operability ?
> >
> >So, I feel that FMIPv6 should contain enough specification that can become a
> >standard without depending on link-layer trigger standardization to succeed. We
> >are keen on moving FMIPv6 along, and would welcome new ideas that would improve
> >the protocol. However, items that would require standardization of their own
> >should perhaps be part of a separate document, and (still) be recognized in the
> >FMIPv6 specification.
> >
>
> As Hesham has pointed out, the current FMIPv6 spec has an implicit dependence
> on link layer triggers. How would an AR know to send a PrxyRtAdv or an
> MN to send a SolPrxyRtAdv without some kind of information from the
> link layer that a handover was pending? The BETH spec has made these
> dependencies explicit, and has used the abstract trigger formulation to
> make them independent of a particular link layer. In the low latency
> MIPv4 spec, this approach was taken from the beginning. From an engineering
> standpoint, IMHO making the need for triggers explicit and outlining
> how they might work seems more likely to result in successful implementations.
> It does not mean that every link layer must support all the triggers,
> nor that every link layer must support BETH. It is possible that some
> link layers won't have the proper kinds of triggers, in fact, some
> may not even be able to support the base FMIPv6 spec for that reason.
> If the need for triggers is called out in the spec, an implementor
> can make a quicker decision about whether or not their link layer
> and system platform supports the right ones, and, if not, work with
> the right standardization bodies and their system vendor to assure
> that the link layer triggers are available.
>
> So, I guess I don't see a real problem. There seemed to be strong
> concensus in London for including BETH in the base spec at this
> point, I think we should move forward with it.
>
>                 jak