Subject: RE: [seamoby] Re: [mobile-ip] Comments on: I-D ACTION:draft-many folks-l2-mobilereq-00.txt

From: George Tsirtsis <[email-masked]>
Date: Tue, 17 Jul 2001 05:34:26 -0400

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, July 16, 2001 7:20 PM
To: [email-masked]; [email-masked]
Subject: [seamoby] Re: [mobile-ip] Comments on: I-D
ACTION:draft-manyfolks-l2-mobilereq-00.txt

George,

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

...
>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...
>

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.

GT> OK, I see...It would be nice to state that somewhere though....i.e.: the
AP to AR protocol for this update is likely to be proprietary to the AP's
technology...and yes I know that some APs (as well as wavelan hubs) also
speak IP in which case this could be an IP protocol...oh well...the world is
not simple anymore :-)

>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.
>

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.

GT> We do indeed, I just said that because in Table 2 you have AP/AR as
Recipient of Link UP/DOWN triggers

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?

GT> Hmmm...you see that is what I do not like about this...I would much
better prefer not to refer to APs in this way...The L2 triggers always go to
an IP router or a host as you said...if one wants to implement an IP host in
an AP then as far as this mechanism goes this is an IP host (not an AP!).
The reason I am fussy about this is that any IETF mechanism/protocol should
be designed for the clear architectural case so it is correct...then it can
be implemented in whatever way fits the specific scenario. The other way
never works quit so well...So, lets just define the API and let people
implement it the way they need...you can even give the AP case as an
example...

>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...

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

GT> OK, will think about it and we can discuss in London.

>
>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? 
>

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?

GT> I fully agree that CT should not be tight to one single mobility
protocol but I also think the API described in this spec should not be
either...these are *generic* triggers "I am coming from there"...or "I am
going there"...some of them not even mobility specific i.e.: "link up",
"link down"....These have nothing to do with any particular mobility
protocol and some of them can be used by non mobility protocols...So, I
think we should start the opposite way...assume they are the same triggers
until you find a strong reason why CT needs its own specific triggers.
Otherwise protocol X will also come later on and demand its own specific
triggers => no good....

...
>
>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.

GT> OK, we can discuss in London...

Thanks
George

P.S.: BTW, I am a bit confused with the seamoby list...you use the
[email-masked] address...but when I go to though this is
[email-masked]...is this an alias of the same list?

---

From: James Kempf <[email-masked]>
Date: Fri, 20 Jul 2001 09:02:15 -0700 (PDT)

George,

>implement it the way they need...you can even give the AP case as an

I agree that the trigger ends up on the IP stack of the AR. The AP is
the generating agent for the trigger, not the recipient. The table
is confusing, I'll change it.

>Otherwise protocol X will also come later on and demand its own specific

Actually, the spec is not describing an API, it is describing requirements.
There is a separate spec in preparation for the API. As such, the
requirements in Section 6.2 reflect those that come out of the CT discussion.
The requirements are formulated as descriptions of abstract triggers.
I agree that an API should consolodate the trigger descriptions so
that only a single set appears, but they reflect the requirements
from all the areas.

One area that wasn't discussed in the paper is header compression. 
There may also be requirements for header compression, I hope perhaps
to have an opportunity to speak with the ROHC folks in London on it.

>[email-masked]...is this an alias of the same list?

It's the same alias.

		jak