Subject: [seamoby] Comments on: I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt

From: George Tsirtsis <[email-masked]>
Date: Mon, 16 Jul 2001 08:43:44 -0400

First of all to say again that this is useful work...sorry for the large
number of comments but I hope you will find them constructive.

1. In section 3.1 you explain what an L2 Trigger is. 
"  An L2 trigger is an abstraction of a notification from L2 
   (potentially including parameter information) that a certain event 
   has happened or is about to happen. "
I would continue to clarify with something like that:
"...The L2 Trigger is delivered to the IP layer so that IP protocols aware
of this trigger can act accordingly. The purpose of this specification is to
standardize a set of triggers with their meaning and parameters they carry.
How the triggers are created is outside the scope of this document and
should be defined on a per L2 Protocols bases."

2. Why is Section 4 in this draft? Why do we examine triggers for L2
Handoffs...I think this is out of scope? Section 5 describes use of triggers
with L3 Handoffs which is in scope and all we need...

3. In the table in Section 5 I have a different view on the concept of
"Recipient" of the various Triggers described. I think the "Recipient" is
the *IP Layer* in either the AR or the MN. Whether the trigger comes via an
AP or not is not relevant IMO. The consideration of the AP, however, is
sometime useful in the spec (e.g.: some times you need the AP's L2 addr if
one is used). Still the AP itself is never the recipient of the
trigger...i.e.: the AP does not act on trigger reception, apart from
forwarding it to the AR as normal.

4. I suggest the table in section 5 to be expanded and each Trigger to be
described in a bit more detailed...the sort, table descriptions, are a bit
nebulous...BTW, what is the purpose of "L2 Handover Start" Trigger??

5. Section 6.1.:
"  Although this timing requirement is 
   loosely defined, it is desirable to initiate reactive CT sometime 
   before (or about the same time as) the L2 handoff initiation. "
Please define "L2 Handoff" in the spec...it keeps confusing me...to my mind
we are only talking about L2 Handoffs here...so, what do you mean above?
similar things appear throughout the doc...

6. Section 6.2 defines CT related triggers, why are these different from the
ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can
(optionally?) include the information required for the triggers defined in
6.2. Also why do you have CT triggers going to the MN? and why both reactive
and proactive triggers go to both old and new ARs? 

7. Section 7:
"  While the primary purpose of L2 triggers described in this draft is 
   to aid L2 mobility optimization, L2 triggers can also benefit 
   networks without Mobile IP or other IP mobility protocol support. "
...to aid L2 mobility optimization???? you mean L3 mobility optimization? or
the term confuses me again?

Thanks and again good work!
George

---

From: James Kempf <[email-masked]>
Date: Mon, 16 Jul 2001 11:19:56 -0700 (PDT)

George,

Thanx for you comments. I'll fold them in on the next revision, which
will be after IETF 51. Specific responses below.

		jak

>should be defined on a per L2 Protocols bases."

OK.

>with L3 Handoffs which is in scope and all we need...

If the AR is not informed that the MN has changed APs, the AR's 
mapping of L2 address to IP address may be out of date when the MN moves.
The AR must either perform proxy ARP (IPv4) or Neighbor Discovery (IPv6)
in order to refresh the mapping.

With an L2 trigger and an associated update protocol, the AP could
specfically tell the AR what the new mapping is. If all the APs
have a single radio technology, then one can  reasonably argue
that this is radio technology specific (even if the protocol
to update the AR's mapping is based on IP); however, in the future,
it is possible that subnets with mixed technology APs may become
more common. So, while the draft does not advocate a particular
approach to solving this problem, it does lay out the requirements
for allowing it to be solved, should some working group  decide
they wanted to take on the task.

>forwarding it to the AR as normal.

I'm not entirely sure I understand your comment, but let me see.

Basically, the idea in the draft is that the AP is not a recipient
of the trigger, however, it may be the source. The recipient that
is identified in the draft is an IP entity (i.e. an IP host or
an IP router, the only entities that there are in IP networks).
APs are neither, since they are transparent by definition. 

So I think we are agreeing on that point.

The AP *may* have an IP address if it is engaged in, say, IAPP like
traffic to propogate L2 trigger information. At that point, it
is acting like an IP host.

I agree that, on a particular IP entity identified as a target,
the IP stack is the recepient of the trigger. 

Does this correspond to what you are saying?

>nebulous...

OK, I'll look into it. If you have any proposed wording, please send it
along.

>BTW, what is the purpose of "L2 Handover Start" Trigger??
>

See draft-kempf-beth-ipv6-01.txt. It is used to optimize handover
smoothing.

>similar things appear throughout the doc...

OK.

>and proactive triggers go to both old and new ARs? 

We had some discussion on this among the authors. It is true that
there is overlap, we wanted to lay out the requirements separately.
The reason is that there is a strong feeling among the CT design
team participants that CT should not be tied to a mobility protocol.
While I think it is probably worthwhile to lay out the requirements
separately, perhaps something should be said about overlap, and
maybe put a section in that describes how to satisfy them with
a single set of triggers. Does this sound like a good idea?

>the term confuses me again?

OK, we probably need to sharpen up the definitions, maybe add one
for L3 mobility.

The idea in this section was some L2 triggers (like those in Section 4,
for example) could be used in nonmobile networks or networks with
the nomadic model.
>Thanks and again good work!

Thank you for the comments! If you have any text you'd like to see in the 
document (particularly on the table in Section 5) please send it along.

		jak