Subject: RE: [netlmm] FW: comments to Sri's draft

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 13 Mar 2007 15:03:44 -0700

Hi Heejin,
 
Thanks for the comments, please see inline.
 
Regards
Sri

  _____  

From: Heejin Jang [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 6:59 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netlmm] FW: comments to Sri's draft

 >  I have some comments on the draft.

 >  1. MAG location

 > - Unlike ver-01, it's not clearly stated where MAG is located. If MAG is
not collocated with an access router, some functions such as sending MN-HNP
in an RA would be difficult.

MAG is a functional element. It has various parts. How the function is
implemented or architected is very much specific to the

architecture.

>  2. RA before PBU

>  - In Section 3, it seems that an RA with MN-HNP is sent before the PBU is
accepted. There may be a problem if PBU is rejected 

>  - When the auto-configuration is allowed, the MN assumes that MN-HoA is
valid right after completing the configuration. However,  

>  the HoA is valid only after PBU is accepted. Moreover, in case PBU is
rejected afterward, the MN mistakenly assumes the invalid 

>  HoA is valid. 

>  - I think it's more robust to send an RA with MN-HNP after PBU is
accepted.

>  - When PBU is rejected finally (after several trials), it's better to
notify the rejection explicitly by sending RA (PI option including HLP with
0-lifetime) so that the MN cannot use the HoA based on HLP ASAP. 

Good point. We thought about this. If the PBU is rejected, the MAG can
always send an RA retiring the prefix with 0 lifetime

and further removing the source based route over the tunnel. This case is no
different from LMA rejecting a subsequent PBU

after accepting the initial PBU and so if even if we switch the order, we
will always hit this case.

 >  3. Problem of RA unicast

 > - In Section 6, RA is supposed to be sent to the MN as a unicast by
setting IPv6 destination = all-nodes multicast & link 

>  layer address = MN's MAC address. But how can MAG always know the MN's
MAC address? If MN sends RS or NS with 

>  the unspecified source address (::) after link change, it may be
difficult for MAG to learn MN's MAC address unless MN's profile includes it.

Access authentication ensures a mobile node, identified by MN-Identifier and
with a given MAC address is authorized to use the

link. That is stated assumption.  Also, when the MN sends the RS, the L3
header can be unspecified address (::), but the L2 header

should contain the mobile node's MAC address. 

>  4. Format of HNP option

>  - In Section 8, an HNP option can carry HNP or HoA but not both at the
same time. We can make the option to carry both of them by defining a new
bit as in 'R' flag in PI option (according to MIPv6 RFC3775). If the flag is
set to 1, it means that HNP option  

>  includes HoA and the 'Prefix Length' field identifies the length of HLP
which is already prepended to HoA. 

Ok. So, we need a flag as supposed to using the 128 bit length to
differentiate between the HoA vs HNP. 

Good point.

>  5. The use of 'on-link' prefix 

>  - In section 7, it is written that ".. advertising the mobile node's home
prefix as the on-link prefix and with the other configuration parameters".
Does the 'on-link' mean that 'L-flag' in PI option should be set to 1 in RA?
Should it be?

Yes. The prefix is hosted locally on the access link and the on-link flag
must be set.

>  6. Overhead of RA unicast 

>  In PMIP domain, there may be MNs with cmip capabililty and without cmip
capability that require network based mobility.  
> Therefore MAG cannot send multicast RAs but needs to send unicast RAs
node-by-node all the time. 
 
This is required for the shared link support. The advertised prefix must be
on a node basis and we need to isolate the view. 

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

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 14 Mar 2007 17:18:59 +0900

Hi

> implemented or architected is very much specific to the architecture.

Allow me a few questions.

1. When a MAG and an access router are in separate boxes, how can the
MAG make the access router to send an RA message with MN-HNP? There
must be some kind of signaling between them.

2. When a MAG and an access router are in separate boxes, how can the
MAG can forward the packets destined to an MN (which arrives through
the tunnel from LMA)?

3. Can a single MAG serve two different access routers in two
different links (like PMIP client in draft-singh)?

I don't know how some MAG functions could be performed unless the MAG
is collocated with an access router.

> will always hit this case.

So in case of PBU reject, the MAG advertises the MN-HNP with 0 life
time to make the MN stop using the rejected MN-HoA. Am I right?

But that would invalidate all MN-HoA with the same prefix. There may
be a problem if the MN has multiple MN-HoAs.

Allow me to give an example.
Assume an MN configures a MN-HoA1 with an MN-HNP and PBU is accepted.
So the MN-HoA1 is valid and the MN uses the address.
After a while, the MN configures another MN-HoA2 (maybe for privacy
reason) with the same MN-HNP but this time PBU is rejected (maybe for
LMA capacity).
If the MAG advertise the MN-HNP with lifetime 0, it would invalidate
not only MN-HoA2 but also unnecessarily MN-HoA1.

> with a given MAC address is authorized to use the link. That is stated assumption.
> Also, when the MN sends the RS, the L3

The statement assume that a MAC address is used in L2 communication.
However 802.16 doesn't use MAC address for the communication. 802.16
header doesn't carry MAC address. I wish the statement would be
modified to incorporate 802.16 case.

> Yes. The prefix is hosted locally on the access link and the on-link flag

Even if a prefix is hosted on an access link, the prefix can be
advertised without setting L-bit. A prefix with L = 0 doesn't say
anything of its on-link or off-link properties as below.

      L              1-bit on-link flag.  When set, indicates that this
                     prefix can be used for on-link determination.  When
                     not set the advertisement makes no statement about
                     on-link or off-link properties of the prefix.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 14 Mar 2007 23:29:16 -0700

Hi Jin, 

Please see inline.

-----Original Message-----
From: JinHyeock Choi [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 1:19 AM
To: Sri Gundavelli
Cc: Heejin Jang; [email-masked]
Subject: Re: [netlmm] FW: comments to Sri's draft

> must be some kind of signaling between them.
..

MAG is a functional element. we did not state, how to break that 
function, that is specific to the architecture. There is no single 
requirement from all SDO's suggesting a specific model and so there
is no single way to break that function and its better if the solution
from IETF stays generic and leaves that to the specific SDO's.
This functional separation, has no bearing on the core Proxy Mobile
IPv6 operation. In the simplest model, there could be a part of the MAG
function, a control element, that detects a mobile node on the access
link and sends a simple event to the MAG to perform the registration
and set up the data path. That's one way of functional separation and
where only part of the control function is on the Access Router and the
part of the function is outside the Access Router. In another model,
the using the Alt-CoA option, the tunnel can be terminated on a different
entity, thus keeping the control and data paths separate and again this
has no bearing on the Proxy Mobile IPv6 protocol, addressing model or
the any of the core aspects of the protocol. This is orthogonal to the
base protocol.

> be a problem if the MN has multiple MN-HoAs.

No. We clearly said, on a shared access link, the RA's have to be
segregated. Each mobile MUST see's its own prefix and not see some other
node's prefix.  The RA's have to be sent to L2 unicast address and
L3 multicast address. If multiple MN's are on the same prefix, still
the RA'c must be unicasted and hence the expiring the prefix logic
should work just fine.

> not only MN-HoA2 but also unnecessarily MN-HoA1.

Does not matter. We are creating a prefix route and infact the MAG
MAY never predictably know the address that the mobile is using. 
LMA accepting a BU, implies the authorization for the mobile to use
that prefix and if autoconfig is enabled, it MAY consume one or more
addresses. Now, if the PBU is rejected subsequently, the network has
the right to deny that prefix for that mobile node and including one
or more addresses that the mobile may be using from that prefix.

> modified to incorporate 802.16 case.

Ok. Please suggest some text.

>                     on-link or off-link properties of the prefix.

Not sure, why it should not be set. The prefix follows the mobile and
its always onlink, on the access link. So, I don't see the issue, if the
L-bit is set.

Thanks for the comments.

Regards
Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 15 Mar 2007 18:55:26 +0900

Dear Sri

Thanks for your kind reply.

> or more addresses that the mobile may be using from that prefix.

That does not matter if binding is managed between Proxy-CoA and
prefix (MN-HNP). But it does if binding is managed between Proxy-CoA
and HoA (MN-HoA). It still is not clear to me which one you intend.

> Ok. Please suggest some text.

The simplest text would be to just state the requirement as below,

An MAG (or AR) should see to that the the RA is delivered to the MN in unicast.
The specific mechanism may differ according to specific link-layer technology.

> its always onlink, on the access link. So, I don't see the issue, if the

What I mean is NOT that L-bit should not be set BUT that L-bit may not
be set. We don't have to 'MUST' set L-bit.

Best Regards

JinHyeock

p.s.
By the way, I sent the following mail but didn't receive a reply yet.
If you kindly reply, it would be of help.

Dear Sri

I also went over the draft and here are my main concerns.

1. Link/ Subnet model
- I assume that the draft supports ONLY per-MN-prefix model and
doesn't consider shared prefix model. Am I right? If so, I recommend
the draft states that in more clear and explicit way.
- The drafts seems to support shared link from the below

  This Proxy Mobile IPv6 scheme is independent of the underlying access
  technology or the link model.  The interface between the mobile node
  and the mobile access gateway can be either:

  o  Point-to-Point Link

  o  Shared Link

I wonder this may conflict with 'per-MN-prefix model'. In previous
per-MN-prefix models such as 'IPv6 over 3GPP' or 'IPv6 over 802.16',
'per-MN-prefix model' entails a peer-to-peer link. Every MN belongs to
a peer-to-peer link and no two MNs belong to the same link at any
time. We'd better define per-MN-prefix model more clearly.

2. MN-HoA Role
- It's not clear what MN HoA's role will be. Is the Proxy Binding
established between
MN-HoA and Proxy CoA or
MN-HNP (Home Network Prefix) and Proxy CoA?
- I think it's easier to manage the binding with MN-HNP, instead of
MN-HoA. But there are several sentences implying the latter as below.

  Proxy Binding Update (PBU)

     A signaling message sent by the mobile access gateway to a mobile
     node's local mobility anchor for establishing a binding between
     the mobile node's MN-HoA and the Proxy-CoA.

Kindly clarify.

3. MN-HoA detection
- I have a few related questions
 1) Does PBU ALWAYS carry an MN-HoA?
 2) Does Binding Cache entry in 5.1 ALWAYS has an MN-HoA?
 3) Does Binding Update List in 6.2 ALWAYS has an MN-HoA?
 4) Does MN profile ALWAYS include an MN-HoA?
- If 1) is yes, how an MAG can reliably know a MN's MN-HoA, which is
stateless auto-configured?
- If 4) is yes, how a policy store can reliably know a MN's MN-HoA,
which is stateless auto-configured?

4. Home link emulation
- It's written MAG performs Home link emulation by sending RAs with
MN-HNP and OTHER PARAMETERS. But the other parameters such as link MTU
may not be valid in a currently attached link. I think it's enough
just to send MN-HNP in RAs without having to worry about other
parameters.

5. Home link attachment
- It's not clear to me whether an MN can attach to its Home link. In
other word, is it possible for an MN to attach to the same link as its
LMA? Kindly clarify.

I have a few suggestions.

1. I have difficulty grasping the whole PMIPv6 procedure. Sec 3
doesn't distinguish 'Initial Attachment' and 'Intra-LMD mobility' as
in draft-singh. I propose to present the procedure in two stages,
1) Inital attachment, where an MN attaches to a PMIPv6 domain for the
first time
  and doesn't have an MN-HoA yet and
2) Intra-LMD mobility where the MN moves inside PMIPv6 domain and has
the MN-HoA.

2. The order of signaling messages is not clear. I am not sure whether
'RA is sent before PBU' or not. I think the figure describing
signaling procedure like Figure 2), 3) in draft-singh would be of
help.

Best Regards

JinHyeock

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 15 Mar 2007 14:44:24 -0400

Sir, 

Sorry for jumping in the middle of discussion. 
Please find few inline comments. 

Regards,
Ajoy  

the using the Alt-CoA option, the tunnel can be terminated on a
different

Ajoy-> There are implications on protocol behavior. If you allow PMIP
anchoring we
will see following modifications to protocol behavior: 
(1) There will be NO NEED of BU timestamp extension 
(2) There will be no need for LMA to authorize MAG during every
inter-MAG handoff.  
(3) Most of PMIPv6 specific changes proposed to MIPv6 HA will be
eliminated thereby 
 hugely simplify PMIP protocol design. This is so because standalone
PMIP client makes 
 PMIPv6 protocol semantically similar to client MIPv6 protocol. 

IMO, this is a key concept and should not be left to SDOs. 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, March 15, 2007 1:29 AM
To: 'JinHyeock Choi'
Cc: 'Heejin Jang'; [email-masked]
Subject: RE: [netlmm] FW: comments to Sri's draft

Hi Jin, 

Please see inline.

-----Original Message-----
From: JinHyeock Choi [mailto:[email-masked]]
Sent: Wednesday, March 14, 2007 1:19 AM
To: Sri Gundavelli
Cc: Heejin Jang; [email-masked]
Subject: Re: [netlmm] FW: comments to Sri's draft

..

the using the Alt-CoA option, the tunnel can be terminated on a
different

Thanks for the comments.

Regards
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 11:55:10 -0700

Hi Jin,

Please see inline.

Sri
 
>and HoA (MN-HoA). It still is not clear to me which one you intend.

The binding is for the prefix. I did clarify this in my earlier email
as well. There could be optionally and MN-HoA present in the BCE, however
that is for keeping the reachable state of the mobile and has no implication
on the protocol. In any case, the creation of the BCE implies the state
for the whole prefix. 

> The specific mechanism may differ according to specific link-layer
technology.

Ok. Thanks

>be set. We don't have to 'MUST' set L-bit.

Hmm...Need to think a bit more on the implication of this. But, its a minor
issue for now.

> If you kindly reply, it would be of help.

Well, I already replied to this email.  I can send you again. Here it is..

> Sent: Tuesday, March 13, 2007 10:37 PM
> To: 'JinHyeock Choi'
> Cc: [email-masked]'
> Hi JinHyeock,
> Thanks for the comments. Please see inline 
>
> Regards
> Sri
>
> Sent: Tuesday, March 13, 2007 5:00 AM
> To: Sri Gundavelli
> Cc: [email-masked]

> time. We'd better define per-MN-prefix model more clearly.

There are two things here

- Addressing Model
- Access Link Types

For the addressing model, we support Per-MN-Prefix model and for the
link types, we support both P2P links and Shared links. All though
all the 3 major SDO architectures assume a P2P link model, for supporting
802.11 WLAN scenario, we decided to support both the link types and this
was based on feedback from the WG. When supporting the Shared-link model,
the proxy mobility agent/MAG has to ensure, the RA's advertising the
mobile node's home network prefix are unicasted or some how segregated,
beyond that there are no known issues and no reason as to support 
Per-MN-Prefix model only on a specific link type. All thought the
peer-to-peer
link model is assumed in the above specifications, you have listed, don't
see any issues supporting that addressing model on a shared link.

>      the mobile node's MN-HoA and the Proxy-CoA.

Sure. In the Per-MN-Prefix model, the MN-HoA has little relevance. The
route is created for the whole prefix on the LMA. However, if the MAG
can predictable determine the mobile node's home address, it can certainly
update the LMA and can be stored in the BCE. This may have little
value from the protocol operation perspective, but as a mobility management
system, it is useful information to preserve the reachable address of the
mobile node in the BCE, that the network manages. Its optional information
and is not required. So, the MN-HNP is relevant here and not as such the 
MN-HoA. The key index elements of the BCE, will be the MN-Identifier or
the Prefix Identifier. We prefer to leave this as an implementation choice.

>  1) Does PBU ALWAYS carry an MN-HoA?

No. Its optional and has no bearing on the protocol.

>  2) Does Binding Cache entry in 5.1 ALWAYS has an MN-HoA?

No. Its optional.

>  3) Does Binding Update List in 6.2 ALWAYS has an MN-HoA?

No. Its optional. The MAG MAY not be able to determine the MN-HoA,
when using auto address configuration techniques based on cryptographic
properties. 

> which is stateless auto-configured?

MN-HoA need not be in the mobile node's profile. If present and
if the MAG has the ability to deliver that information to the mobile
node using IKEv2, DHCP or IPCP other mechanisms, it MAY be there in
the profile for that purpose. However, this aspect has no bearing on
the signaling messages between the LMA and the MAG.

> just to send MN-HNP in RAs without having to worry about other

Sure. That's why, we removed the specific properties after -01 version.

> other word, is it possible for an MN to attach to the same link as its

No.
There is no real home link. When using Per-MN-Prefix model, the LMA is
a topological anchor point and does not host the mobile node's home 
prefix and hence is not required to participate in any Proxy ND operations.
The prefix is hosted on the access link and for the mobile node, the
whole PMIPv6 domain appears as its home link.

> signaling procedure like Figure 2), 3) in draft-singh would be of

We had the call flow in -0 version of the draft and later removed
it. We will work on this section and improve the presentation in the
next version. If need be, we will bring the call flow back.

> Thanks for your kind consideration.

Thanks again for the comments.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 16 Mar 2007 11:37:35 +0900

Dear Sri

Thanks for your clarifying reply. Now I can understand the draft
intention better.

> Hmm...Need to think a bit more on the implication of this. But, its a minor

ok.

> Well, I already replied to this email.  I can send you again. Here it is..

For whichever reason, I didn't receive the reply. :-(

> see any issues supporting that addressing model on a shared link.

I see. Previously the term 'per-MN-prefix model' meant both
'Addressing Model' and 'Access Link Types', so I was confused.

> the Prefix Identifier. We prefer to leave this as an implementation choice.

I see. I wish the draft make it more clear that the binding is for the
prefix. There are a few confusing statements.

> Sure. That's why, we removed the specific properties after -01 version.

ok.

> whole PMIPv6 domain appears as its home link.

Let me rephrase the question. Can an MN and its LMA be at the same
(physical) link?

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 20:24:16 -0700

Hi Jin,

Please see inline.

-----Original Message-----
> Sent: Thursday, March 15, 2007 7:38 PM
> To: Sri Gundavelli

> For whichever reason, I didn't receive the reply. :-(

No problem.

> 'Addressing Model' and 'Access Link Types', so I was confused.

Yes

> prefix. There are a few confusing statements.

Ok. We will make it clear.

> Let me rephrase the question. Can an MN and its LMA be at the same

No. Not per this spec i.e not atleast when we are supporting Per-MN-Prefix
model only. The prefix moves with the mobile and the LMA does not bind
this prefix on a physical interface. LMA is just a topological anchor
point. But, this question can be ambiguous. I'm not talking about the
scenario where the LMA shares a link with A MAG and the mobile attaches
to that link. I just say, the MN-HNP is not hosted on the LMA's physical
interface, when supporting Per-MN-Prefix model.

Thanks
Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 16 Mar 2007 15:09:31 +0900

Sri

> point.

ok.

> But, this question can be ambiguous. I'm not talking about the
> to that link.

This scenario is what I am concerned. The case seems like 'an MN
returning Home N/W' in MIPv6. Even in this case, is Proxy BU performed
just the same?

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 15 Mar 2007 23:15:23 -0700

Hi JinHyeock, 

>returning Home N/W' in MIPv6. Even in this case, is Proxy BU performed

No. But, the LMA will never advertise the MN-HoA prefix on any of its
interfaces. Again, the prefix is not hosted on the interface of the 
LMA attached to that link. Only the MAG on that link will do that. 

Sri