Subject: [netlmm] Which Addressing Model to Choose?

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Jul 2006 12:16:22 -0700

At the Montreal meeting, the WG discussed the addressing model for NETLMM. 
The current DT NETLMM protocol design is neutral with respect to the 
addressing model. But comments expressed at the meeting and received by the 
co-chairs from IAB members offline suggest that the WG needs to decide on an 
addressing model for NETLMM. This note is intended to kick off technical 
discussion on the possible choices.

The two addressing models and how they apply to NETLMM are:

1) The shared link model, in which the access router or routers in the 
NETLMM domain advertise the same collection of prefixes for stateless 
address configuration on each link. For stateful address configuration, the 
DHCP server allocates addresses from the same shared prefixes for mobile 
nodes on all links. IPv6 Neighbor Discovery works as in RFC 2461 and 2462, 
including DAD, and broadcast and link local multicast traffic on the link is 
available to all nodes across all links.

2) A prefix-per mobile node model, in which the access router or routers 
advertise a unique set of prefixes to each mobile node for stateless 
configuration. For stateful address configuration, the DHCP server allocates 
addresses from unique per mobile node prefixes. With the exception of 
neighbor unreachability detection for the access router (which may be 
necessary if it is not done by the wireless link layer), IPv6 Neighbor 
Discovery is unnecessary because, effectively, there is only one mobile node 
on the link. Broadcast and/or link local multicast traffic can be done on 
the link but only the access router will see it.

The background for the shared link model should be well-known, as it is the 
default model for IP subnets. RFC 2461 and 2462 describe local link 
behavior, along with other RFCs in the IPv6 collection. The background for 
the prefix per mobile node model is probably less clear, but RFC 3314 
documents the recommendations the IETF made to 3gpp regarding the 
appropriateness of such a model and some suggestions about how to implement 
it. Replacing the link technology specific mechanisms described in RFC 3314 
with the equivalent standard IP based ones gives an idea how a NETLMM 
version of the prefix per mobile node model might work.

Up until now, the WG has considered partially supporting the shared sublink 
model on the MN-AR interface by forwarding particular link local multicast 
associated with DAD and having the MAGs function as routers with prefixes 
shared across multiple links. This is described in 
draft-ietf-netlmm-mn-ar-if-01.txt and is commonly called a "multilink 
subnet". The feedback we've gotten from IAB members is that this option is 
not such a good idea, the reasons why are described in 
draft-thaler-intarea-multilink-subnet-issues-00.txt.

Note that the choice of addressing model may also force a choice for the 
function of the MAG in the NETLMM architecture. The choices are:

1) The MAG functions as a router. It decrements TTL for all packets, and it 
limits broadcast and link local multicast traffic to a single interface and 
uses a different subnet prefix on each link.

2) The MAG functions as a bridge. It does not decrement TTL and it forwards 
broadcast and link local multicast across interfaces and uses the same 
subnet prefix on every link.

The implications of adopting the shared link model for NETLMM are that the 
MAGs must collaborate to provide the mobile nodes with the same view of 
multiple links as if they were a single broadcast domain. In order to 
provide a consistent model of MAG functionality and avoid the multilink 
subnet issues described in 
draft-thaler-intarea-multilink-subnet-issues-00.txt, the MAG would need to 
function as a bridge, with the LMA as the last hop router that originates 
the RAs.

The implications of the prefix per mobile node model are that the MAG may 
act as either a bridge or a router. If the MAG is a bridge, the LMA is the 
last hop router and it originates the RAs. If the MAG is a router, then 
NETLMM domain appears to the mobile node like a subnet with multiple access 
routers, which change as the mobile node moves. On each move, the subnet 
prefixes available to the mobile node do not change, they are the unique 
prefixes originally assigned to the mobile node. The implications of the MAG 
as router need further study, since the mobile node will be dropping and 
adding default routers as it moves. Note that 3gpp uses the MAG (SGSN in the 
case of 3gpp) as bridge so that case is much better understood from a 
deployment standpoint.

In discussing the issue, the WG should consider the following questions:

1) Is there any significant functional benefit provided by the shared link 
model, for the deployment scenerios envisioned in the PS draft and the goals 
in the REQ draft?

2) Is there any significant functional benefit provided by the prefix per 
mobile node model, for the deployment scenerios envisioned in the PS draft 
and the goals in the REQ draft?

 With regard to potential customers of NETLMM, 3gpp and 3gpp2 both use the 
prefix per mobile node model, but if that model is chosen, then customers 
who might want to support the shared link model will be unable to do so. 
Finally, though the current set of potential customers for NETLMM are 
primarily cellular or cellular-like protocols - where the prefix per mobile 
node model is a fair match with the link layer - the applicability of the 
prefix per mobile node model to shared link wireless protocols such as 
802.11 needs some additional thought.

We'll have the technical discussion for about a month, then do a consensus 
call (unless of course the technical discussion makes the WG consensus 
clear).

                    James and Phil

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jul 2006 13:04:00 -0700

James,

Initial reaction is that we should not forget about the case of DHCP
prefix delegation as a useful variant on the prefix-per-MN model.
About what you are calling the shared link model, that would certainly
entail bridging. In that case, what we have been calling "links" up
to now would more appropriately be called: "segments" in the larger
bridged link (see the terminology in RFC4389).

About the MN-AR interface spec, you are correct that it is currently
doing partial ND proxying. It supports proxying for DAD and it is also
doing proxy RAs, since the MAG is essentially sending proxied RAs on
behalf of the LMA. But, there is nothing in the spec that would be
incompatible with the prefix-per-MN model so labeling it as multilink
subnet would be too limiting for the flexibility it provides. Please
see also the section on "Multilink Subnet Considerations" in that
document and comment, since we have given this subject serious
consideration and want to make sure we get it right. Would also be
interested in hearing comments from others on this.

Thanks - Fred
[email-masked]

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 12:16 PM
To: [email-masked]
Subject: [netlmm] Which Addressing Model to Choose?

At the Montreal meeting, the WG discussed the addressing model for
NETLMM. 
The current DT NETLMM protocol design is neutral with respect to the 
addressing model. But comments expressed at the meeting and received by
the 
co-chairs from IAB members offline suggest that the WG needs to decide
on an 
addressing model for NETLMM. This note is intended to kick off technical

1) The shared link model, in which the access router or routers in the 
NETLMM domain advertise the same collection of prefixes for stateless 
address configuration on each link. For stateful address configuration,
the 
DHCP server allocates addresses from the same shared prefixes for mobile

nodes on all links. IPv6 Neighbor Discovery works as in RFC 2461 and
2462, 
including DAD, and broadcast and link local multicast traffic on the
link is 
available to all nodes across all links.

advertise a unique set of prefixes to each mobile node for stateless 
configuration. For stateful address configuration, the DHCP server
allocates 
addresses from unique per mobile node prefixes. With the exception of 
neighbor unreachability detection for the access router (which may be 
necessary if it is not done by the wireless link layer), IPv6 Neighbor 
Discovery is unnecessary because, effectively, there is only one mobile
node 
on the link. Broadcast and/or link local multicast traffic can be done
on 
the link but only the access router will see it.

The background for the shared link model should be well-known, as it is
the 
default model for IP subnets. RFC 2461 and 2462 describe local link 
behavior, along with other RFCs in the IPv6 collection. The background
for 
the prefix per mobile node model is probably less clear, but RFC 3314 
documents the recommendations the IETF made to 3gpp regarding the 
appropriateness of such a model and some suggestions about how to
implement 
it. Replacing the link technology specific mechanisms described in RFC
3314 
with the equivalent standard IP based ones gives an idea how a NETLMM 
version of the prefix per mobile node model might work.

Up until now, the WG has considered partially supporting the shared
sublink 
model on the MN-AR interface by forwarding particular link local
multicast 
associated with DAD and having the MAGs function as routers with
prefixes 
shared across multiple links. This is described in 
draft-ietf-netlmm-mn-ar-if-01.txt and is commonly called a "multilink 
subnet". The feedback we've gotten from IAB members is that this option
is 
not such a good idea, the reasons why are described in 
draft-thaler-intarea-multilink-subnet-issues-00.txt.

1) The MAG functions as a router. It decrements TTL for all packets, and
it 
limits broadcast and link local multicast traffic to a single interface
and 
uses a different subnet prefix on each link.

2) The MAG functions as a bridge. It does not decrement TTL and it
forwards 
broadcast and link local multicast across interfaces and uses the same 
subnet prefix on every link.

The implications of adopting the shared link model for NETLMM are that
the 
MAGs must collaborate to provide the mobile nodes with the same view of 
multiple links as if they were a single broadcast domain. In order to 
provide a consistent model of MAG functionality and avoid the multilink 
subnet issues described in 
draft-thaler-intarea-multilink-subnet-issues-00.txt, the MAG would need
to 
function as a bridge, with the LMA as the last hop router that
originates 
the RAs.

The implications of the prefix per mobile node model are that the MAG
may 
act as either a bridge or a router. If the MAG is a bridge, the LMA is
the 
last hop router and it originates the RAs. If the MAG is a router, then 
NETLMM domain appears to the mobile node like a subnet with multiple
access 
routers, which change as the mobile node moves. On each move, the subnet

prefixes originally assigned to the mobile node. The implications of the
MAG 
as router need further study, since the mobile node will be dropping and

adding default routers as it moves. Note that 3gpp uses the MAG (SGSN in
the 
case of 3gpp) as bridge so that case is much better understood from a 
deployment standpoint.

1) Is there any significant functional benefit provided by the shared
link 
model, for the deployment scenerios envisioned in the PS draft and the
goals 
in the REQ draft?

2) Is there any significant functional benefit provided by the prefix
per 
mobile node model, for the deployment scenerios envisioned in the PS
draft 
and the goals in the REQ draft?

 With regard to potential customers of NETLMM, 3gpp and 3gpp2 both use
the 
prefix per mobile node model, but if that model is chosen, then
customers 
who might want to support the shared link model will be unable to do so.

Finally, though the current set of potential customers for NETLMM are 
primarily cellular or cellular-like protocols - where the prefix per
mobile 
node model is a fair match with the link layer - the applicability of
the 
prefix per mobile node model to shared link wireless protocols such as 
802.11 needs some additional thought.

We'll have the technical discussion for about a month, then do a
consensus 
call (unless of course the technical discussion makes the WG consensus 
clear).

                    James and Phil

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Jul 2006 13:28:46 -0700

Fred,

I think the distinction between DHCP prefix delegation and advertising a 
prefix in an RA (or, alternatively, having the DHCP server allocate an 
address with a prefix) is that the node delegated prefixes by DHCP prefix 
delegation is allowed to further delegate them to subnet (that is, act as a 
router) whereas a prefix obtained from an RA can't be so used.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 13, 2006 1:04 PM
Subject: RE: [netlmm] Which Addressing Model to Choose?

James,

Thanks - Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, July 13, 2006 12:16 PM
To: [email-masked]
Subject: [netlmm] Which Addressing Model to Choose?

                    James and Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Jul 2006 22:32:55 +0200

Thanks for note, please allow me posting above your message.  I've read
it and I think so many sub-cases and mixtures between the two models
(shared link and prefix per-mobile) are possible that I won't mention
all.  E.g. DHCP could send prefixes to ARs (MAGs) according to mobile
movement, thus link and prefix per-mobile blend.

I'd support the following initial addressing architecture (copy pasted
from the home network models draft-soon-rfc):

               route     v  /48                        A:B:C::/48
                         |
                        LMA
                         | /64    intra-operator link: A:B:C:0::/64
              --+--.--+-.+- . -+- . -+--
                |     |        |     |
                AR1   AR2      ARi   ARn
                |     |        |     |
             ------  ------  ------ ------
               /64   /64      /64   /64    RA prefix:  A:B:C:i::/64

There can be routers between LMA and ARs.

The prefixes stay stable on links, don't change.  DHCP doesn't try to
follow MN movement and doesn't distribute prefixes to ARs.

The MN acquires a /128 address from LMA (probably a DHCP Server).  The
LMA and ARs co-operate (with netlmm protocol) to update single routes
towards full /128 addresses.  Local routing works with longest prefix
match, there would be no problem with MN using a /128 address under an
AR different from where it obtained it.  I.e. even if MN acquires an
address under AR1 (AR1 advertises a:b:c:1::/64) it can still use its
address a:b:c:1::something under AR2 which advertises a:b:c:2::/64,
provided that routes at AR2 know about this particular
a:b:c:1::something/128.

DHCP prefix delegation would still be used in case needed by MR (between
LMA and MR, not between LMA and AR).

The RAs sent by ARs should tell the MN to use DHCP to acquire an address
instead of stateless auto-conf ('M' bit IIRC, for "managed").

Is this a shared-link model or a prefix per-mobile model, I can't say.

With respect to the question whether MAG should be a bridge or a router,
I'd prefer the MAG (AR) to be a router, because I personally would know 
better how to handle it.

With respect to the question on what do customers prefer, I must say I
don't know.

FWIW, thanks,

Alex

James Kempf wrote:
> NETLMM. The current DT NETLMM protocol design is neutral with respect
>  to the addressing model. But comments expressed at the meeting and 
> received by the co-chairs from IAB members offline suggest that the 
> WG needs to decide on an addressing model for NETLMM. This note is 
> intended to kick off technical discussion on the possible choices.
> 
> 1) The shared link model, in which the access router or routers in 
> the NETLMM domain advertise the same collection of prefixes for 
> stateless address configuration on each link. For stateful address 
> configuration, the DHCP server allocates addresses from the same 
> shared prefixes for mobile nodes on all links. IPv6 Neighbor 
> Discovery works as in RFC 2461 and 2462, including DAD, and broadcast
>  and link local multicast traffic on the link is available to all 
> nodes across all links.
> 
> 2) A prefix-per mobile node model, in which the access router or 
> routers advertise a unique set of prefixes to each mobile node for 
> stateless configuration. For stateful address configuration, the DHCP
>  server allocates addresses from unique per mobile node prefixes.
> With the exception of neighbor unreachability detection for the
> access router (which may be necessary if it is not done by the
> wireless link layer), IPv6 Neighbor Discovery is unnecessary because,
> effectively, there is only one mobile node on the link. Broadcast
> and/or link local multicast traffic can be done on the link but only
> the access router will see it.
> 
> The background for the shared link model should be well-known, as it 
> is the default model for IP subnets. RFC 2461 and 2462 describe local
>  link behavior, along with other RFCs in the IPv6 collection. The 
> background for the prefix per mobile node model is probably less 
> clear, but RFC 3314 documents the recommendations the IETF made to 
> 3gpp regarding the appropriateness of such a model and some 
> suggestions about how to implement it. Replacing the link technology 
> specific mechanisms described in RFC 3314 with the equivalent 
> standard IP based ones gives an idea how a NETLMM version of the 
> prefix per mobile node model might work.
> 
> sublink model on the MN-AR interface by forwarding particular link 
> local multicast associated with DAD and having the MAGs function as 
> routers with prefixes shared across multiple links. This is described
>  in draft-ietf-netlmm-mn-ar-if-01.txt and is commonly called a 
> "multilink subnet". The feedback we've gotten from IAB members is 
> that this option is not such a good idea, the reasons why are 
> described in draft-thaler-intarea-multilink-subnet-issues-00.txt.
> 
> Note that the choice of addressing model may also force a choice for 
> the function of the MAG in the NETLMM architecture. The choices are:
> 
> 1) The MAG functions as a router. It decrements TTL for all packets, 
> and it limits broadcast and link local multicast traffic to a single 
> interface and uses a different subnet prefix on each link.
> 
> forwards broadcast and link local multicast across interfaces and 
> uses the same subnet prefix on every link.
> 
> The implications of adopting the shared link model for NETLMM are 
> that the MAGs must collaborate to provide the mobile nodes with the 
> same view of multiple links as if they were a single broadcast 
> domain. In order to provide a consistent model of MAG functionality 
> and avoid the multilink subnet issues described in 
> draft-thaler-intarea-multilink-subnet-issues-00.txt, the MAG would 
> need to function as a bridge, with the LMA as the last hop router 
> that originates the RAs.
> 
>  may act as either a bridge or a router. If the MAG is a bridge, the 
> LMA is the last hop router and it originates the RAs. If the MAG is a
>  router, then NETLMM domain appears to the mobile node like a subnet 
> with multiple access routers, which change as the mobile node moves. 
> On each move, the subnet prefixes available to the mobile node do not
>  change, they are the unique prefixes originally assigned to the 
> mobile node. The implications of the MAG as router need further 
> study, since the mobile node will be dropping and adding default 
> routers as it moves. Note that 3gpp uses the MAG (SGSN in the case of
>  3gpp) as bridge so that case is much better understood from a 
> deployment standpoint.
> 
>  link model, for the deployment scenerios envisioned in the PS draft 
>  per mobile node model, for the deployment scenerios envisioned in 
> the PS draft and the goals in the REQ draft?
> 
>  the prefix per mobile node model, but if that model is chosen, then 
> customers who might want to support the shared link model will be 
> unable to do so. Finally, though the current set of potential 
> customers for NETLMM are primarily cellular or cellular-like 
> protocols - where the prefix per mobile node model is a fair match 
> with the link layer - the applicability of the prefix per mobile node
>  model to shared link wireless protocols such as 802.11 needs some 
> additional thought.
> 
> consensus call (unless of course the technical discussion makes the 
> WG consensus clear).
> 
> 
> James and Phil
> 
> 
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jul 2006 14:09:40 -0700

James, 

> router) whereas a prefix obtained from an RA can't be so used.

Right; that is the useful variant I was referring to. I would like to
have things such that the MNs could also be routers for arbitrarily
complex networks attached on their downstream links and that model would
be well-supported by DHCP prefix delegation. It would also give rise to
a mobile router that could travel throughout the NETLMM domain and have
the delegated prefixes track along with it as it moves. (Global mobility
for such a mobile router would be out-of-scope, of course.)

This whole discussion is a very important one, and I'm glad that you
took the initiative to open it. As I said, we want to get things right
in the MN-AR interface spec and make sure no one goes off and shoots
themselves in the foot. It could be that we currently have too much
flexibility in the spec, so lets find out where the discussion takes
us and refine things as necessary.

Thanks - Fred

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 13, 2006 1:04 PM
Subject: RE: [netlmm] Which Addressing Model to Choose?

James,

Thanks - Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, July 13, 2006 12:16 PM
To: [email-masked]
Subject: [netlmm] Which Addressing Model to Choose?

                    James and Phil

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jul 2006 14:42:52 -0700

Alex,

It sounds as if you would like to have it that each AR (MAG) advertises
a different prefix, and that the MN acquires one or more addresses
relative
to the prefix being advertised by their "home" AR (MAG) - right? So then
when the MN moves to a "visited" AR it would keep its addresses, and
routing
on the home AR would be updated to point to the visited AR - does that
sound
right?

If so, I think you are hinting at more of a "mesh" deployment whereas
the
"classical" NETLMM model is more of a "hub-and-spokes" deployment. There
are many aspects of the mesh model that are attractive, including fault
tolerance and load balancing, but the model could be susceptible to
routing
churn and MNs could be left orphaned if their home AR (MAG) fails.
Please
check Appendix A of the "NETLMM using DHCP" I-D and see if that comes
close
to the model you are envisioning. IMO, there should be a way to couple
the
best aspects of both hub&spokes and mesh models in the correct
proportions
to provide a best-fit for the specific use-case scenarios.

Fred

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 1:33 PM
To: James Kempf
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

               route     v  /48                        A:B:C::/48
                         |
                        LMA

FWIW, thanks,

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Jul 2006 15:20:05 -0700

Alex,

Since DHCP is allocating the address, it could be either shared link or 
prefix per mobile node, depending on how the DHCP server is allocating the 
address. Note that just because the DHCP server is allocating the address 
doesn't mean that the last hop router won't do RAs with prefixes in them, 
however.

But you seem to want to make the MAGs into routers, which means the shared 
link model is out. As I mentioned in my email, the shared link model 
requires the MAGs to be bridges in order to maintain a consistent view of 
the NETLMM domain as a single "broadcast" domain. The prefix per mobile node 
model might allow the MAGs to be ARs, though. I don't think this impacts how 
the prefix numbering is done in the NETLMM domain beyond the wireless last 
hop.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2006 1:32 PM
Subject: Re: [netlmm] Which Addressing Model to Choose?

>> received by the co-chairs from IAB members offline suggest that the WG 
>> needs to decide on an addressing model for NETLMM. This note is intended 
>> to kick off technical discussion on the possible choices.
>>
>> the DHCP server allocates addresses from the same shared prefixes for 
>> mobile nodes on all links. IPv6 Neighbor Discovery works as in RFC 2461 
>> and 2462, including DAD, and broadcast
>>  and link local multicast traffic on the link is available to all nodes 
>> across all links.
>>
>> configuration. For stateful address configuration, the DHCP
>> the default model for IP subnets. RFC 2461 and 2462 describe local
>> background for the prefix per mobile node model is probably less clear, 
>> but RFC 3314 documents the recommendations the IETF made to 3gpp 
>> regarding the appropriateness of such a model and some suggestions about 
>> how to implement it. Replacing the link technology specific mechanisms 
>> described in RFC 3314 with the equivalent standard IP based ones gives an 
>> idea how a NETLMM version of the prefix per mobile node model might work.
>>
>> sublink model on the MN-AR interface by forwarding particular link local 
>> multicast associated with DAD and having the MAGs function as routers 
>> with prefixes shared across multiple links. This is described
>>  in draft-ietf-netlmm-mn-ar-if-01.txt and is commonly called a "multilink 
>> is not such a good idea, the reasons why are described in 
>> it limits broadcast and link local multicast traffic to a single 
>> forwards broadcast and link local multicast across interfaces and uses 
>> the same subnet prefix on every link.
>>
>> the MAGs must collaborate to provide the mobile nodes with the same view 
>> of multiple links as if they were a single broadcast domain. In order to 
>> to function as a bridge, with the LMA as the last hop router that 
>> originates the RAs.
>>
>>  may act as either a bridge or a router. If the MAG is a bridge, the LMA 
>> is the last hop router and it originates the RAs. If the MAG is a
>>  router, then NETLMM domain appears to the mobile node like a subnet with 
>> multiple access routers, which change as the mobile node moves. On each 
>> move, the subnet prefixes available to the mobile node do not
>>  change, they are the unique prefixes originally assigned to the mobile 
>> node. The implications of the MAG as router need further study, since the 
>> mobile node will be dropping and adding default routers as it moves. Note 
>> that 3gpp uses the MAG (SGSN in the case of
>>  3gpp) as bridge so that case is much better understood from a deployment 
>> standpoint.
>>
>>  link model, for the deployment scenerios envisioned in the PS draft and 
>> the goals in the REQ draft?
>>
>>  per mobile node model, for the deployment scenerios envisioned in the PS 
>> draft and the goals in the REQ draft?
>>
>> customers who might want to support the shared link model will be unable 
>> to do so. Finally, though the current set of potential customers for 
>> NETLMM are primarily cellular or cellular-like protocols - where the 
>> prefix per mobile node model is a fair match with the link layer - the 
>> applicability of the prefix per mobile node
>> consensus call (unless of course the technical discussion makes the WG 
>> consensus clear).
>>
>>
>> James and Phil
>>
>>
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Jul 2006 00:33:25 +0200

Templin, Fred L wrote:
> Alex,
> 
> It sounds as if you would like to have it that each AR (MAG) 
> advertises a different prefix, and that the MN acquires one or more 
> addresses relative to the prefix being advertised by their "home" AR 
> (MAG) - right?

Not quite, the MN would get an address from LMA DHCP server.  Address 
not necessarily derived from a designated "home" AR's prefix.

If there were 3 ARs, they'd RA prefixes :1:, :2: and :3: and DHCP would 
give addresses prefixed :4: to all MNs. (no AR would RA :4:).

> So then when the MN moves to a "visited" AR it would keep its 
> addresses, and routing on the home AR would be updated to point to 
> the visited AR - does that sound right?

Right.

>  the "classical" NETLMM model is more of a "hub-and-spokes" 
> deployment. There are many aspects of the mesh model that are 
> attractive, including fault tolerance and load balancing, but the 
> model could be susceptible to routing churn and MNs could be left 
> orphaned if their home AR (MAG) fails.

Routing churn - ok, if the model uses tunnels instead of real routes,
and still tunnel interfaces are pointed by full /128 addresses the
intermediary routers wouldn't be involved in potential churn.

"home" AR fails - ok, but I don't assume a "home" AR.  The important is 
that the nAR or LMA don't fail.

If "routes" are like "prefix/len  dst dev eth0" then probably churn 
risk.  If "routes" are like "addr/128 dst dev tun0" then probably less 
churn risk because no intermediary routers would be involved in routing 
message exchanges.

Actually I'll have to check "churn" in MW see what you mean.

> Please check Appendix A of the "NETLMM using DHCP" I-D and see if 
> that comes close to the model you are envisioning.

Will do, post back later.

> IMO, there should be a way to couple the best aspects of both
> hub&spokes and mesh models in the correct proportions to provide a
> best-fit for the specific use-case scenarios.

There should be.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Jul 2006 15:37:19 -0700

James,

One of Alex's points that should not be missed:

> all.

I agree with this, and see it that the prefix-per-mobile-node and
shared link cases are the two extreme endpoints of a continuum with
myriad sub-cases in-between. The tradeoff is likely to be flexibility
vs risk of mis-configuration, and it may not be a one-size-fits-all
in the end.

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 3:20 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

Alex,

Since DHCP is allocating the address, it could be either shared link or 
prefix per mobile node, depending on how the DHCP server is allocating
the 
address. Note that just because the DHCP server is allocating the
address 
doesn't mean that the last hop router won't do RAs with prefixes in
them, 
however.

But you seem to want to make the MAGs into routers, which means the
shared 
link model is out. As I mentioned in my email, the shared link model 
requires the MAGs to be bridges in order to maintain a consistent view
of 
the NETLMM domain as a single "broadcast" domain. The prefix per mobile
node 
model might allow the MAGs to be ARs, though. I don't think this impacts
how 
the prefix numbering is done in the NETLMM domain beyond the wireless
last 
hop.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2006 1:32 PM
Subject: Re: [netlmm] Which Addressing Model to Choose?

>                         | /64    intra-operator link: A:B:C:0::/64
WG 
the 

>>  and link local multicast traffic on the link is available to all
nodes 
>> 2) A prefix-per mobile node model, in which the access router or
routers 
is 
>> background for the prefix per mobile node model is probably less
clear, 
>> sublink model on the MN-AR interface by forwarding particular link
local 

>>  in draft-ietf-netlmm-mn-ar-if-01.txt and is commonly called a
"multilink 
the 
and 
>> forwards broadcast and link local multicast across interfaces and
uses 
>> The implications of adopting the shared link model for NETLMM are
that 
>> draft-thaler-intarea-multilink-subnet-issues-00.txt, the MAG would
need 
LMA 
>>  router, then NETLMM domain appears to the mobile node like a subnet
with 
mobile 
>>  3gpp) as bridge so that case is much better understood from a
deployment 
and 
>>  per mobile node model, for the deployment scenerios envisioned in
the PS 
>> customers who might want to support the shared link model will be
unable 
>> consensus call (unless of course the technical discussion makes the
WG

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Jul 2006 15:42:38 -0700

Fred,

The issue is that the advice we're getting from IAB members is to choose one 
or the other. The WG is, of course, free to ignore that advice, but then the 
WG faces a significant intellectual marketing effort trying to convice the 
IETF in general and IESG in particular that this choice is acceptable. 
Speaking as the WG chair, I would certainly like the avoid having to make 
that effort.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2006 3:37 PM
Subject: RE: [netlmm] Which Addressing Model to Choose?

James,

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, July 13, 2006 3:20 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

Alex,

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2006 1:32 PM
Subject: Re: [netlmm] Which Addressing Model to Choose?

WG
the

nodes
routers
is
clear,
local

"multilink
the
and
uses
that
need
LMA
with
mobile
deployment
and
the PS
unable
WG

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 14 Jul 2006 05:16:17 -0400

Hello James,

This is a really valuable snapshot to think about.

First of all, I would like share my comments about the terminology used in the dt-protocol-draft.

draft-giaretta-netlmm-dt-protocol-00.txt defines the MAC and LMA like below:
----------------------------
The Mobile Access Gateway
      The Mobile Access Gateway (MAG) is a router that a mobile node is
      attached to as the first hop router in the NetLMM infrastructure.
      The MAG is connected to the mobile node over some specific link
      provided by a link layer but the NetLMM infrastructure is agnostic
      about the link layer technology that is used.  Each MAG has its
      own identifier used in NetLMM protocol messaging between the MAG
      and the LMA.  The important interfaces between link layer specific
      functions and the NetLMM function reside on the MAG.  There are
      multiple MAGs in a NetLMM infrastructure.

The Local Mobility Anchor
      The local mobility anchor (LMA) is a router that maintains
      reachability to a mobile node's address while the mobile node
      moves around within the NetLMM infrastructure.  It is responsible
      to maintain forwarding information for the mobile nodes which
      includes a set of mappings to associate mobile nodes by their
      identifiers with their address information, associating the mobile
      nodes with their serving MAGs and the relationship between the LMA
      and the MAGs.  There may be one or more LMAs in a NetLMM
      infrastructure.
--------------------------------------

I would like to have your opinion whether it is possible to delete the phrase of "is a router" from both parts if this does not affect the netlmm architecture.
In my understanding, the distinctive feature of MAC is to provide the specific L2 link connectivity to the MN.
BTW, the feature of LMA is to provide the L3 reachability to the MN.
If I am missing something here, please correct me.

At this point, I would like to add one more comment about the used "IP Link" terminology in that draft.
The draft defines the IP Link like below:

  IP Link
      A set of routers, mobile nodes, and wireless access points that
      share link broadcast capability or its functional equivalent.
      This definition covers one or multiple access points under one or
      several access routers.  In the past, such a set has been called a
      subnet, but this term is not strictly correct for IPv6, since
      multiple subnet prefixes can be assigned to an IP link in IPv6.

Could you decouple that definition like "IP Subnet" and "Link" that was specified from the Dave's draft?
IMHO, the last sentence of the definition might cause some confusion by combining the "IP" with "Link".
I think more better way is to use IP Subnet and Link very distinctively. If this is already amended, sorry for the late re-visit.
Even if there was some discussion regarding this on the mailing list, my memory is not so clear and the current version of 
draft-giaretta-netlmm-dt-protocol-00.txt still combines "IP" and "Link".

Now, back to the main issue which addressing model to choose in netlmm architecture.
Yes, as you pointed out, the issue of MAC's acting as a router is a valuable point to think about.
Here, maybe another separation whether it has a bridge function or not thinking about the case 
where L2 entity just delivers the packets to the L3 entity using tunneling between them.
In more higher level, I would like to have your opinion whether it is more preferable to start from 
more basic line by thinking about the functionality of the LMA in the netlmm architecture.
Definitely, it is a router so it is expected to decrement TTL for all packets. 
Thus, this LMA separates a "Link". If this LMA distributes the same "IP Subnet" prefixes over the separated "Link"
This results in multilink subnet issues regardless of the MAC's functionality, I think.
Again, If I am misunderstanding about netlmm architecture, please correct me.

Best Regards,
-Junghoon

---

From: Andy Huang <[email-masked]>
Date: Fri, 14 Jul 2006 17:19:37 +0800

It seems to me that the issue is very similar to multilink subnets issue 
which has ever been discussion in the ml.

I think these two addressing models are two kinds of different ways to 
realize the requirement defined in PS draft. Of course, prefix-per mobile 
node model has its own advantage, i.e. it can avoid a lot of trouble such as 
DAD, DNA, proxy RA, default router selection and so on. In fact, these 
questions are resulted from current Netlmm architecture. To some degree, I 
think current architecture is a kind of multilink subnets architecture 
because the same questions exist in the multilink subnets. Link-scoped 
multicast and DAD have been brought up in 
[draft-thaler-intarea-multilink-subnet-issues-00.txt]. What's more, I have 
the same worry as Vijay about whether the SeND and the DNA spec will be 
widely implemented and used or not.

However, if we can solve these problems perfectly we can insist on our 
current choice. IMHO, we should not give up our efforts on the way to 
success even if there are some potential problems in the current solution. 
And if we mean to adopt prefix-per mobile node model perhaps much more works 
have to be done. What's more, I could not see more benefits from prefix-per 
mobile node model though it is recommended to 3GPP in RFC3314.

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Templin, Fred L" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 14, 2006 6:42 AM
Subject: Re: [netlmm] Which Addressing Model to Choose?

> Fred,
>
> The issue is that the advice we're getting from IAB members is to choose 
> one or the other. The WG is, of course, free to ignore that advice, but 
> then the WG faces a significant intellectual marketing effort trying to 
> convice the IETF in general and IESG in particular that this choice is 
> acceptable. Speaking as the WG chair, I would certainly like the avoid 
> having to make that effort.
>
>            jak
>
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Jul 2006 08:19:58 -0700

> I would like to have your opinion whether it is possible to delete the 
> phrase of "is a router" from both parts if this does not affect the netlmm 
> architecture.

I think the LMA must be a router. Whether or not the MAG could be a router 
depends on the addressing model. Remember, however, that we are talking 
about functional entitites here. It is possible for an AR to have MAG 
functionality and for the MAG to be a bridge, just as an AR can have NAS 
functionality but also route. Bridging could also be resticted to particular 
subnets, perhaps O&M traffic to and from the base stations is routed while 
data plane traffic to mobiles is bridged. This is a little unusual from an 
abstract enterprise IP network perspective, but is found in  some cellular 
architectures.

> I think more better way is to use IP Subnet and Link very distinctively. 
> If this is already amended, sorry for the late re-visit.
> Even if there was some discussion regarding this on the mailing list, my 
> memory is not so clear and the current version of

This comment came up on the PS and REQ drafts too.

> Thus, this LMA separates a "Link". If this LMA distributes the same "IP 
> Subnet" prefixes over the separated "Link"

Well, this still doesn't determine whether the shared link model or prefix 
per mobile node model is your preference. The LMA is a router in both cases. 
The question is what role should the MAG play?

         jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Jul 2006 08:27:20 -0700

> node model has its own advantage, i.e. it can avoid a lot of trouble such 
> as DAD, DNA, proxy RA, default router selection and so on. In fact, these

I don't think prefix per mobile node can avoid all of these. Basically:

1) DAD: With the prefix per mobile node model, the MN does DAD but there is 
no possibility of ever having an address conflict, because the MN is the 
only one on the link. So there is no need to forward NAs between links.
2) DNA: If the link layer does not provide bidirectional reachability 
detection of the AR and movement detection, then these will have to be done 
at the IP layer. They must be done regardless of which model is used. In 
fact, DNA must be used on every L2 move (i.e. from one AP to another) for 
bidirectional reachability detection of the AR and subnet movement detection 
unless these are provided by the wireless link layer.
3) Proxy RA: Not sure what you meant here.
4) Default router selection: Again, unless the wireless link layer supplies 
this, it will need to be done at the IP layer, even with prefix per mobile 
node.

Prefix per mobile node doesn't get rid of having to do these operations, it 
just modifies the possible answers a MN can get to simplify the protocol.

> widely implemented and used or not.

Well, one could say the same of NETLMM at this point. :-) The question 
should be what is the right technical choice.

> And if we mean to adopt prefix-per mobile node model perhaps much more 
> works have to be done. What's more, I could not see more benefits from 
> prefix-per mobile node model though it is recommended to 3GPP in RFC3314.
>

OK, sounds like you are in favor of continuing to develop multilink subnets. 
Perhaps you could give some thought to what benefits multiink subnets would 
have over the other two models, to justify the effort we will have to make 
to get it through the IESG.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Jul 2006 13:46:59 -0700

James,

I did some more thinking about the "in-between" cases, and I now think
that pretty much all of them run up against multilink subnet issues of
one form or another. But, the in-between cases can often be "mended"
using tunnels to make them look like the shared link model - at the
expense of extra overhead in the data plane, of course.

The main point I want to make for now is that it does not have to
be a one vs. the other decision at this point. Instead, both models
may have their respective use-cases. I'm thinking prefix-per-mn for
environments that require large (huge?) scaling properties, and shared
link for smaller deployments that have lots of shared services. It
should be all the same as far as the NETLMM protocol is concerned
(since the NETLMM is a control-plane protocol) and is really more
of a consideration for the data plane and for the MN-AR interface.

One thing I want to reiterate and make sure the point gets across,
in the case where prefix-per-MN is used why not give the MN the
*whole* prefix using DHCP prefix delegation instead of just one or
a few addresses using SLAAC? If it is prefix-per-MN, the MN should
get the whole thing so it can act as a mobile router and further
sub-delegate the prefix to its downstream links.

The other point is that if DHCP prefix delegation is used, the
RAs don't have to carry any prefix information options at all.
Link movement detection and confirmation would then simply use
the standard DHCP Confirm/Rebind mechanisms.

Thanks - Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 3:43 PM
To: Templin, Fred L; Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

Fred,

The issue is that the advice we're getting from IAB members is to choose
one 
or the other. The WG is, of course, free to ignore that advice, but then
the 
WG faces a significant intellectual marketing effort trying to convice
the 
IETF in general and IESG in particular that this choice is acceptable. 
Speaking as the WG chair, I would certainly like the avoid having to
make 
that effort.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Alexandru Petrescu" 

James,

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Thursday, July 13, 2006 3:20 PM
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

Alex,

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 13, 2006 1:32 PM
Subject: Re: [netlmm] Which Addressing Model to Choose?

WG
the

nodes
routers
is
clear,
local

"multilink
the
and
uses
that
need
LMA
with
mobile
deployment
and
the PS
unable
WG

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Jul 2006 14:09:49 -0700

Fred,

jak>> Good. The extra tunnels make for more complexity, right?

jak>> From the standpoint of getting the work approved by the IESG, I think 
it would be a problem if we were to say that we want to support multilink 
subnets. Since "extraordinary claims require extraordinary evidence", they 
will certainly press us hard if we send our documents to them with multilink 
subnets as the default case, and we will need to really justify that.

jak>> Also, I would like to know why people thing the shared link model is 
necessary to support, given the scenerios in the PS draft and other likely 
deployment scenerios. What does the design gain by makeing the mobile node 
believe that there are other nodes on the link, other than it looks like an 
enterprise Ethernet-based nework? The latter has little value in my mind, 
since most deployed public access networks don't look like that.

jak>> The other issue with supporting both is that it will introduce 
additional complexity. The WG already expressed a concern about complexity 
in Montreal.

jak>> The problem is that DHCP is not "required to implement" for an IPv6 
node, wheras SLAAC is. I agree that having DHCP described in the MN AR 
interface document is useful, because some of our potential customers use 
DHCP, but we can't not do SLAAC.

            jak

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 14 Jul 2006 22:31:05 -0400

> I think the LMA must be a router. 

Sure, there needs at least of one router for MN's L3 reachability. 
The suggestion of deleting "is a router" from both parts comes from no clear benefit by adding that phrase.

-Junghoon

---

From: Andy Huang <[email-masked]>
Date: Mon, 17 Jul 2006 21:37:23 +0800

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 14, 2006 3:16 AM
Subject: [netlmm] Which Addressing Model to Choose?

...[snip]

> access routers, which change as the mobile node moves. On each move, the 
> subnet prefixes available to the mobile node do not change, they are the 
> unique prefixes originally assigned to the mobile node. The implications 
> of the MAG as router need further study, since the mobile node will be 
> dropping and adding default routers as it moves. Note that 3gpp uses the 
> MAG (SGSN in the case of 3gpp) as bridge so that case is much better 
> understood from a deployment standpoint.
>
=>I don't know how to introduce NetLMM protocol into 3GPP architecture. IMO, 
there is little chance to it because WCDMA has provided the mobility of 
inter-SGSN. When MS moves to new SGSN, Route Area Update or Location Update 
will trigger handover between old SGSN and new SGSN. The GTP tunnel will be 
switched to new SGSN and communication will continue. From the perspective 
of NetLMM protocol, the GTP tunnel between SGSN and GGSN is similar to the 
tunnel between MAG and LMA. However, this GTP tunnel is established when MN 
initiates PDP Context Activation process. i.e. NetLMM protocol function has 
been defined in 3GPP, right?

> goals in the REQ draft?
> mobile node model is a fair match with the link layer - the applicability 
> of the prefix per mobile node model to shared link wireless protocols such 
> as 802.11 needs some additional thought.

[quoted from RFC3314]
   The IPv6 WG recommends that the 3GPP treat a primary PDP context,
   along with its secondary PDP contexts, as a single IPv6 link, and
   that the GGSN view each primary PDP context as a single subnet.
   Accordingly, a given global (or site-local) prefix should not be
   assigned to more than one PDP context.

=> I don't know why prefix per MN model should be used for 3GPP? It's 
different from current 2.5G case.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Jul 2006 15:51:36 +0200

James Kempf wrote:
> Fred,
> 
> I did some more thinking about the "in-between" cases, and I now
> think that pretty much all of them run up against multilink subnet
> issues of one form or another. But, the in-between cases can often be
> "mended" using tunnels to make them look like the shared link model -
> at the expense of extra overhead in the data plane, of course.
> 
> The main point I want to make for now is that it does not have to be
> a one vs. the other decision at this point. Instead, both models may
> have their respective use-cases. I'm thinking prefix-per-mn for 
> environments that require large (huge?) scaling properties, and
> shared link for smaller deployments that have lots of shared
> services. It should be all the same as far as the NETLMM protocol is
> concerned (since the NETLMM is a control-plane protocol) and is
> really more of a consideration for the data plane and for the MN-AR
> interface.
> 
> jak>> From the standpoint of getting the work approved by the IESG, I
>  think it would be a problem if we were to say that we want to
> support multilink subnets. Since "extraordinary claims require
> extraordinary evidence", they will certainly press us hard if we send
> our documents to them with multilink subnets as the default case, and
> we will need to really justify that.
> 
> jak>> Also, I would like to know why people thing the shared link
> model is necessary to support, given the scenerios in the PS draft
> and other likely deployment scenerios. What does the design gain by
> makeing the mobile node believe that there are other nodes on the
> link, other than it looks like an enterprise Ethernet-based nework?
> The latter has little value in my mind, since most deployed public
> access networks don't look like that.
> 
>  additional complexity. The WG already expressed a concern about 
> complexity in Montreal.
> 
> One thing I want to reiterate and make sure the point gets across, in
> the case where prefix-per-MN is used why not give the MN the *whole*
> prefix using DHCP prefix delegation instead of just one or a few
> addresses using SLAAC? If it is prefix-per-MN, the MN should get the
> whole thing so it can act as a mobile router and further sub-delegate
> the prefix to its downstream links.
> 
> The other point is that if DHCP prefix delegation is used, the RAs
> don't have to carry any prefix information options at all. Link
> movement detection and confirmation would then simply use the
> standard DHCP Confirm/Rebind mechanisms.
> 
> jak>> The problem is that DHCP is not "required to implement" for an
>  IPv6 node, wheras SLAAC is. I agree that having DHCP described in
> the MN AR interface document is useful, because some of our potential
> customers use DHCP, but we can't not do SLAAC.

RA, usually used for SLAAC (stateless address autoconf), can be
configured such that the node configures an address from DHCP (put 'M'
bit in RA), instead of configuring from a prefix in that RA.

SLAAC could give a temporary address to MN, not guaranteeing session
continuity, but valid on that link.  The address for session continuity
would come from DHCP.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Jul 2006 09:37:51 -0700

James,

> jak>> From the standpoint of getting the work approved by the IESG, I
think 
> subnets as the default case, and we will need to really justify that.

I don't see the problem here. Whether the link btw the MN and
AR (MAG) is pt-2-pt, shared link or multilink is immaterial to
the NETLMM protocol. All the NETLMM protocol should be doing is
delegating address/prefixes and adding/deleting routes based on
requests from MNs. In other words, the NETLMM protocol should be
agnostic as to how the MN-AR link looks and it should be left up
to access network operators to not deploy a link model that might
give the MNs an unpleasant surprise.

IMO, the best way to address this is to document the potential
issues and provide advice to access network operators in a
"Multilink Subnet Considerations" sections that explains the
negative implications of multilink subnet and tells how to
avoid/mitigate them through informed operational practice. 

> additional complexity. The WG already expressed a concern about
complexity 
> in Montreal.

Howso? It should be all the same to the NETLMM protocol no matter
how the access network link(s) appears. Instead, it seems like we
would have to go out of our way to disallow certain access network
link models when the is no real compelling reason to do so.

> jak>> The problem is that DHCP is not "required to implement" for an
IPv6 

> DHCP, but we can't not do SLAAC.

Well, if we set the 'M' bit in RAs it would be the network's
way of providing advice to MNs which they would probably do
well to heed. Legacy MNs could then still use SLAAC if they
didn't have DHCP client support, but it seems like MN migration
to DHCP would inevitable in order to realize the benefits of
prefix delegation if not other useful features such as DNS
delegation, etc.

Fred

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jul 2006 10:30:02 -0700

Fred,

think

jak>> Phil and I discussed multilink subnets with Jari (IESG), Dave Thaler, 
and Bernard Aboba (IAB) in Montreal, and the answer is still "if you want to 
do multilink subnet, you'll need to justify it really strongly, and, btw, we 
think it would be better if you stick to an existing addressing model". From 
personal experience in other cases where the IESG and IAB were skeptical 
about something (i.e. AAA keys), I think this will open the WG to perhaps 
2-3 years of discussion and debate with the IESG, which in the end may or 
may not be successful in convincing them that the multilink subnet model has 
major benefits for NETLMM and that we have throught through the technical 
considerations enough for them to accept the model. We are likely to have 
our docs rejected when we initially submit them. Needless to say, we will 
miss any chance of getting other SDOs to deploy NETLMM in the short term.

jak>> If I thought that multilink subnets had any major benefit for NETLMM 
deployments, I would be arguing strongly in favor of continuing on that path 
and working through the technical considerations. But, I don't see any major 
benefits. Maybe you or someone else can explain them? I don't mean how to 
make it work, I mean *why* are multilink subnets better than either the 
shared link model or the prefix per mobile node model for the deployment 
cases NETLMM is considering? Nobody so far has been able to make that case, 
AFICT. All people seem to be saying is "that's what we are working on now, 
so let's stick to it rather than change".

complexity

jak>> We already have one case where multilink subnets would add complexity 
to the NETLMM protocol. In order for DAD security to work, if the LMA 
detects a duplicate address, it must ask the MAG on which the existing owner 
mobile node is located to DAD-solicit the address, then the MAG must forward 
the address through the LMA to the MAG on which the new mobile node doing 
DAD is located. This allows the owner of the address to put SEND on the DAD. 
But the LMA and MAGs cannot decrement TTL, which they would otherwise do 
since by the multilink subnets they are routers. This means either the 
NETLMM protocol must have a special message just to forward the DAD NA, or 
the MAG and LMA must snoop the DAD NA message.

jak>> With either the prefix per mobile node model or the shared link model 
there is no need for special treatment for DAD. With the prefix per mobile 
node model, DAD never discovers another address on the link. With the shared 
link model, all link local multicast traffic is forwarded because the MAGs 
are acting as bridges, so the DAD traffic need not be treated separately.

jak>> Now I know that DHCP doesn't have this problem, but the fact is that 
we need to support SLAAC as well as DAD, because SLAAC is "required to 
implement" for IPv6.

IPv6

jak>> Right but some IPv6 host stacks (Microsoft's for example), don't 
support DHCP. If we want to support minimal changes in the host, we need to 
support what IPv6 has as default, which is SLAAC.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 17 Jul 2006 10:52:45 -0700

In the SAE, possible options are on the S1, S5a, S5b, and/or S2 interfaces.

Nobody is proposing that NETLMM be used in existing, deployed GPRS systems.

            jak

----- Original Message ----- 
From: "Andy Huang" <[email-masked]>
To: "James Kempf" <[email-masked]>; <[email-masked]>
Sent: Monday, July 17, 2006 6:37 AM
Subject: Re: [netlmm] Which Addressing Model to Choose?

>> the last hop router and it originates the RAs. If the MAG is a router, 
>> then NETLMM domain appears to the mobile node like a subnet with multiple 
> =>I don't know how to introduce NetLMM protocol into 3GPP architecture. 
> IMO, there is little chance to it because WCDMA has provided the mobility 
> of inter-SGSN. When MS moves to new SGSN, Route Area Update or Location 
> Update will trigger handover between old SGSN and new SGSN. The GTP tunnel 
> will be switched to new SGSN and communication will continue. From the 
> perspective of NetLMM protocol, the GTP tunnel between SGSN and GGSN is 
> similar to the tunnel between MAG and LMA. However, this GTP tunnel is 
> established when MN initiates PDP Context Activation process. i.e. NetLMM 
> protocol function has been defined in 3GPP, right?
>
>> of the prefix per mobile node model to shared link wireless protocols 
>> such as 802.11 needs some additional thought.
>
> [quoted from RFC3314]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Jul 2006 16:57:23 -0700

James,

w/o going through exhausing detail, I'll grant your point that
multilink subnet is responsible for requiring the proxied NS(DAD)
in the SLAAC case. If not for the SEND requirements, the procedure
would be simple ND proxying, but with SEND things get a bit more
complex. As you say, this would not be a problem for the DHCP
case but if SLAAC is the base case then we have to take the
added complexity into account.

One thing I will challenge, though, is the assumptiom that the
ARs (MAGs) and/or LMAs need to be either just routers or just
bridges; there might be some operational advantage to having
them function as hybrid routing-bridges instead.

Fred

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, July 17, 2006 10:30 AM
To: Templin, Fred L; Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [netlmm] Which Addressing Model to Choose?

Fred,

think

jak>> Phil and I discussed multilink subnets with Jari (IESG), Dave
Thaler, 
and Bernard Aboba (IAB) in Montreal, and the answer is still "if you
want to 
do multilink subnet, you'll need to justify it really strongly, and,
btw, we 
think it would be better if you stick to an existing addressing model".
From 
personal experience in other cases where the IESG and IAB were skeptical

about something (i.e. AAA keys), I think this will open the WG to
perhaps 
2-3 years of discussion and debate with the IESG, which in the end may
or 
may not be successful in convincing them that the multilink subnet model
has 
major benefits for NETLMM and that we have throught through the
technical 
considerations enough for them to accept the model. We are likely to
have 
our docs rejected when we initially submit them. Needless to say, we
will 
miss any chance of getting other SDOs to deploy NETLMM in the short
term.

jak>> If I thought that multilink subnets had any major benefit for
NETLMM 
deployments, I would be arguing strongly in favor of continuing on that
path 
and working through the technical considerations. But, I don't see any
major 
benefits. Maybe you or someone else can explain them? I don't mean how
to 
make it work, I mean *why* are multilink subnets better than either the 
shared link model or the prefix per mobile node model for the deployment

cases NETLMM is considering? Nobody so far has been able to make that
case, 
AFICT. All people seem to be saying is "that's what we are working on
now, 
so let's stick to it rather than change".

complexity

jak>> We already have one case where multilink subnets would add
complexity 
to the NETLMM protocol. In order for DAD security to work, if the LMA 
detects a duplicate address, it must ask the MAG on which the existing
owner 
mobile node is located to DAD-solicit the address, then the MAG must
forward 
the address through the LMA to the MAG on which the new mobile node
doing 
DAD is located. This allows the owner of the address to put SEND on the
DAD. 
But the LMA and MAGs cannot decrement TTL, which they would otherwise do

since by the multilink subnets they are routers. This means either the 
NETLMM protocol must have a special message just to forward the DAD NA,
or 
the MAG and LMA must snoop the DAD NA message.

jak>> With either the prefix per mobile node model or the shared link
model 
there is no need for special treatment for DAD. With the prefix per
mobile 
node model, DAD never discovers another address on the link. With the
shared 
link model, all link local multicast traffic is forwarded because the
MAGs 
are acting as bridges, so the DAD traffic need not be treated
separately.

jak>> Now I know that DHCP doesn't have this problem, but the fact is
that 
we need to support SLAAC as well as DAD, because SLAAC is "required to 
implement" for IPv6.

IPv6

jak>> Right but some IPv6 host stacks (Microsoft's for example), don't 
support DHCP. If we want to support minimal changes in the host, we need
to 
support what IPv6 has as default, which is SLAAC.

            jak

---

From: Andy Huang <[email-masked]>
Date: Tue, 18 Jul 2006 15:50:24 +0800

I agree that multilink subnets has no more benefits than the prefix per MN 
model if address space is not the point. I also think it's possible that 
addressing model change will not result in a lot of changes in current work. 
If we have no more evidence to support multilink subnets we have to modify 
our work in consideration of the future of NetLMM  protocol.

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Templin, Fred L" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 1:30 AM
Subject: Re: [netlmm] Which Addressing Model to Choose?

> Thaler, and Bernard Aboba (IAB) in Montreal, and the answer is still "if 
> you want to do multilink subnet, you'll need to justify it really 
> strongly, and, btw, we think it would be better if you stick to an 
> existing addressing model". From personal experience in other cases where 
> the IESG and IAB were skeptical about something (i.e. AAA keys), I think 
> this will open the WG to perhaps 2-3 years of discussion and debate with 
> the IESG, which in the end may or may not be successful in convincing them 
> that the multilink subnet model has major benefits for NETLMM and that we 
> have throught through the technical considerations enough for them to 
> accept the model. We are likely to have our docs rejected when we 
> initially submit them. Needless to say, we will miss any chance of getting 
> other SDOs to deploy NETLMM in the short term.
>
> path and working through the technical considerations. But, I don't see 
> any major benefits. Maybe you or someone else can explain them? I don't 
> mean how to make it work, I mean *why* are multilink subnets better than 
> either the shared link model or the prefix per mobile node model for the 
> deployment cases NETLMM is considering? Nobody so far has been able to 
> make that case, AFICT. All people seem to be saying is "that's what we are 
> working on now, so let's stick to it rather than change".
>
> complexity to the NETLMM protocol. In order for DAD security to work, if 
> the LMA detects a duplicate address, it must ask the MAG on which the 
> existing owner mobile node is located to DAD-solicit the address, then the 
> MAG must forward the address through the LMA to the MAG on which the new 
> mobile node doing DAD is located. This allows the owner of the address to 
> put SEND on the DAD. But the LMA and MAGs cannot decrement TTL, which they 
> would otherwise do since by the multilink subnets they are routers. This 
> means either the NETLMM protocol must have a special message just to 
> forward the DAD NA, or the MAG and LMA must snoop the DAD NA message.
>
> model there is no need for special treatment for DAD. With the prefix per 
> mobile node model, DAD never discovers another address on the link. With 
> the shared link model, all link local multicast traffic is forwarded 
> because the MAGs are acting as bridges, so the DAD traffic need not be 
> treated separately.
>
> to support what IPv6 has as default, which is SLAAC.
>
>            jak
>
>

---

From: Andy Huang <[email-masked]>
Date: Tue, 18 Jul 2006 16:28:28 +0800

If MAG just works as bridge, it can forward link local multicast and 
broadcast and use the same subnet on every link. I am wondering whether the 
NetLMM protocol is necessary in the case or not. And I also remember MAG is 
a router in the NetLMM protocol.

   Mobile Access Gateway (MAG)
      A Mobile Access Gateway (MAG) is a router embedded in a device
      that terminates a specific link layer technology to which mobile
      nodes attach themselves.  It terminates one end of the MAG of the
      connection to one or more Local Mobility Anchors and participates
      in the NetLMM protocol exchange.

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 7:57 AM
Subject: RE: [netlmm] Which Addressing Model to Choose?

James,

Fred

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Jul 2006 09:11:29 +0200

On Monday 17 July 2006 19:30, James Kempf wrote:
> NETLMM deployments, I would be arguing strongly in favor of
> continuing on that path and working through the technical
> considerations. But, I don't see any major benefits. Maybe you or
> someone else can explain them? I don't mean how to make it work, I
> mean *why* are multilink subnets better than either the shared link
> model or the prefix per mobile node model for the deployment cases
> NETLMM is considering? Nobody so far has been able to make that
> case, AFICT. All people seem to be saying is "that's what we are

The original proposal for the MN-AR interface was based on a 
multi-link subnet model, adding complexity to both the interface and 
NetLMM protocol. 

While making the thing to work has been technically interesting and 
rewarding for me, I do not think there is any benefit for the network 
and the MN (I don't think "wasting" of addressing space is a real 
issue, see RFC3314 as Phil suggested.)

Like James, I am hence wondering what people think is the benefit of 
such approach.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Jul 2006 11:03:38 +0200

James Kempf wrote:
> Well, if we set the 'M' bit in RAs it would be the network's way of 
> providing advice to MNs which they would probably do well to heed. 
> Legacy MNs could then still use SLAAC if they didn't have DHCP client
>  support, but it seems like MN migration to DHCP would inevitable in 
> order to realize the benefits of prefix delegation if not other 
> useful features such as DNS delegation, etc.
> 
> jak>> Right but some IPv6 host stacks (Microsoft's for example), 
> don't support DHCP.

Not sure about that.  Haven't checked in practice but tech notes at MS
website make think DHCPv6 may be supported in Vista and Longhorn, in
addition to stateless auto-config. http://tinyurl.com/7nkb8

> If we want to support minimal changes in the host, we need to support
>  what IPv6 has as default, which is SLAAC.

It's true that more implementations have SLAAC than DHCPv6 but that may
change.  Because IPv4 deployers are used to centrally manage address
distribution.

Alex

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 18 Jul 2006 09:45:48 -0500

Since addressing is not an issue, I don't see that multilink subnets has
more benefits over the prefix per MN 
model.

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2006 2:11 AM
To: [email-masked]
Cc: Templin, Fred L
Subject: Re: [netlmm] Which Addressing Model to Choose?

On Monday 17 July 2006 19:30, James Kempf wrote:
> NETLMM deployments, I would be arguing strongly in favor of continuing

> on that path and working through the technical considerations. But, I 
> don't see any major benefits. Maybe you or someone else can explain 
> them? I don't mean how to make it work, I mean *why* are multilink 
> subnets better than either the shared link model or the prefix per 
> mobile node model for the deployment cases NETLMM is considering? 
> Nobody so far has been able to make that case, AFICT. All people seem 
> to be saying is "that's what we are working on now, so let's stick to 
> it rather than change".

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Jul 2006 08:50:23 -0700

> added complexity into account.

I'm going to have to go back on what I said here, because I think
we are getting confused between multilink subnets and multilink
*NETLMM domains*. In the case of a single shared link alone, it
would be a single-link NETLMM domain and no proxy DAD would be
needed. In all other cases, however, it would be a multilink NETLMM
domain whether the multiple links were pt-2-pt, shared links, or a
mixture of both. In that case, if a MN's link-local address is to
be used to identify the MN within the NETLMM domain there would
still need to be a proxy DAD mechanism for link-local addresses
(as currently specified in the MN-AR interface spec) even if all
MNs use the prefix-per-MN model. So it is multilink *NETLMM domain*
and not multilink subnet that is causing the need for DAD proxying.
(Note that the DHCP access method can be implemented w/o RFC2462
DAD and hence w/o the need for link-local proxy DAD.)

About the prefix-per-MN model, it is *not* specific to pt-2-pt
links. The prefix-per-MN  model can be used whether the links
are pt-2-pt or shared links, and using the prefix-per-MN model
in both cases clearly avoids multilink subnet issues.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 09:23:54 -0700

jak>> Like what?

jak>> BTW, the TRILL WG is working on a kind of hybrid router/bridge. It 
uses link state routing between the devices. I think they're looking at a 
scalability limit considerably below what we are, primarily because (if I 
understand correctly) of the scalibility of link local multicast.

            jak

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Jul 2006 09:43:38 -0700

> understand correctly) of the scalibility of link local multicast.

Yes, I already answered this same thing about TRILL/RBridge in my
reply to Kent. The TRILL people use the term "campus" to refer to
a potentially large link that connects multiple segments via
RBridges. I agree that a single RBridged campus might not fulfill
the scaling requirements for a large NETLMM domain, but I don't
see a problem with having lots of campuses within a single
NETLMM domain.

Fred

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jul 2006 10:42:51 -0700

Agreed.

            jak

----- Original Message ----- 
From: "Templin, Fred L" <[email-masked]>
To: "James Kempf" <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 18, 2006 9:43 AM
Subject: RE: [netlmm] Which Addressing Model to Choose?

Fred

---

From: Julien Laganier <[email-masked]>
Date: Wed, 19 Jul 2006 09:50:18 +0200

Fred,

I think your message below got to the point. However I'd like to add a 
precision w.r.t. need to DAD link-local address:

Depending on the subnet model:

 - multi-link-subnet: proxy DAD required for all MNs addresses 
(link-locals and globals)

 - per-MN-subnet: proxy DAD not required for global addresses because 
only the MAG and MN are in the same subnet. Proxy DAD a priori 
required for the link-local MN address. However, if *all links* in 
the domain are *pt-2-pt*, then it there's no proxy DAD required for 
link-local addresses because only the MAG and MN would ever be 
on-(a-given-)link.

What do people on the list think?

--julien

On Tuesday 18 July 2006 17:50, Templin, Fred L wrote:
> > in the SLAAC case. If not for the SEND requirements, the
> > procedure would be simple ND proxying, but with SEND things get a
> > bit more complex. As you say, this would not be a problem for the
> > DHCP case but if SLAAC is the base case then we have to take the

---

From: Andy Huang <[email-masked]>
Date: Wed, 19 Jul 2006 17:26:59 +0800

Yes, I think so. But in the netlmm domain there is a precondition, MAG must 
not forward the local link multicast and boardcast.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Jul 2006 10:55:13 -0700

Hi Julien,

> (link-locals and globals)

It seems like this discussion is helping to further our
understanding. Based on Dave Thaler's draft and on what
we've talked about here (and also on a discussion I just
had with my officemate), I'm becoming increasingly of
the opinion that multilink subnet is just plain dangerous
operational practice. An informed application developer
would rightly ask: "How can a node be on my *subnet*, but
not be a neighbor on my *link*?", and an uninformed
application developer could very easily (and innocently)
write code that breaks in obscure ways. In other words,
multilink subnet violates a fundamental architectural
principle of the Internet.

It seems that in order to do it "right" from a protocol/
interface standpoint we would have to proxy/bridge all
link-scoped communications. But then, we would have a
single shared link and not a multilink subnet at all.
Short of that, the mechanism can either: 1) allow
flexibility but warn against poor operational practices,
or 2) constrain flexibility so that poor operational
practices cannot occur.   

> only the MAG and MN are in the same subnet.

I agree; per-MN-subnet is a clean aproach in any case.

> Proxy DAD a priori 

The only issue I see here is whether the link-local address is to
be used to identify the MN within a NETLMM domain. If so, there
needs to be some means to ensure that the MN's link-local address
is unique within the domain whether all links are pt-2-pt or some
mix of pt-2-pt and shared links. If we could somehow get the MAG
to assign the link-local address to the MN, then there is no need
for DAD because the MAG can be considered an authoritative address
delegation agent. On the other hand, if the MN is going to
self-assign a link-local, there needs to be some form of DAD.
If the DAD can be done w/o having to involve a MN on another link
then that is fine. But, if the DAD might potentially need to
involve a MN on another link, that starts down the slippery
slope of multilink subnet. 

> What do people on the list think?

Let's keep talking and make sure we get this one right.

Fred

--julien

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Jul 2006 11:00:25 -0700

Julien,

> link-local addresses because only the MAG and MN would ever be

In the per MN subnet model, fow would the MAG and LMA ensure that the MN 
doesn't pick a duplicate link local addres, if proxy DAD is not done? 
Perhaps they simply don't forward the NS because they are enforcing a single 
MN per link?

               jak

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Jul 2006 09:49:41 +0200

> Hi Julien,

Hi Fred,

cutting down a bit,

> [...]
>
> > - per-MN-subnet: proxy DAD not required for global addresses
> > because only the MAG and MN are in the same subnet.
>
> > required for the link-local MN address. However, if *all links*
> > in the domain are *pt-2-pt*, then it there's no proxy DAD
> > required for link-local addresses because only the MAG and MN
> > would ever be on-(a-given-)link.
>
> be used to identify the MN within a NETLMM domain. 

I do not think that issues are limited to the case where link-local 
address is used as the MN's identifier.

If a given link is not pt-2-pt, e.g. broadcast multi access like 
Ethernet, then there is a problem if two on-link MNs use the same 
link-local address. This is orthogonal to the "per-MN-subnet prefix" 
property because the prefix is only used to configure global unicast 
addresses, whereas all link-local unicast addresses will live under 
fe80::/10 prefix.

If the two colliding MNs configures their LL addresses (and do DAD) 
for the first time while on the same link, then we do not have a 
problem because plain DAD (without proxy) will take care of that.

But if the two colliding MNs configures their LL addresses (and do 
DAD) for the first time while on different links and the NetLMM 
infrastructure does not proxy DAD, then we do have a problem: If 
later on it happens that one of the MN moves to the same link that 
the other, they will be using the same link local address on the same 
link. If the link is broadcast multi-access that is certainly not 
acceptable.

> If so, there 
> delegation agent.

I do not think it is possible that the MAG assign link-local addresses 
per the current specification. Further, that would defeat most of 
link-locals usage which I thought was to allow autoconfiguration.

> On the other hand, if the MN is going to 

The need to involve a MN on another link comes from SEND requirement 
of signed ND messages. 

I do not think relaying *only* DAD would really "starts down the 
slippery slope of multilink subnet" as you put it. If that is the 
only thing ever relayed, then I think we do not have a multilink 
subnet. We are just enforcing "multilink link-locals uniqueness", 
which is a small subset of "multilink subnets."

--julien