Subject: [netlmm] draft-ietf-netlmm-mn-ar-if-03.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 13 Feb 2008 17:10:50 -0500

I have just submitted a new version of draft-ietf-netlmm-mn-ar-if,
which you can find here:

http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt

Soon I expect there will be an HTML diff from -02 at this location:

http://tools.ietf.org/wg/netlmm/draft-ietf-netlmm-mn-ar-if/draft-ietf-ne
tlmm-mn-ar-if-03-from-02.diff.html

Major changes:

* Modified description of step REP1 of MAG_GET_MN_ID sub-function
  to state that PBU/PBACK exchange must complete before RA is sent.
  I think this is necessary to get the right HNP into the RA.

* Added a MAG_GET_HI sub-function with advice on how to populate
  ATT, MNIID, and HI fields of the PBU.

* Added a straw-man Security Considerations section.

Comments and suggestions welcome.

-Pete
_______________________________________________
netlmm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/netlmm

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 27 Feb 2008 10:24:39 -0500

Peter,
        I have a comment on Section 6.

It is not clear how MN_ATTACH function is invoked. It says when MN 
attaches to the new MAG MN_ATTACH function is invoked. I think it would 
be clear to mention how the MN knows that it has moved to a new MAG. 
Does it invoke MN_ATTACH every time it changes L2 link?

Section 5 has some minor typo.

Regards
Ashutosh

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

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 27 Feb 2008 10:49:12 -0500

Hi, Ashutosh,

Ashutosh Dutta wrote:
> attaches to the new MAG MN_ATTACH function is invoked. I think it
> would be clear to mention how the MN knows that it has moved to a new
> MAG. Does it invoke MN_ATTACH every time it changes L2 link?  

How this happens is really outside the scope of the draft; the MN_ATTACH
invocation is an abstraction for some link-dependent event that causes
the
MN to send a new RS (according to DNA specs).  Yes, this function should
be invoked whenever the MN changes its L2 link (or when PPP goes down
and
comes back up).

> Section 5 has some minor typo.

Can you point them out more specifically?  I think I see one "the link
did
changed" which I can fix.  Any others?

Thanks,

-Pete

>> Soon I expect there will be an HTML diff from -02 at this location:
http://tools.ietf.org/wg/netlmm/draft-ietf-netlmm-mn-ar-if/draft-ietf-
>> ne tlmm-mn-ar-if-03-from-02.diff.html
>> 
>> Major changes:
>>

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 27 Feb 2008 10:57:35 -0500

Hi Peter,
          So is it the fundamental assumption that we have a new MAG for 
each L2 link independent of the link type (WiFi or CDMA(PPP))?

         In one of our preliminary PMIP implementation (WiFi) in the 
lab, we look for L2 link change (ESSID) and trigger the RS to start the 
PMIP BU. I was just curious if we are in fact following the standard.

That was the only typo I could see in Section 5.

Regards
Ashutosh

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 27 Feb 2008 11:12:15 -0500

Hi, Ashutosh,

Ashutosh Dutta wrote:
> Hi Peter,
>           So is it the fundamental assumption that we have a new MAG
> for each L2 link independent of the link type (WiFi or CDMA(PPP))? 

I think that's a matter for deployments to determine.  The MN-AR draft
just references DNA to say that the MN sends an RS whenever the link
changes.  Absent some link indication, there is really no way for the
MN to determine whether it is on a new MAG or the same MAG - in fact the
IP stack is fooled into thinking it is always the same MAG while in the
same NETLMM domain.

> lab, we look for L2 link change (ESSID) and trigger the RS to start
> the PMIP BU. I was just curious if we are in fact following the
> standard.   

I think that's a valid implementation.

> That was the only typo I could see in Section 5.

Ok, it will be fixed in the next version.

Thanks for your review.

-Pete

>>> would be clear to mention how the MN knows that it has moved to a
>>> new MAG. Does it invoke MN_ATTACH every time it changes L2 link?
>> 
>> How this happens is really outside the scope of the draft; the
>> MN_ATTACH invocation is an abstraction for some link-dependent event
>> that causes the MN to send a new RS (according to DNA specs).  Yes,
>> this function should be invoked whenever the MN changes its L2 link
>> (or when PPP goes down and comes back up).
>> 
>> Can you point them out more specifically?  I think I see one "the
>> link did changed" which I can fix.  Any others?
>> 
>> Thanks,
>> 
>> -Pete
>> 
>> 
>>> Regards
>>> Ashutosh
>>> 
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.tx
>>>> t

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 27 Feb 2008 10:25:45 -0600

Ashutosh,

As Pete mentioned a link change does not necessarily imply a MAG change. It
is upto implementations to determine if a change of AP/BS triggers the MN
sending an RS.
However the MN has to verify if the MAG has changed by sending an RS and
determine if the MAG has changed based on the RA.
In your example, I guess a change in the AP is not triggering an RS but
rather a change in the ESSID.... It is IMO valid. But if you want to be
aggressive about verifying if the MAG has changed, you would trigger the RS
on every AP change.

-Raj

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 27 Feb 2008 11:30:13 -0500

Peter,

       The point I am making is that, if  in the scenario when MAG does 
not change even if L2 link changes, then how many sub-functions of 
MN_ATTACH function should really be invoked. It is not required to go 
through all the sub-functions in that case. Do you think it would help 
to put some comment like that?

Thanks
Ashutosh

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 27 Feb 2008 11:47:24 -0500

Hi, Ashutosh,

Ashutosh Dutta wrote:
>> I think that's a matter for deployments to determine.  The MN-AR
>> draft just references DNA to say that the MN sends an RS whenever
>> the link changes.  Absent some link indication, there is really no
>> way for the MN to determine whether it is on a new MAG or the same
>> MAG - in fact the IP stack is fooled into thinking it is always the
>> same MAG while in the same NETLMM domain. 
>> 
> 
> Peter,
> 
>        The point I am making is that, if  in the scenario when MAG
> does not change even if L2 link changes, then how many sub-functions
> of MN_ATTACH function should really be invoked. It is not required to
> go through all the sub-functions in that case. Do you think it would
> help to put some comment like that?    

In fact right now the text says "whenever it attaches to a new MAG".
I'm not sure how the MN can really figure this out.  Maybe it should
say "whenever the link indicates that its attachment point has changed."
I think we need to execute all MN_ATTACH sub-functions when this
happens.

What do others think?

-Pete

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 27 Feb 2008 11:54:36 -0500

Hi Peter,

	I think you have asked the right question, which I failed to 
communicate properly. It is important to specify how the mobile can 
figure out that it is in fact under a new MAG and thus needs to start 
all the MN_ATTACH functions. Link layer layer change indication is not 
enough to determine that the MAG has in fact changed.

Thanks
Ashutosh

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 27 Feb 2008 11:11:15 -0600

Hi Pete,

    
> I think we need to execute all MN_ATTACH sub-functions when this

I agree with the proposed change. A link change may cause a MAG change and
hence the MN needs to perform the MAG change test with every link change.

-Raj

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 28 Feb 2008 09:47:28 -0500

Hi Raj, Pete,
              In addition to the proposed change, it may also be helpful 
to say few words about "how does MN perform MAG change test" or have a 
pointer to the "MAG change test" procedure.

Thanks
Ashutosh

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 28 Feb 2008 11:00:51 -0500

Hi, Ashutosh,

I don't think we need to tell the MN that the MAG changed.  While
the link layer might detect a going down / coming up event, the
whole idea is to fool the MN into thinking it hasn't moved.  This
is by advertising the same HNP in the RA delivered to the MN in
step REP1 of MAG_GET_MN_ID.

-Pete

Ashutosh Dutta wrote:
> Hi Raj, Pete,
>               In addition to the proposed change, it may also be
> helpful to say few words about "how does MN perform MAG change test"
> or have a pointer to the "MAG change test" procedure.  
> 
> Thanks
> Ashutosh
> 
> Basavaraj Patil wrote:
>> Hi Pete,
>> 
>>> say "whenever the link indicates that its attachment point has
>>> changed." I think we need to execute all MN_ATTACH sub-functions
>>> when this happens. 
>>> 
>>> What do others think?
>> 
>> I agree with the proposed change. A link change may cause a MAG
>> change 
>> and hence the MN needs to perform the MAG change test with every
>> link change. 
>> 
>> -Raj
>> 
>>> -Pete

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 28 Feb 2008 10:10:40 -0600

Pete,

The MN needs to know that the MAG changed because the default router setting
needs to be modified. So even though the MN receives the same HNP in the RA,
it does need to be aware of the change in the DR.
We are avoiding the MN configuring a different address by advertising the
same HNP but not necessarily MAG/DR change.

-Raj

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 28 Feb 2008 11:22:48 -0500

Hi, Raj,

Are you talking about the Link-layer Address option in the
Router Advertisement?  On an Ethernet link, this field would
indeed allow the MN to set the proper MAC address in its
next-hop table for the default router.

However, on a point-to-point link I believe this value will
be identical to the Interface Identifier (for example negotiated
during PPP) which happens also to be the lower 64 bits of the
link-local address.  We have already assumed in the base protocol
that all MAGs in a domain share the same link-local address.
Therefore, the Link-layer Address option should be set to the
same value throughout a netlmm domain.  I can't think of any
IP-layer parameters that would change when moving from MAG
to MAG within a single domain.

-Pete

Basavaraj Patil wrote:
> Pete,
> 
> The MN needs to know that the MAG changed because the default router
> setting needs to be modified. So even though the MN receives the same
> HNP in the RA, it does need to be aware of the change in the DR. We
> are avoiding the MN configuring a different address by advertising
> the same HNP but not necessarily MAG/DR change.   
> 
> -Raj
> 
> 
>> I don't think we need to tell the MN that the MAG changed.  While the
>> link layer might detect a going down / coming up event, the whole
>> idea is to fool the MN into thinking it hasn't moved.  This is by
>> advertising the same HNP in the RA delivered to the MN in step REP1
>> of MAG_GET_MN_ID. 
>> 
>> -Pete
>> 
>> Ashutosh Dutta wrote:
>>> Hi Raj, Pete,
>>>>> In fact right now the text says "whenever it attaches to a new
>>>>> MAG". I'm not sure how the MN can really figure this out.  Maybe
>>>>> it should say "whenever the link indicates that its attachment
>>>>> point has changed." I think we need to execute all MN_ATTACH
>>>>> sub-functions when this happens.
>>>>> 
>>>>> What do others think?
>>>> 
>>>> change and hence the MN needs to perform the MAG change test with
>>>> every link change. 
>>>> 
>>>> -Raj
>>>> 
>>>>> -Pete

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 28 Feb 2008 11:29:18 -0500

Hi Pete,
         I think we are discussing as to when to trigger MN_ATTACH 
function. Currently the text in the draft says,

6. MN_ATTACH Function

     The MN_ATTACH function is invoked by the MN whenever it attaches to a
     new MAG, and consists of the following sub-functions:

In order to support the above text, we need to know that the MAG the 
mobile is attaching to is the new MAG. Change in layer 2 event itself is 
not sufficient to prove that it is indeed attaching to a new MAG. Other 
option is to trigger MN_ATTACH function upon every layer 2 movement 
which is probably not optimized.

Alternatively, as Raj suggested, the mobile can send an RS upon L2 
change to trigger the generic RA (not the MN specific RA) that will 
determine if the MAG has actually changed or not. If the MAG has 
changed, then one can trigger MN_ATTACH function to do the rest of sub 
functions. But then there are other issues such as how to differentiate 
between generic RA and MN specific RA.

We probably need some clarification/discussion here?

Thanks
Ashutosh

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 28 Feb 2008 11:36:34 -0500

Hi, Ashutosh,

Ashutosh Dutta wrote:
>      The MN_ATTACH function is invoked by the MN whenever it attaches
>      to a new MAG, and consists of the following sub-functions:
> 
> mobile is attaching to is the new MAG. 

The proposal I made was to change this text to say 
"whenever the link indicates that its attachment point has changed."

> Change in layer 2 event itself
> is not sufficient to prove that it is indeed attaching to a new MAG.
> Other option is to trigger MN_ATTACH function upon every layer 2
> movement which is probably not optimized.    

I think it's the best we can do - the DNA protocol has to get
triggered whenever the link detects a change.

> changed, then one can trigger MN_ATTACH function to do the rest of
> sub functions. But then there are other issues such as how to
> differentiate between generic RA and MN specific RA.     

What do you mean by a "generic RA" vs. "MN specific RA"?  In my
understanding the RA sent by the MAG during step REP1 of MAG_GET_MN_ID
contains the individually assigned Home Network Prefix for the MN.

> We probably need some clarification/discussion here?

If you agree with the above points, I think the change I suggested
would be sufficient.  No?

-Pete

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 28 Feb 2008 17:58:44 +0100

Hi Pete, 

> We have already assumed in 
> the base protocol that all MAGs in a domain share the same 
> link-local address.

This is one of the options, the base protocol mentions other as well. This one doesn't work with SEND.

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of McCann Peter-A001034
> Sent: 28. veljaca 2008 17:23
> To: Patil, Basavaraj (NSN - US/Irving); Ashutosh Dutta
> Cc: [email-masked]
> Subject: Re: [netlmm] draft-ietf-netlmm-mn-ar-if-03.txt
> 
> Hi, Raj,
> 
> be identical to the Interface Identifier (for example 
> negotiated during PPP) which happens also to be the lower 64 
> bits of the link-local address.  We have already assumed in 
> the base protocol that all MAGs in a domain share the same 
> link-local address.
> IP-layer parameters that would change when moving from MAG to 
> MAG within a single domain.
> 
> -Pete
> 
> Basavaraj Patil wrote:
> > Pete,
> >

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 28 Feb 2008 12:08:20 -0500

Hi, Domagoj,

Ok, my mistake - maybe it isn't the only option in the base protocol.
However, it does seem to be explicitly assumed in Section 5 of the 
mn-ar draft:

>   A much simpler solution is:
>
>      All MAGs in a NETLMM domain MUST configure the same link-local
>      address.
>
>   When SEND is used, that means that all MAGs share a single SEND
>   public-private key pair, and hence a single link-local CGA.

-Pete

Premec, Domagoj wrote:
>> the base protocol that all MAGs in a domain share the same link-local
>> address.
> 
>> Sent: 28. veljaca 2008 17:23 To: Patil, Basavaraj (NSN - US/Irving);
>> Ashutosh Dutta 
>> Cc: [email-masked]
>> Are you talking about the Link-layer Address option in the Router
>> Advertisement?  On an Ethernet link, this field would indeed allow
>> the MN to set the proper MAC address in its next-hop table for the
>> default router. 
>> 
>> However, on a point-to-point link I believe this value will be
>> identical to the Interface Identifier (for example negotiated during
>> PPP) which happens also to be the lower 64 bits of the link-local
>> address.  We have already assumed in the base protocol that all MAGs
>> in a domain share the same link-local address.
>> Therefore, the Link-layer Address option should be set to the same
>> value throughout a netlmm domain.  I can't think of any IP-layer
>> parameters that would change when moving from MAG to MAG within a
>> single domain. 
>> 
>> -Pete
>> 
>> Basavaraj Patil wrote:
>>> Pete,
>>> 
>>> setting needs to be modified. So even though the MN receives the
>>> same HNP in the RA, it does need to be aware of the change in the
>>> DR. We are avoiding the MN configuring a different address by
>>> advertising the same HNP but not necessarily MAG/DR change.
>>> 
>>> -Raj
>>> 
>>> 
>>>> advertising the same HNP in the RA delivered to the MN in step
>>>> REP1 of MAG_GET_MN_ID. 
>>>> 
>>>> -Pete
>>>> 
>>>> Ashutosh Dutta wrote:
>>>>> Hi Raj, Pete,
>>>>> helpful to say few words about "how does MN perform MAG change
>>>>> test" or have a pointer to the "MAG change test" procedure.
>>>>> 
>>>>> Thanks
>>>>> Ashutosh
>>>>> 
>>>>> Basavaraj Patil wrote:
>>>>>> Hi Pete,
>>>>>> 
>>>>>> change and hence the MN needs to perform the MAG change test
>>>>>> with every link change. 
>>>>>> 
>>>>>> -Raj
>>>>>> 
>>>>>>> -Pete

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 28 Feb 2008 12:47:08 -0500

Hi Pete,
         In a regular (non-PMIP) environment, a router sends a generic 
RA that does not advertise HNP but subnet prefix.

Now in a regular deployment scenario, there will be hosts of both kinds. 
Thus a PMIP-enabled router (assuming MAG co-locates with the router) 
would need to be configured to send two RAs - the regular generic RA 
with subnet prefix and the MN specific RA with HNP (on demand).

Now, when a PMIP client gets these two RAs, it will need to 
differentiate one from the other and should not try to configure its 
address based on the generic RA. Prefix for generic RA has changed, but 
prefix for MN-specific RA (HNP) has not changed. Generic RA can still be 
used to differentiate if the MAG has  actually changed or not.

        We ran into this problem in the lab and thus have deactivated 
the generic RA from rad.conf file in the router (MAG) and issue *only* 
MN specific RA based on HNP upon attachment. This should not be a 
standard practice however. We also invoke PMIP procedure for every L2 
change, since we have different MAG for each L2 link change (it is also 
not the most ideal deployment scenario).

Please let me know if I am mis-understanding something here.

Thanks
Ashutosh

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 28 Feb 2008 13:02:58 -0500

Hi, Ashutosh,

I think the questions you raise have to do with PMIP interacting
with non-PMIP (client MIP?) access and need to be dealt with after
a recharter of the WG.

NETLMM assumes an un-modified host stack (albeit one that supports
standards such as DNA and SEND, if the capabilities are not available
from the link layer) therefore PMIP should be able to
support any mobile that attaches.  I guess I am saying that for
now, a PMIP domain should support PMIP for any mobile that wanders
into coverage.  There is no need to define a "non-PMIP host".

-Pete

Ashutosh Dutta wrote:
> Hi Pete,
>          In a regular (non-PMIP) environment, a router sends a
> generic RA that does not advertise HNP but subnet prefix. 
> 
> address based on the generic RA. Prefix for generic RA has changed,
> but prefix for MN-specific RA (HNP) has not changed. Generic RA can
> still be used to differentiate if the MAG has  actually changed or
> not.     
> 
> the generic RA from rad.conf file in the router (MAG) and issue
> *only* MN specific RA based on HNP upon attachment. This should not
> be a standard practice however. We also invoke PMIP procedure for
> every L2 change, since we have different MAG for each L2 link change
> (it is also not the most ideal deployment scenario).     
> 
>> understanding the RA sent by the MAG during step REP1 of
>> MAG_GET_MN_ID contains the individually assigned Home Network Prefix
>> for the MN. 
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 28 Feb 2008 10:38:46 -0800 (PST)

Hi Ashutosh/Pete,

I did not follow this thread completly. Couple of comments:

1. MN-AR link is a p2p link. There is an assumption that there
are only two nodes on the link, the MAG and the Mobile. This
is the case in all current SDO architectures. Now, w.r.t when
trying to emulate this using WiFI, the protocol requirements
do not change, we still need the RA's sent by the MAG to be
received by one and one node. We can unicast the RA's or as Julien
pointed out in the past, you can configure a shared 802.11 link
as a PMP link and this offers the p2p behaviour as required by
the protocol.

2. We do not mandadate a unique link-local address config on
every MN-AR link in a PMIP domain. This is one approach. But,
in access link where there is SEND is deployed, we have an issue
there, unless the trust anchor allows all the MAGs to be able to
send secured ND messages with the same identity (this is a more
SEND configuration issue).

3. We do not assume that PPP and specifically IPv6CP is always in
place. When IPv6CP is used, the identifiers can be negotiated by
both the peers. We have to operate in links where there is no PPP
or identifier negotiation is in place. In such configuration, the
peers detect the other node thru regular ND messages.

4. As far as I see, most configurations may as part of CT will move
the whole P2P link to a new MAG and with no topology change on the
link. The peer and the DR is the same and this is probably the best
approach as there will not by any latency related to a new DR
detection or for timing out the prev DR entry learnt on the prev
link.

Sri

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 28 Feb 2008 14:18:54 -0500

Thanks Sri for the clarification about the p2p link. I realize that PMIP 
for shared link is not in the charter yet.

I think I should clarify one more thing here.

  We have tried PMIP over WiFi (shared) and emulated PPP (PPPoE) 
environment. As
it appears, multiple RA problem needs to be addressed in a pure WiFi
(shared link environment) unlike point-to-point environment. In a pure
point-to-point environment, there is only one RA between the MAG and the 
mobile
over the point-to-point link that is triggered after the PPP link is 
established. In PMIP case, this RA uses HNP as the prefix.

Also, as it appears, in a pure point-to-point (e.g., PPP) deployment 
environment,
every L2 change warrants an establishment of a new point-to-point 
connection and
will result in a new MAG by default and thus warrants a new MN_attach 
procedure.

Is this assumption correct?

Thanks
Ashutosh

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 28 Feb 2008 11:41:50 -0800 (PST)

Hi Ashutosh,

On Thu, 28 Feb 2008, Ashutosh Dutta wrote:

> Thanks Sri for the clarification about the p2p link. I realize that PMIP for 
> shared link is not in the charter yet.
>
> We have tried PMIP over WiFi (shared) and emulated PPP (PPPoE) environment. 
> As
> every L2 change warrants an establishment of a new point-to-point connection 
> and

It depends on how this is implemented. If PPP context transfer scheme is
in place, the terminal should not detect a new MAG, as the entire link is
moved and the link-local identifiers both the peers remain the same and
so there is DR change. But, at each handoff if the P2P link is tore down
and re-established with the new MAG, the terminal may see a new DR (if
no group link-local address is used) and also the terminal needs to handle
this type of handoff in a special way.

Sri

>> > > > >  REP1
>> > > > > >  test"
>> > > > > > >  with

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 29 Feb 2008 22:15:17 +0900

Hi Sri and all,

> this type of handoff in a special way.

I think that it is better if the network can keep the PPP link on the MN 
side when it moves to a new MAG because some implementation breaks the 
session on the MN side if the PPP connection is terminated and 
re-established. Thus, it may not be a good idea to use PPP 
re-establishment as a trigger for MN_ATTACH.

Regards,
-- 
Hidetoshi

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 29 Feb 2008 22:25:54 +0900

Hi Pete,

I have another question about Section 6.2, which says:

"If the MAG knows that there was a previous session using a different 
ATT but the same MNIID, the MAG SHOULD set the HI field to 2 (Handoff
between two different interfaces of the mobile node)"

I thought if the two interfaces are different, the IIDs of them may also 
be different.

What do you think?

Regards,
-- 
Hidetoshi

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 29 Feb 2008 10:37:59 -0500

Hi, Hidetoshi,

I added this case to allow for handoff of a single NETLMM 
session between two interfaces of the same MN.  My assumption
is that if the MN is smart enough to re-use the MNIID across
two different interface technologies, it is probably asking
for the same session to be handed off.

However, I made all of these requirements a SHOULD because 
the MAG may have more specific information about the new
attachment and in that case it should be free to set the
HI as it sees fit.

This section is new text so I hope everyone reads it - I am
certainly open to suggestions/changes.

Thanks,

-Pete

Hidetoshi Yokota wrote:
> I thought if the two interfaces are different, the IIDs of them may
> also be different. 
> 
> What do you think?
> 
> Regards,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 29 Feb 2008 09:01:34 -0800 (PST)

Hi Yokota-san,

On Fri, 29 Feb 2008, Hidetoshi Yokota wrote:

> I think that it is better if the network can keep the PPP link on the MN side 
> when it moves to a new MAG because some implementation breaks the session on 
> the MN side if the PPP connection is terminated and re-established. Thus, it 
> may not be a good idea to use PPP re-establishment as a trigger for 
> MN_ATTACH.
>

Offcourse. As I said, if the PPP session is tore down and reestablished at
each handoff, the MN should "handle this type of handoff in a special
way". It requires the MN to retain the address configuration on the prev
PPP link till its moved to the new PPP interface. Requires some changes
on the host, as supposed to the other approach of PPP CT.

Sri