Subject: [netlmm] Questions regarding new NetLMM protocol draft

From: "Grace, Kevin H." <[email-masked]>
Date: Thu, 22 Jun 2006 17:41:35 -0400

In the spirit of trying to help clarify the NetLMM protocol draft
"draft-giaretta-netlmm-dt-protocol-00.txt", below are some
questions, comments, and suggestions. Hopefully they're helpful and
and at a high enough level.

Thanks,
Kevin

A) Is it envisioned that while a MN is within a mobility domain, it
will be associated with the same LMA regardless of the MAG? If so,
should the document state this explicitly; otherwise, could the
document maybe describe a case or cases where there would be a need
for changing LMAs?

B) Can a MN be associated with multiple LMAs simultaneously? For
example, if a mobility domain has multiple egress points, might it be
advantageous to funnel traffic through an LMA topologically closer to
the egress point? Should such a capability be permitted or prohibited? 

C) In a domain with multiple LMAs and no AAA, how should a MAG
determine which LMA to use for a newly arrived MN? Is iteratively
trying each LMA acceptable? 

D) When a MN moves to a new MAG, does the LMA send anything to the old
MAG to clean up state? If so, should text be added to section 4 and
8.2.3.5 to
describe this? 

E) Is it envisioned that in some circumstances the LMA might remain
unaware of whether a MN is authorized, and upon receiving a Location
Registration message, the LMA will contact an external system to
determine authorization?

F) Should text be added to section 4 to describe in more detail what
happens when a MN tries to configure a new address that is already in
use by
another MN?

G) Proper MAG/LMA behavior for reacting to a Disassociation Reply
message containing an error code is unspecified; is there a
recommended reaction? More generally, should the handling of different
error codes each Reply/Ack message be documented?

-----------------------------------------------------------------------
-----------------------------------------------------------------------
--------------------------------

A copy of the protocol design document is posted here:

http://www.geocities.com/kempf42/draft-giaretta-netlmm-dt-protocol-00.t
xt

           jak

----- Original Message ----- From: "Roberts Phil-APR042" <Phil.Roberts
at motorola.com>
To: <netlmm at ietf.org>
Sent: Tuesday, June 20, 2006 7:53 AM
Subject: [netlmm] NETLMM design team update

The design team is still continuing its work on the protocol design.
We
submitted a draft-00 of the document yesterday
(draft-giaretta-netlmm-dt-protocol-00.txt) and we would like to express
to the working group our assessment of the status of our work, what one
should expect from the draft at this stage, and what we would like as
working group input at this stage of the process.

The design team believes it has a good understanding of the new
functional elements being proposed for the NETLMM protocol and their
operation, of the message sequences between those functional elements,
and the contents of those messages.  The design team still has work to
do in describing these elements and in working out to its own
satisfaction some lingering issues that haven't been sufficiently
assessed in the protocol design.

The protocol draft (insert link) at this stage has descriptions of all
the functional elements and all of the protocol messages and fields.
The design team is considering another message in the protocol
sequences
but hasn't had enough time to digest the implications of it and
integrate it well into the document.  This version of the document is a
snapshot of the work and the design team realizes that more smoothing
and cleaning up is needed.  There is a section documenting open issues
that the design team is still working on.

It would be good for the working group when considering this document
not to focus too much on specific details, but to focus on the big
picture concepts in the document - the functional entities, the
protocol
exchanges, and the required fields.  The design team welcomes input at
this stage, but please be sensitive to the fact that comments at this
stage need to be kept at a high level.  There will be a time for
detailed review, but at this point big picture comments are what the
design team would like input on.

At IETF66 the design team will present the status of the work at that
time, which will probably include resolution of some outstanding items,
and another draft iteration either shortly before or shortly after
IETF.

Phil Roberts on behalf of the design team

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Andy Huang <[email-masked]>
Date: Fri, 23 Jun 2006 10:13:52 +0800

And I also have some questions after reading this protocol.
Q1:
Described in 8.2.1, the MAG List includes the following fields:
MAG ID of the associated MAG.
One or more IP address(es) of the associated MAG.
Forwarding capabilities of the associated MAG.
Forwarding setting for the associated MAG.
Capability list of the associated MAG.

I was confused with what  is the difference between 'Forwarding capabilities 
of the associated MAG' and 'Capability list of the associated MAG' ?
As to 'Forwarding setting for the associated MAG', is it a part of 
'Capability list of the associated MAG'?
The last three things seem ambiguous. Or I didn't understant them clearly?

Q2:
I am wondering whether MAG will send RA with LMA prefix in the prefix option 
periodically?

Q3:
Routing tag is defined in the protocol, but there is no details about how to 
use the routing tag in the traffic forwarding.

----- Original Message ----- 
From: "Grace, Kevin H." <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 23, 2006 5:41 AM
Subject: [netlmm] Questions regarding new NetLMM protocol draft

Thanks,
Kevin

           jak

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 24 Jun 2006 18:27:19 +0200

Hi Kevin,

  My personal responses / viewpoints on your comments:

> document maybe describe a case or cases where there would be a need

The document should start this explicitly.  Covered in Appendix A,
"TODO", last bullet (bullet 12).

> the egress point? Should such a capability be permitted or prohibited? 

No such capability has been discussed or envisioned by the design
team.  Anyway, I don't offhand see how multiple LMAs for one IP
address would work.

> trying each LMA acceptable? 

This is (at least currently) out of scope, and closely related
with the address assignment mechanism in use.

> MAG to clean up state? If so, should text be added to section 4 and

?? I think that this is *very* explicitly described in Sections 5.5
and 8.1.3.6 -- not sure of any need to add it to more sections...

> Registration message, the LMA will contact an external system to

Normally, authorization would be handled in association with
address allocation, before the Location Registration, but the
protocol doesn't make any such assumption, and as far as I can
see authorization could happen at the point you ask about, too.

> happens when a MN tries to configure a new address that is already in

Maybe.  I guess I feel this is decently covered in 7.1.1 and 8.2.3.4,
but if Section 4. doesn't become insufferably long, something could
be added there.

> error codes each Reply/Ack message be documented?

Good point.  We should add something about this.  I've added a TODO
item in the draft source on my disk, for now.

Regards,

	Henrik