Subject: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 2

From: Jari Arkko <[email-masked]>
Date: Fri, 04 Jan 2008 00:14:33 +0100

This the second batch. While there have been issues in my review,
so far I have not found anything that would not be relatively easy
to fix. But there are issues that need to be addressed, and some
work is needed in revising the document.

I am currently somewhere in Section 6, and the next batch of comments
should arrive during the weekend.

Substantial:

> 4.   If the local mobility anchor determines that the mobile node is
>      not authorized for the network-based mobility management
>      service, it MUST reject the request and send a Proxy Binding
>      Acknowledgement message with Status field set to
>      PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).

Comment: This would imply that the LMA has an authorization
policy that allows only a particular set of mobile nodes to
receive this service. I did not see this requirement in
Section 4, but the edit that I suggested in batch 1 would
include this.

>    3.   If the local mobility anchor cannot authorize the mobile node
>         based on the Mobile Node Identifier option [RFC-4283] present in
>         the request, it MUST reject the Proxy Binding Update request and
>         send a Proxy Binding Acknowledgement message with Status field
>         set to 133 (Not home agent for this mobile node).
> 
>    4.   If the local mobility anchor determines that the mobile node is
>         not authorized for the network-based mobility management
>         service, it MUST reject the request and send a Proxy Binding
>         Acknowledgement message with Status field set to
>         PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
> 
>    ...
> 
>    6.   The local mobility anchor MUST authenticate the Proxy Binding
>         Update request as described in Section 4.0.  When IPsec is used
>         for message authentication, the SPI in the IPsec header [RFC-
>         4306] of the received packet is needed for locating the security
>         association, for authenticating the Proxy Binding Update
>         request.
> 
>    7.   The local mobility anchor MUST apply the required policy checks,
>         as explained in Section 4.0, to verify the sender is a trusted
>         mobile access gateway, authorized to send Proxy Binding Update
>         requests on behalf of this mobile node.
> 
>    8.   If the local mobility anchor determines that the requesting node
>         is not authorized to send Proxy Binding Update requests, it MUST
>         reject the request and send a Proxy Binding Acknowledgement
>         message with Status field set to
>         MAG_NOT_AUTHORIZED_FOR_PROXY_REG (Not authorized to send proxy
>         registrations).

I am confused about the order of checks chosen here. Steps 3 and 4
appear to be functionality specific to the contents of the MH message.
Why is this processing necessary before IPsec has even verified that
the packet is from a legitimate source? Architecturally, it would
be much better if all checks of this type could be placed at the
point the message is received in the daemon responsible for MH.

> 9.  If the Home Network Prefix option is not present in the Proxy
>     Binding Update request, the local mobility anchor MUST reject
>     the request and send a Proxy Binding Acknowledgement message
>     with Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION
>     (Missing mobile node's home network prefix option).

This seems inconsistent with Figure 2 that says the LMA allocate MN-HNP.
I realize that you later say 0::0 means "allocate a prefix". But this
is not clear for the reader at this point in the document -- even
if the reader skips ahead and looks at Section 8.3.

> In addition, during this MinDelayBeforeBCEDelete
> wait period, the local mobility anchor MUST continue to route the
> mobile node's data traffic.

You mean forward data traffic? If so, where? The only party interested
in it just declared it is no longer interested.

> 5.  If there exists a Binding Cache entry and if the Handoff
>     Indicator field in the Access Technology Type option present in
>     the received Proxy Binding Update message is set to value 4
>     (Handoff state unknown), the local mobility anchor SHOULD wait
>     till the existing Binding Cache entry is de-registered by the
>     previously serving mobile access gateway, before it assigns the
>     same home network prefix or updates the existing Binding Cache
>     entry.  However, if there is no de-registration message that is
>     received within MinDelayBeforeNewBCEAssign amount of time, the
>     local mobility anchor upon accepting the request MUST assign a
>     new home network prefix and create a new Binding Cache entry.
>     The local mobility anchor MAY also choose to assign a new home
>     network prefix and without waiting for a de-registration message.
>     It can use the access technology type value present in the
>     request and as inputs for this decision.

It is unclear where such waiting happens and what the implications
of this waiting are. Is there an interface somewhere where the mobile
node sends RSes to but fails to get an RA back before the decision
about the prefix allocation is done?

> In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
> on the access link connected to the mobile access gateway, but it is
> topologically anchored on the local mobility anchor.  Since there is
> no physical home-link for the mobile node's home network prefix on
> the local mobility anchor and as the mobile node is always on the
> link where the prefix is hosted, any prefix change messages can just
> be advertised by the mobile access gateway on the access link and
> thus there is no applicability of this message for Proxy Mobile IPv6.
> Hence, this specification does not support Mobile Prefix Discovery.

I agree that this spec should not support prefix discovery defined
in RFC 3775.

However, I'm not sure I agree with rationale as written above. Presumably
any prefix change would have to be agreed upon between the MAG and the
LMA. Otherwise they would not be in sync with regards to what prefix
is being used.

Suggest revising the text above.

Editorial:

> ... However, from the
> perspective of the mobile access gateway that sent the request,
> this binding re-registration request may be an initial Binding
> Update request after the mobile node's attachment to that mobile
> access gateway.
> 
>    Initial Binding Registration:

>From whose perspective should the rules following the last line
be followed?

>    Binding Re-Registration:
> 
>    1.  If the requesting prefix in the Home Network Prefix option is a
>        non 0::/0 value and is different from what is present in the

s/requesting/requested/?

>    Processing De-Registration Message:
> 
>    1.  ...
> 
> 
>    Home Network Prefix Option (Non-Zero Prefix) present in the request:

Overall, Section 5.4 was hard to read. For instance, are the items like the
last one above something that applies for processing de-reg messages or
any messages?

Also, this section fails to explain the reasons why multihoming needs
special considerations and proceeds to describe detailed rules without
giving a rationale for them.

I am still wondering whether a different choice of identifier for the
mobile node/interface would have provided exactly the same functionality
but with simpler and more understandable processing rules.

Jari

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 Jan 2008 17:03:05 -0800

Hi Jari,
 
Please see inline.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, January 03, 2008 3:15 PM
> To: [email-masked]; [email-masked]
> Subject: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 2
> 

Ok. It can be explicitly stated about this requirement.

> Why is this processing necessary before IPsec has even verified that

I agree. This is wrong. IPsec related checks need to be before this.

> point the message is received in the daemon responsible for MH.

Sure. This specified checks can be enforced right at the point the
MH packet is received by a given entity. Not sure, if you are suggesting
we do it differently ?

> if the reader skips ahead and looks at Section 8.3.

There are two possibilities here:

a) The absence of a mandatory HNP option
b) The content in the option (0::0/64 or a specific prefic cafe::/64)

The above specified rule is for handling Case #a. 

Let us know, if the text needs to be reworked.

> in it just declared it is no longer interested.

This is a good point. But, we should some how control this
behavior on what the LMA should do with the traffic. Drop
or forward to old MAG (that is not interested in the traffic).
We can certainly specify that the LMA should drop the traffic,
but, I wonder if FMIP type of mechanisms are applied later, if
dropping the packets will be a good idea. How about we define
a protocol variable for controlling this behavior and with the
default value of forward. The logic behind keeping the old data
path active is that the BCE is still valid.

> about the prefix allocation is done?

The MAG is required to advertise the prefix only after completing the
signaling with the LMA. During this wait period, the RS's from the
MN will not result in RA containing the HNP. The MAG will send the
RA containing the HNP only after a successful signaling completion.
But, there can be an RA from the MAG with no HNP option.

> LMA. Otherwise they would not be in sync with regards to what prefix

Ok. Makes sense. We can reword it.

>From the LMA perspective:

- it is an Initial Binding Registration, if the Binding Cache entry
  existence test finds no BCE entry that can be associated with that
  request

- it is an Re-Registration, if the Binding Cache entry existence test
  find a BCE entry that the PBU can be associated with. This re-registration
  from a nMAG perspective may be an initial registration, that may be
  the reason for confusion.

> >        non 0::/0 value and is different from what is present in the

Ok

> giving a rationale for them.

If we look at it bit differently, the multihoming section is primarily
a set of rules for doing a Binding Cache entry existence test. Given a
PBU for a specific MN-ID, how we associate the request for a MN over
a given access tech to an existing BCE or decide to allocate a new BCE
entry.
Logically, they are one group of rules. I agree that processing rules
are bit to hard to read, but there are simply too many combinations,
new MAG, old MAG, multi-homing, timestamp ... the nature of the problem
in PMIP is bit different, when compared to MIP6 signaling.

> but with simpler and more understandable processing rules.

Mandatory IID would have made the rules bit more easier. But, we cant
generate that all the time. If IID generation is not the issue, we
can reduce few processing rules.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 3 Jan 2008 19:21:20 -0800 (PST)

>> but with simpler and more understandable processing rules.

Thinking a bit more on this. Most of these processing rules
are for multi-homing. We introduced the IID in addition to
the Access Tech type option and I think that was, IMO, not
required. Just the ATT is sufficient and that will eliminate
many processing rules. Because, we are not affectively using
the access technology type for BCE lookup.

Our argument that there could be multiple radios of the same
type and each of them will connect to a different MAG may not
be practical. Typically, it not possible to qualify a device
with FCC or other regulatory body, for two collocated radios
of same access technology. AFAIK, there is a 20 cm seperation
rule that is required for similar type radio collocation. We
cannot use the two port USB example to imply one would collocate
two 802.11 radios side by side. Even though an end user can
plugin two similar radios in a those two USB slots, side-by-side,
that configuration will not qualified by any operator as there
will be interference and affectively an radio link.

So, we now have the IID, ATT and HNP. If we can eliminate the
IID and use the ATT as the interface identifier, we can get
rid of few processing rules and can make this much better.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 04 Jan 2008 15:50:36 -0800

> Let us know, if the text needs to be reworked.

We should re-word the above paragraph as follows.

  9.   If the Home Network Prefix mobility option, either with a valid
       prefix or a request for the prefix, is not present in the Proxy
       Binding Update, the local mobility anchor MUST reject the request
       and send a Proxy Binding Acknowledgement message with Status field
       set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's
       home network prefix option).

This would make it clear that the LMA is always expecting the
mobility option to be always there in the proxy BU.

> dropping the packets will be a good idea. 

Even if FMIPv6 if used with PMIPv6, the old MAG would not send a
de-registration proxy BU as long as it receives a HI from the new
MAG. As long as the old MAG is aware that it should be tunneling
the packets to the new MAG, it won't be de-registering with the
LMA.

draft-yokota-mipshop-pfmipv6-01.txt does not seem to cover this
case. It does not show the PMAG sending a de-registration proxy
BU to the LMA in figure 3.

> How about we define

IMO, the LMA should be just dropping the packets if there is
nowhere it can forward the packets to.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 4 Jan 2008 16:20:20 -0800 (PST)

> nowhere it can forward the packets to.

MAG sent the de-reg, LMA did not Ack it yet and has a valid
binding state. From the LMA point of view, the data path should
still be active as long as the BCE is active.

>From MAG point of view, it requested for a dereg, but during this
period, it should really route the traffic, atleast till it
receives the PBA or terminates the state for the attached MN.

This is for a transient period of time. I wonder, if its not ok
to forward the traffic till it sends the PBA, rather than dropping
the traffic. Given the discussions in SDO bodies related to early/late
switching, I feel its probably better to define a variable and
leave some flexibility, as there is no interop issue.

But, I'm ok either way.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 04 Jan 2008 16:31:50 -0800

> receives the PBA or terminates the state for the attached MN.

If the MAG did not receive a Proxy BAck in response to the
de-registration PBU, it would send the PBU again. it would keep
sending the PBU until the LMA sends a Proxy BAck.

My understanding is that the LMA responds immediately with a PBAck
when it receives a de-registration PBU, but still keeps the BCE
around for MinDelayBeforeBCEDelete milliseconds.

> to forward the traffic till it sends the PBA, 

The PBAack would be sent immediately. Right?

Vijay

rather than dropping

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 4 Jan 2008 16:39:44 -0800 (PST)

> around for MinDelayBeforeBCEDelete milliseconds.

This is in the context of Multihoming. When the HI hint is set to
Unknown, IID is not present, the LMA must decide if it should
allocate the same or a new prefix. It can send the PBA after
waiting for the dereg is complete, as the PBA has the HNP option.
So, we cant send the PBA right away for this specific case.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 04 Jan 2008 16:55:43 -0800

Sri Gundavelli wrote:
> This is in the context of Multihoming. 

This is not correct. Irrespective of the scenario, the LMA always
responds with a PBAck immediately. It does not delay the PBAck. It
might hold onto the BCE for a while longer, but that is not the
same as delaying the PBAck.

 > When the HI hint is set to

But here the LMA needs to check if it receives a de-registration
proxy BU within the MinDelayBeforeNewBCEAssign period from the
old MAG. It it does, it assigns the same prefix again. If not,
it assigns a new prefix. See bullet 5 on page 26.

Why is the MinDelayBeforeBCEDelete relevant here? Why does the
LMA have to wait for MinDelayBeforeBCEDelete before sending a
PBAck?

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 4 Jan 2008 17:17:46 -0800 (PST)

> LMA have to wait for MinDelayBeforeBCEDelete before sending a

This is the the conclusion from the MH discussion. If the HI is
unknown to the LMA, it can CHOOSE to wait for a dereg message
from the current MAG, before it decides to assign a new prefix.
We cannot just send the PBA right away. The wait is for allowing
the LMA to recv the dereg from the prev MAG. If the LMA has to
send the PBA right away, it has to allocate a new prefix, killing
the session or assign the same prefix assigned to a different
interface. This PBA even though delayed, will ensure we handle
the case correctly. Any case, this is truely a corner case of
HI=Unknown, No IID, the theoritical case of a multi-homed terminal
in PMIP domain ..etc.

Sri

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 15:50:33 +0200

> MH packet is received by a given entity. Not sure, if you are suggesting

The current order has to be changed, but I think we agree on what the
order should be. Do not place mobile IP "application" level logic before
the lower level operations such as IPsec have been completed.

> Let us know, if the text needs to be reworked.

I think the current approach is fine (0::0 means asking for a prefix).
However,
for clarity you should point that out already here.

> mobility option to be always there in the proxy BU. 

This is fine with me.

> path active is that the BCE is still valid.

Lets leave the FMIP-for-NETLMM behaviour to the next spec.

So I think for now we're simply dropping the traffic. You may want
to think about things like how fast a MAG will be responding with
ICMP errors if it still gets packets to the node...

>From your discussion with Vijay:

If the MAG decided to ask for dereg, the mobile node and associated
interface has gone away. There's really no forwarding that we can
do.

>>>     network prefix and without waiting for a 
>>>       
>> de-registration message.
>>     

Ok, later parts of the document talked clearly about this.

> can reduce few processing rules.

Maybe you can, if you allow some link types to provide an empty string
as an IID.

> rid of few processing rules and can make this much better. 

I'm not sure this is sufficient. The IIDs are there to handle what IMHO
is going to be a configuration that we will see in the future: NETLMM
on a WLAN. If we do not recognize MAC instances, someone will have
a laptop with two WLAN cards and its going to not work when it
attaches to a NETLMM domain.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 13:55:11 -0800

> interface has gone away. There's really no forwarding that we can

Agree. Sri, I think we should specify that the LMA would just drop
the packets in this case.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 Jan 2008 00:30:52 -0800

Hi Jari,

Please see inline ...

> Sent: Monday, January 14, 2008 5:51 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] AD review of 
> draft-ietf-netlmm-proxymip6, batch 2
> 

Ok.

> for clarity you should point that out already here.

Its specified, will ensure its clear.

> > mobility option to be always there in the proxy BU. 

Before I make this change, I just want to be sure, if the line
"If the Home Network Prefix option is not present in the PBU",
may confuse some people to believe this is for the case, where the
prefix value is 0::/0 in the request. If this is confusing, we can
add that extra note.

> interface has gone away. There's really no forwarding that we can

Ok. How about we leave it with a SHOULD clause, as there will be no
interop issues.

> Maybe you can, if you allow some link types to provide an empty string

I assume you mean "empty string" to imply, a MAG generated string for
a given MN's interface. So, this needs to be moved between MAG's as
part of CT, may be as well use HNP for the session identification in
addition to MN-Id. We endup with this new requirement for the nMAG to
know about the HNP/IID, versus more process rules.

> attaches to a NETLMM domain.

Ok. Now that we have IID/ATT, may be we can support this configuration.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 13:15:32 +0200

Sri,

> prefix value is 0::/0 in the request. If this is confusing, we can

I think it is fairly clear, but you could also say "... If the Home
Network Prefix mobility option (containing either 0::0 or a valid
prefix) is not present ..."

> Ok. How about we leave it with a SHOULD clause, as there will be no

This is fine. I.e., SHOULD drop. Then implementations that know better might
do something more reasonable.

> know about the HNP/IID, versus more process rules.

I'm not sure I understand. What I meant that if there is some link layer
which does not have an interface identifier, then all equipment using
that technology would set ATT = that technology and IID = empty string.
This requires no context transfer.

But I'm not wedded to the idea of using the empty string. What I want is
a clear definition of how BCEs are indexed.

> Ok. Now that we have IID/ATT, may be we can support this configuration.

You have to. NETLMM is not allowed to break existing functionality in
unmodified hosts (even in an admittedly relatively rare case).

Jari

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Jan 2008 17:24:48 +0200

One comment on consolidating P-MIPv6's multi-homing operation:

Jari Arkko wrote:
> I'm not sure I understand. What I meant that if there is some link
> layer which does not have an interface identifier, then all equipment
> using that technology would set ATT = that technology and IID = empty
> string. This requires no context transfer.

An alternative to using an empty string as the IID is to assign the IID
a value that represents the ATT when there is no native IID.  This makes
the explicit ATT message field dispensable and thus helps to consolidate
protocol operation.

Overloading the ATT onto the IID is feasible because the ATT is needed
-- as per section 5.4 of the P-MIPv6 spec -- only when the old MAG
cannot provide an IID (bullet 5, page 26).

In deployments where hosts are known to have at most one interface per
technology, overloading the ATT onto the IID will, in the context of a
specific mobile-host ID, result in a pseudo-IID.  The pseudo-IID can be
handled by the protocol in the same way as a native IID.  In deployments
where hosts may have more than one interface per technology, the ATT is
useless to begin with.

- Christian

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jan 2008 09:19:44 -0800 (PST)

Hi Jari,

Ok

> This requires no context transfer.

In this scenario, we may have to deal with multiple interfaces of
the same ATT. If there are multiple BCE's for the same MN-Id and
with the same ATT, when the LMA receives a PBU, with HNP=::/0,
IID=Empty, HI=Handoff, we have to provide some way to identify the
right BCE. So, not sure, if we can eliminate the current processing
rules when IID is empty, as its the case of no IID.

Ok

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jan 2008 09:34:50 -0800 (PST)

Hi Christian,

> the explicit ATT message field dispensable and thus helps to consolidate

But, I guess, we still would need the ATT as the comment IID
collision across interfaces, as Jari pointed out. Also, we
have the Handover hint in the ATT option. So, we would need
that option any case.

> where hosts may have more than one interface per technology, the ATT is

The issue with psuedo IID is that, the generation should be
predictable and any entity should be able to do that. If
its not predictable and requires the old MAG to pass it to
the new MAG, we can as well depend on the HNP.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Jan 2008 21:09:54 +0200

Hi Sri -

> have the Handover hint in the ATT option. So, we would need

Note that IID collisions are a problem only if the colliding interfaces
belong to the same mobile host.  This is so because an IID is always
used in conjunction with a mobile-host ID.  This collision probability
is exceedingly small, and I believe it can be ignored.

Regarding the handover hint:  It shouldn't be difficult to move this
into a separate option in case we conclude that we can do without an
explicit ATT field.

> the new MAG, we can as well depend on the HNP.

Since the pseudo-IID would be a constant, access-technology-specific
value, it would be predictable and not require context transfer.

Specifically, each MAG (and possibly each LMA) would store a copy of a
constant, well-known list of access technology indexes, to be used as
pseudo IIDs for interfaces that do not have a native IID.

- Christian

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jan 2008 11:31:42 -0800 (PST)

Hi Christian,

> into a separate option in case we conclude that we can do without an

Renaming the option and removing the ATT is not an issue. I prefer
retaining the ATT as supposed to adding the psuedo IID generation
logic. The other consideration for the end-points to use the ATT
for other purposes, given that such options are being propsed in
MIP6. It might be cleaner to keep both IID and ATT as supposed
to eliminating one. Offcourse, we need to be crystal clear on the
usage.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Jan 2008 21:53:05 +0200

Sri -

> to eliminating one. Offcourse, we need to be crystal clear on the

If the main function of the ATT ends up being "other purposes", then the
ATT should IMO be decoupled from the base binding update procedure.

Even in the current spec, the ATT is only used when neither an IID nor a
handover hint is given, and even then it is up to the LMA whether or not
to look at it.  So we should seriously consider leaving the use of the
ATT up to the deployment -- by moving the handover hint into a separate
option, and making the ATT option itself optional.  (Sounds funny.  Once
upon a time, the definition of "option" implied that the option couldn't
be mandatory in the first place, but anyway...)

- Christian

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 15 Jan 2008 12:01:04 -0800 (PST)

> be mandatory in the first place, but anyway...)

True, its hardly used in BCE lookup procedure for now. So it is
some what decoupled. Renaming the ATT with HI and still carrying the
ATT is one option, as HI is mandatory and overloading it with
additional info is not an issue and with the possibility "Unknown"
ATT value, versus one more option.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Jan 2008 22:07:24 +0200

Sri -

> ATT value, versus one more option.

Right.  I recommend separate options given that PBUs will frequently
need only the HI value.

- Christian

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jan 2008 14:14:29 -0800

I like the idea of separating the Access technology type and
Handover indication information into two separate mobility
options.

Now it would be the Handover Indication option that would be
mandatory to appear in the first Proxy BU from a MAG. Right?

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 16 Jan 2008 14:19:03 -0800 (PST)

Lets make the ATT optional as we dont need it primarily for
BCE association, as Christian suggested. The HI option is
mandatory in all cases first PBU or second PBU. Its not worth
making this mandatory for the first PBU, it wiil introduce
more processing checks.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Jan 2008 14:19:59 -0800

> making this mandatory for the first PBU, it wiil introduce

Agree. What I meant was that in the current draft the Access
Technology Type option is mandatory. Now it would be the
Handover Indication option.

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Thu, 17 Jan 2008 10:11:12 +0200

Vijay -

> mandatory to appear in the first Proxy BU from a MAG. Right?

Yes, that's right.

Alternatively, we could make the Handover Indication option optional and
define the absence of it to mean "handoff state unknown" -- i.e., what
is currently meant by value 4 in the Handover Indication field.

- Christian

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 17 Jan 2008 03:50:25 -0600

Sri,

> to eliminating one. Offcourse, we need to be crystal clear on the

An example of the usefulness of the ATT option is in deployments for
obtaining the appropriate AAA parameters. Depending on the access technology
that the MN is attached to, different parameters from AAA may be required.
Hence this indication is useful.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 17 Jan 2008 04:10:07 -0600

Christian,

> pseudo IIDs for interfaces that do not have a native IID.

I don't know how this solves the problem regarding the IID duplication. The
IID is expected to be unique. If the MN does not have an IID (on certain
access links), I don't believe the MAG should be generating a pseudo IID for
that MN. 

-Raj

---

From: Christian Vogt <[email-masked]>
Date: Thu, 17 Jan 2008 12:46:56 +0200

Raj -

> access links), I don't believe the MAG should be generating a pseudo IID for

As per the P-MIPv6 spec, an IID is always used in combination with a
mobile-host ID.  The pseudo IID thus uniquely identifies an interface.

The assumption here is that mobile hosts have at most one interface per
access technology.  This assumption is IMO feasible because, for the
only case where we need the pseudo IID -- page 26, bullet 5 --, the
current P-MIPv6 spec is based on the very same assumption.

- Christian

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 09:20:07 -0800 (PST)

> Hence this indication is useful.

Hi Raj,

We just split the ATT from HI option to make it cleaner. ATT is
not currently used in the session identification logic and so
its optional.

Sri

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Jan 2008 16:58:27 +0200

>
>> Lets make the ATT optional
I like the separation of the various information items to their own options.

However, while likelihood of an IID collision is almost non existent, I
think it would be good design hygiene to compare values only if they are
from the same name space. That is, I think we need the ATT for
disambiguating IIDs from different access technologies.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 25 Jan 2008 12:41:31 -0600

Hello Folks,

Currently MEXT wg is considering Binding Revocation for IPv6 Mobility as
an item for their re-chartering activity. The following is the proposed
text for this recharter item:

"
Binding Revocation for IP Mobility:
===================================

Define a binding revocation mechanism for Mobile IPv6 and its
extensions.  This mechanism can be used by any entity involved in the
base Mobile IPv6 protocol or one of its extensions to request its
corresponding entity to terminate either one, multiple or all binding
cache entries.
"

As it is obvious, Binding Revocation has a strong usecase and
applicability to PMIPv6 and since the PMIPv6 base protocol document is
in a very good shape and passed AD review and hopefully after a short
time will be sent to IESG, I thought it is appropriate if we can start
discussing the PMIPv6 usecase and requirements to Binding Revocation.
This is important in order to make sure that all PMIPv6 usecases and
requirements are covered by this MEXT work item.

I really appreciate your comments and discussion on this topic. 

The following IETF draft is not a MEXT wg work item, however, has been
presented during Chicago MIP6 and Vancouver MEXT meetings and have been
discussed extensively on the MIP6 mailing list.

http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio
n-02.txt

Please note that I am ccing MEXT wg mailing list too.

Best Regards,
Ahmad