Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA too, not only by CN

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Dec 2007 15:17:05 +0100

Section 4, subsection 4.2, 5th and 6th paragraphs.

OLD TEXT:
>    Binding Refresh Request
> 
>       A Binding Refresh Request is used by a correspondent node to
>       request a mobile node to re-establish its binding with the
>       correspondent node.  This message is typically used when the
>       cached binding is in active use but the binding's lifetime is
>       close to expiration.  The correspondent node may use, for
>       instance, recent traffic and open transport layer connections as
>       an indication of active use.
> 
>    Binding Error
> 
>       The Binding Error is used by the correspondent node to signal an
>       error related to mobility, such as an inappropriate attempt to use
>       the Home Address destination option without an existing binding.

NEW TEXT:
>    Binding Refresh Request
> 
>       A Binding Refresh Request is used by a correspondent node or the home agent to
>       request a mobile node to re-establish its binding with the
>       correspondent node.  This message is typically used when the
>       cached binding is in active use but the binding's lifetime is
>       close to expiration.  The correspondent node or the home agent may use, for
>       instance, recent traffic and open transport layer connections as
>       an indication of active use.
> 
>    Binding Error
> 
>       The Binding Error is used by the correspondent node or the home agent to signal an
>       error related to mobility, such as an inappropriate attempt to use
>       the Home Address destination option without an existing binding.
> 

Even though RFC3775 states at some point that a CN can be a HA, it is 
unclear when implementing whether a HA should implement sending BRR or 
BErr to the MN or not.  Some people have implemented this as yes, HA 
should send BErr and BRR to MN.  This has been discussed in the past on 
the mip6 mailing list.  Note that the disambiguation proposed above may 
be needed in some other parts of the document as well.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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

---

From: Brian Haley <[email-masked]>
Date: Wed, 12 Dec 2007 11:18:55 -0500

Hi Alex,

>>       an indication of active use.

You missed one CN -> CN or HA at the end of the first sentence, I think 
changing it to "it" is fine:

     Binding Refresh Request

        A Binding Refresh Request is used by a correspondent node or home
        agent to request a mobile node to re-establish its binding with
        it.  This message is typically used when the cached binding is in
        active use but the binding's lifetime is close to expiration
        The correspondent node or the home agent may use, for instance,
        recent traffic and open transport layer connections as an
        indication of active use.

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Dec 2007 02:20:58 -0600

Hi Alex,

Somehow I missed this posting; 
My understanding, as per the chairs decision, RFC3775bis is a minor
revision to fix known and reported errors. However, this is a protocol
extension and change which is not within the scope of RFC3775bis.

Thanks.

Regards,
Ahmad

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, December 12, 2007 8:17 AM
> To: [email-masked]
> Subject: [MEXT] [RFC3775 changes] BRR, BErr are sent by HA 
> too, not only by CN
> 
> Even though RFC3775 states at some point that a CN can be a 
> HA, it is unclear when implementing whether a HA should 
> implement sending BRR or BErr to the MN or not.  Some people 
> have implemented this as yes, HA should send BErr and BRR to 
> MN.  This has been discussed in the past on the mip6 mailing 
> list.  Note that the disambiguation proposed above may be 
> needed in some other parts of the document as well.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Dec 2007 11:13:04 +0100

> extension and change which is not within the scope of RFC3775bis.

Hi Ahmad, indeed posts get missed sometimes.

The BRR/BErr being sent by HA (in addition to CN) is a necessary 
disambigation, has been discussed in the past:
-rfc3775 mentions at some point that "CN" is any correspondent to the
  MN, and HA is a "CN" in this sense.
-some implementations have already implemented HA to send BRR and BErr.
-this is more of a textual clarification and less to none new protocol
  to write.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Dec 2007 07:53:42 -0600

> Subject: Re: [MEXT] [RFC3775 changes] BRR, BErr are sent by 
> HA too, not only by CN
> 
> Ahmad Muhanna wrote:
> > Hi Alex,
> > 
> The BRR/BErr being sent by HA (in addition to CN) is a 
> necessary disambigation, has been discussed in the past:

Hi Alex,
The fact that some already implemented this message does not
automatically make it part of this standard. I would say that is their
own reading of the spec. The point we are discussing here is not the
applicability of the message. It is the scope of the changes of
RFC3775bis, which, is limited to capture and fix minor errors. NOT to
introduce new functionalities.

Best Regards,
Ahmad 

> too, not 
> >> only by CN
> >> unclear when implementing whether a HA should implement 
> sending BRR 
> >> or BErr to the MN or not.  Some people have implemented 
> this as yes, 
> >> HA should send BErr and BRR to MN.  This has been discussed in the 
> >> past on the mip6 mailing list.  Note that the 
> disambiguation proposed 
> >> above may be needed in some other parts of the document as well.
> >>
> >> Alex
> >>
> >>
> >> 
> _____________________________________________________________________
> >> _ This email has been scanned by the MessageLabs Email Security 
> >> System.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Dec 2007 14:56:35 +0100

> introduce new functionalities.

Ahmad - what do you think - should the HA send BErr/BRR?  OR should it not?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Dec 2007 08:00:32 -0600

> Ahmad - what do you think - should the HA send BErr/BRR?  OR 

[Ahmad]
Hi Alex,
That is a different topic which is not withing the scope of the current
thread.

Regards,
Ahmad

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Dec 2007 15:25:52 +0100

Ahmad Muhanna wrote:
>>>> Ahmad Muhanna wrote:
>>>>> Hi Alex,
>>>>> 
>>>>> Somehow I missed this posting; My understanding, as per the
>>>>> chairs decision, RFC3775bis is a minor revision to fix known
>>>>> and reported errors. However, this is a protocol extension
>>>>> and change which is not within the scope of RFC3775bis.
>>>> 
>>>> -rfc3775 mentions at some point that "CN" is any correspondent
>>>> to the MN, and HA is a "CN" in this sense. -some
>>>> implementations have already implemented HA to send BRR and 
>>>> BErr. -this is more of a textual clarification and less to none
>>>>  new protocol to write.
>>> 
>>> Hi Alex, The fact that some already implemented this message does
>>> not automatically make it part of this standard. I would say that
>>> is their own reading of the spec. The point we are discussing
>>> here is not the applicability of the message. It is the scope of
>>> the changes of RFC3775bis, which, is limited to capture and fix
>>> minor errors. NOT to introduce new functionalities.
> [Ahmad] Hi Alex, That is a different topic which is not withing the
> scope of the current thread.

Ahmad, you could give a technical oppinion on HA sending BRR/BErr 
discussion.  Until then I consider your oppinion to be administratively 
related to the scope of 3775bis, and not technical.

Thus I change the subject to 'Scope of 3775bis' - what do you think this 
scope should be?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Dec 2007 10:35:12 -0600

> 
> Ahmad Muhanna wrote:
> >>>> Ahmad Muhanna wrote:
> >>>>> Hi Alex,
> >>>>> 
> >>>>> Somehow I missed this posting; My understanding, as per 
> the chairs 
> >>>>> decision, RFC3775bis is a minor revision to fix known 
> and reported 
> >>>>> errors. However, this is a protocol extension and 
> change which is 
> >>>>> not within the scope of RFC3775bis.
> >>>> 
> >>>> -rfc3775 mentions at some point that "CN" is any 
> correspondent to 
> >>>> the MN, and HA is a "CN" in this sense. -some 
> implementations have 
> >>>> already implemented HA to send BRR and BErr. -this is more of a 
> >>>> textual clarification and less to none  new protocol to write.
> >>> 
> >>> not automatically make it part of this standard. I would 
> say that is 
> >>> their own reading of the spec. The point we are 
> discussing here is 
> >>> not the applicability of the message. It is the scope of 
> the changes 
> >>> of RFC3775bis, which, is limited to capture and fix minor errors. 
> >>> NOT to introduce new functionalities.
> >> Ahmad - what do you think - should the HA send BErr/BRR?  
> OR should 
> >> it not?
> > 
> Ahmad, you could give a technical oppinion on HA sending 
> BRR/BErr discussion.  Until then I consider your oppinion to 
> be administratively related to the scope of 3775bis, and not 
> technical.
> 
> Thus I change the subject to 'Scope of 3775bis' - what do you 
> think this scope should be?

[Ahmad]
Hi Alex,
The proposed changes is a new functionality that it is not withing the
scope of RFC3775bis and also requires new software update on the HA.

On the other hand, I changed the subject again to read as "Applicability
of sending BRR, BErr by the HA?" 

IMO, you need to separate these two messages (BRR and BErr) and they
need to be discussed separately.

Case of BRR message:
====================

I believe the intention of RFC3775 is to restrict the use of this
message to the CN ONLY. IMO, it is quite clear that within the scope of
RFC3775, this message is not applicable to the HA. For the following
reasons:

1. RFC3775 defines a protocol to enable a mobile node to register its
CoA in a foreign network with its home agent in order to be reachable at
its home address. i.e. create a binding for the MN CoA and its HoA at
the Home Agent.

2. RFC3775 developed a mechanism for the MN to refresh its BCE, i.e.
RFC3775 defined a field in BA which is called lifetime. This field
indicates to the MN the approved lifetime that the Home Agent agreed to
honor while offering mobility services to the MN and at the same time
maintain a BCE for the MN CoA and HoA.

3. In the contents of RFC3775 the mobile node is quite aware that
without maintaining a current BCE at its Home agent, i.e. the basic
fundamental functionality of MIPv6, the Mobile node will loose all of
its mobility services and its reachability at the foreign network using
its HoA.

4. RFC3775 specify that the MN needs to send a new BU message in order
to refresh or extend the BCE lifetime. This is extremely important
because a node like the HA, does not need to send a reminder to every
single MN that it serves and maintains a BCE for.

5. If the HA needs to send a reminder to every MN about the expiry of
its BCE, then we are introducing a new functionality which violates the
basic RFC3775 functionality and a non sense complexity that absolutely
is not necessary and not within the original intention of RFC3775.

6. On the other hand, CN maintains a limited number of BCE for specific
mobile nodes and more importantly if the MN decides NOT to renew its BCE
with a specific CN, the MN continues to be reachable by other CNs at its
HoA and CoA via its Home Agent BCE. In other words, a MN binding with
another CN represent the service (RO) between MN<->CN ONLY, however, in
the case of HA it represents the MN's MIP6 service and access to the
whole internet. Which also administratively governed. i.e. if the MN
does not renew its BCE, then that is a clear indication for the HA to
delete the MN BCE.

7. Finally, the fact that RFC3775 mentions that CN could be a HA, does
not mean that the HA application at such a node need to support BRR.
IMO, such a node could act as a CN for some MNs and a HA for others.
Then, it is normal for this CN/HA node to support BRR for those MN which
is serving as a CN but not a HA.

Best Regards,
Ahmad

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Dec 2007 17:47:16 +0100

Hi Ahmad, I've changed the topic.  Please make another thread, if you
wish, about applicability and scope.

Ahmad Muhanna wrote:
[...]
> [Ahmad] Hi Alex, The proposed changes is a new functionality that it 
> is not withing the scope of RFC3775bis and also requires new software
>  update on the HA.
> 
> On the other hand, I changed the subject again to read as 
> "Applicability of sending BRR, BErr by the HA?"
> 
> Case of BRR message: ====================
[...]
> 4. RFC3775 specify that the MN needs to send a new BU message in 
> order to refresh or extend the BCE lifetime. This is extremely 
> important because a node like the HA, does not need to send a 
> reminder to every single MN that it serves and maintains a BCE for.

Right.

>  its BCE, then we are introducing a new functionality which violates 
> the basic RFC3775 functionality and a non sense complexity that 
> absolutely is not necessary and not within the original intention of 
> RFC3775.

In what does that HA-sends-BRR functionality violate the basic 3775?
What does it break?

I see it offering better reliability: even if the critical BU is lost
the HA requests the BU anew (BRR) and thus reduces the non-bound time
from the entire lifetime to much less.

> 6. On the other hand, CN maintains a limited number of BCE for 
> specific mobile nodes and more importantly if the MN decides NOT to 
> renew its BCE with a specific CN, the MN continues to be reachable by
>  other CNs at its HoA and CoA via its Home Agent BCE. In other words,
>  a MN binding with another CN represent the service (RO) between 
> MN<->CN ONLY, however, in the case of HA it represents the MN's MIP6 
> service and access to the whole internet. Which also administratively
>  governed. i.e. if the MN does not renew its BCE, then that is a
> clear indication for the HA to delete the MN BCE.

Not before it sends a BRR and waits for an answer to that.

> 7. Finally, the fact that RFC3775 mentions that CN could be a HA, 
> does not mean that the HA application at such a node need to support 
> BRR.

That's your reading.  Other implementers read it in the way I said.

>  Then, it is normal for this CN/HA node to support BRR for those MN 
> which is serving as a CN but not a HA.

Is a HA a "CN" when it is the dst field of the BU?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 21 Dec 2007 11:59:06 -0600

> 
> Hi Ahmad, I've changed the topic.  Please make another 
> thread, if you wish, about applicability and scope.
> 
> Ahmad Muhanna wrote:
> [...]

[Ahmad]
Okay, then RFC3775 has a mechanism already specified for updating the MN
BCE at its HA, why do we need another new functionality which, IMO, does
not scale and may cause a huge problem for the HA?

> In what does that HA-sends-BRR functionality violate the basic 3775?

[Ahmad]
I am not sure if what does break is the right question here. 
It is a new functionality which is fundamentally in conflict with the
original RFC3775 intention of how MIP6 BCE is managed at the HA.
However, let me explain what could happen in case that the HA implements
this new weird functionality:

1. Some of the HA are talking about supporting a million BCE
simultaneously. Do you understand the impact on the HA when these BCEs
starts getting close to expiry? and the HA needs to send a BRR message
and not only that but retransmits those messages until a BU is received
from each one of these MNs?
 
3. Personally, I wont agree to such functionality because Home Agent
acts as a server offering a MIP6 mobility service to multiple MNs
governed by a MIP6 protocol which offers a reliable mechanism for
updating the MN BCE lifetime at the HA.

4. Let us assume for the sake of argument that this new functionality is
supported by the HA, what is the impact:
4.1. Can you imagine the unnecessary traffic that is generated for no
reason.

4.2. What is going to be the MN processing when it receives such a
message? All current RFC3775 text talks about a BRR coming from the CN.
Is there going to be a difference in there?

4.3. How MN would recognize that this message is related to MN BCE at
the HA?

4.4. Backward compatibility, How, this would work for MN which only
supports BRR from the CN?
4.5. Finally, if this procedure is adopted, are we going to deprecate
the existing one using lifetime field in BA, etc?
4.6. etc.

> 
> I see it offering better reliability: even if the critical BU 
> is lost the HA requests the BU anew (BRR) and thus reduces 
> the non-bound time from the entire lifetime to much less.

[Ahmad]
1. Wow! Are you calling this a better reliability? What is your
definition of reliability then?

2. Are you suggesting that the current RFC3775 protocol is BROKEN and
does not address BU loss?

3. I do not understand what you mean by: "and thus reduces the non-bound
time from the entire lifetime to much less" Can you please elaborate
more and explain?

> > governed. i.e. if the MN does not renew its BCE, then that 
> is a clear 
> > indication for the HA to delete the MN BCE.
> 

[Ahmad]
What do you mean here, MN does not send a BU to refresh its Home BCE
lifetime except after receiving a BRR?

> That's your reading.  Other implementers read it in the way I said.

[Ahmad]
Excellent. Please cut and paste here the text where it supports your
understanding?

> Is a HA a "CN" when it is the dst field of the BU?

[Ahmad]
I am not sure what you are trying to say here, but for now, let us focus
on the real issue as highlighted above. Thanks!

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Dec 2007 21:46:08 +0100

Ahmad Muhanna wrote:
>>> Case of BRR message: ==================== [...] 4. RFC3775 
>>> specify that the MN needs to send a new BU message in order to 
>>> refresh or extend the BCE lifetime. This is extremely important 
>>> because a node like the HA, does not need to send a reminder to 
>>> every single MN that it serves and maintains a BCE for.
>> 
>> Right.
> 
> [Ahmad] Okay, then RFC3775 has a mechanism already specified for 
> updating the MN BCE at its HA, why do we need another new 
> functionality which, IMO, does not scale and may cause a huge problem
>  for the HA?

What exactly doesn't scale?   I think HA sending BRR is as scalable as
MN sending BU to it.  What's the non-scaling factor introduced by BRR at HA?

>>> 5. If the HA needs to send a reminder to every MN about the 
>>> expiry of its BCE, then we are introducing a new functionality 
>>> which violates the basic RFC3775 functionality and a non sense 
>>> complexity that absolutely is not necessary and not within the 
>>> original intention of RFC3775.
>> 
>> In what does that HA-sends-BRR functionality violate the basic 
>> 3775? What does it break?
> 
> [Ahmad] I am not sure if what does break is the right question here.

But you used the word 'violate' - what does it violate then?

>  original RFC3775 intention of how MIP6 BCE is managed at the HA.

Sorry, what's the conflict you point out?  It's not a new message
format, not any new option.

> However, let me explain what could happen in case that the HA 
> implements this new weird functionality:
> 
> simultaneously. Do you understand the impact on the HA when these 
> BCEs starts getting close to expiry?

Ah!  I didn't assume that all MNs send BUs simultaneously with precisely
the same lifetime.  You seem to assume so.  If so then we have a BU
storm in first place, prior to BRR.

If you didn't assume all million MNs send the BUs simultaneously then
the BRRs aren't sent simultaneously either.

> and the HA needs to send a BRR message and not only that but 
> retransmits those messages until a BU is received from each one of 
> these MNs?

The BRR is sent only if the BU is not received at HA the end of the
lifetime.  It is not _always_ sent.  That is current behaviour of CN.

> updating the MN BCE lifetime at the HA.

BU/BAck is reliable - BU/BAck/BRR is more reliable.  Would you agree?

> 4. Let us assume for the sake of argument that this new functionality
>  is supported by the HA, what is the impact: 4.1. Can you imagine the
>  unnecessary traffic that is generated for no reason.

No, no unnecessary traffic.  BRR sent only if at end of lifetime the BU
is not received.

> message? All current RFC3775 text talks about a BRR coming from the 
> CN. Is there going to be a difference in there?

No difference.

> 4.3. How MN would recognize that this message is related to MN BCE at

It doesn't need to distinguish this - why do you think it should
distinguish?  (if it wants so then it has the HA address thus it can
answer the q you raise).

> supports BRR from the CN?

How does MN know BRR is from CN and not from HA?  I don't think MNs
implement BRR such as to be _only_ from CN.  It can't distinguish the
BRR coming from CN, it just sees an IP address.

>  the existing one using lifetime field in BA, etc? 4.6. etc.

No, keep the suggested lifetime field in BA and process it as usual.

>> I see it offering better reliability: even if the critical BU is 
>> lost the HA requests the BU anew (BRR) and thus reduces the 
>> non-bound time from the entire lifetime to much less.
> 
> [Ahmad] 1. Wow! Are you calling this a better reliability? What is 
> your definition of reliability then?

A form of three-way handshake is better reliability than a two-way exchange.

>  does not address BU loss?

No, not suggesting so.  I suggest in certain conditions when the BU is
lost, the HA using BRR leads to shorter wait for BCE update (shorter
than the current BU waiting for the next lifetime) - less interruption
at MN.

> 3. I do not understand what you mean by: "and thus reduces the 
> non-bound time from the entire lifetime to much less" Can you please
>  elaborate more and explain?

If the BU is lost then MN will send another BU at the end of the current
lifetime.  Instead of waiting for the current lifetime to expire it
could be triggered by a BRR received from the HA.

No difference between CN and HA here.

>>> specific mobile nodes and more importantly if the MN decides NOT
>>>  to renew its BCE with a specific CN, the MN continues to be 
>>> reachable by other CNs at its HoA and CoA via its Home Agent BCE.
>>>  In other words, a MN binding with another CN represent the 
>>> service (RO) between MN<->CN ONLY, however, in the case of HA it
>>>  represents the MN's MIP6 service and access to the whole 
>>> internet. Which also administratively governed. i.e. if the MN 
>>> does not renew its BCE, then that is a clear indication for the 
>>> HA to delete the MN BCE.
>> 
> [Ahmad] What do you mean here, MN does not send a BU to refresh its 
> Home BCE lifetime except after receiving a BRR?

No, I meant it sends its BU as usual, (I think 4s before the lifetime
expires or so).

>>>  does not mean that the HA application at such a node need to 
>>> support BRR.
>> 
> [Ahmad] Excellent. Please cut and paste here the text where it 
> supports your understanding?

Right... difficult to find right now...

>>> IMO, such a node could act as a CN for some MNs and a HA for 
>>> others. Then, it is normal for this CN/HA node to support BRR for
>>>  those MN which is serving as a CN but not a HA.
>> 
> [Ahmad] I am not sure what you are trying to say here, but for now, 
> let us focus on the real issue as highlighted above. Thanks!

I meant to say that the effect of BRR being specified and implemented
for CN is more reliable BCE at CN.  Let's have the same level of
reliability at HA.

Or maybe we just want to stress that some HA implementations do BRR.  Or
do we want to forbid HA implementations to do BRR.

When do we discuss BErr? (Binding Error)

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 22 Dec 2007 01:29:51 -0600

> MN sending BU to it.  What's the non-scaling factor 

[Ahmad]
Read below.

> 
> >>> 5. If the HA needs to send a reminder to every MN about 
> the expiry 
> >>> of its BCE, then we are introducing a new functionality which 
> >>> violates the basic RFC3775 functionality and a non sense 
> complexity 
> >>> that absolutely is not necessary and not within the original 
> >>> intention of RFC3775.
> >> 

[Ahmad]
Please read below.
> Sorry, what's the conflict you point out?  It's not a new 
> message format, not any new option.

[Ahmad]
Please read below.
> > starts getting close to expiry?
> 
> Ah!  I didn't assume that all MNs send BUs simultaneously 
> with precisely the same lifetime.  You seem to assume so.  If 
> so then we have a BU storm in first place, prior to BRR.
> 
> If you didn't assume all million MNs send the BUs 
> simultaneously then the BRRs aren't sent simultaneously either.

[Ahmad]
Alex,
Hopefully, this is my last explanation to help clarify your
understanding of the applicability and use of BRR by the HA.

It is very strange that you understand things and functionalities only
according to your own terms and probably your implementation and past
experience. However, let me summarize what I want to say in an easier to
follow format:

1. Are you assuming that HA provides the same lifetime for all mobile
node and all different subscribers at all times?
2. Are you assuming that, for example all subscribers including prepaid
ones will end having the same BCE lifetime?
3. Are you assuming that there is only your own limited understanding of
how the HA handles the BCE lifetime?

4. IF the answer to all of the above yes, then we have a very specific
HA application which is limited to Alex understanding of Mobile IPv6
services and its applicability and at that point, there is no point of
discussing this any further!

5. However, If the answer is NO to any of 1-3 points, then when a HA is
able to support a high number of different types of subscribers BCE,
then the possibility of too many BCE lifetimes to expire at the same
time is quite very very high and probably devastating to the HA
functionality.

6. If the answer to No. 5 is YES, then it is very possible for a huge
number of these BCE lifetime to expire at the same time and if the HA
needs to send BRR message to all of these MNs at the same time, it
presents a new scalability challenge. In other words, this new
functionality needs to be evaluated and a study of how the HA handles
this very frequent and new phenomena while the HA still supports the
proclaimed number of activation rate becomes very necessary; Hope this
one is clear!

7. You asked me if the BU/BAK/BRR is more reliable than the BU/BA, well,
REGARDLESS!! since you admit that BU/BA is reliable, then that all what
we need and looking for. Your proposed enhancement is not needed,
however, you can keep it specific to your own implementation. Unless,
you still believe that RFC3775 protocol is BROKEN and does NOT handle BU
loss!? 

8. On another note you said: "BRR sent only if at end of lifetime when
the BU is not received." ok; Why do you think that the HA needs to send
a BRR message to the MN after the MN BCE lifetime has expired. It seems
to me that you need to pay close attention to the difference between a
MN Home BCE at the HA and a MN BCE at a CN. Please remember that the
lifetime of these two are DIFFERENT! And consequently what is applicable
to the handling of BCE at the CN is not necessarily TRUE for the MN home
BCE. One more time, an expiry of the BCE at the CN means RO with that CN
is lost but the MN is still reachable via the HA BCE!

9. You also said: "No, keep the suggested lifetime field in BA and
process it as usual."; excellent! Why then we need to introduce this new
functionality to do the same thing which is done by the BU/BA mechanism?

10. In reference to how the use of BRR is more reliable, you also said:
"A form of three-way handshake is better reliability than a two-way
exchange."; Man, it seems that you always tends to think of success
scenarios! You just said that the HA would send the BRR after the BCE
lifetime expires, well, let me add one more thing and the MN is probably
gone home and no longer there. What kind of reliability you are
achieving by sending a BRR for a MN which is probably not there. This
will be the vast majority of the scenarios that your BRR will be
addressing anyway. Let me ask one more time, do you still think that is
a better reliability? :)

11. You seem to understand that supporting BRR message at the HA nothing
but sending a BRR message! This is unfortunate! Supporting BRR is far
more complex and a new functionality than you have in mind and you ever
thought! Just as a reminder, All RFC3775 HA operations and state
machines is processing a request that generates a reply in some form of
Ack! Do you understand what does that mean and its difference from
supporting BRR?! Please think again.

12. However, if you are proposing that the MN is not supposed to send a
BU to renew its BCE lifetime except after it receives a BRR message from
its HA, then that probably a different discussion that needs another
round which I am not willing to be part of and I consider it a waste of
time :-))))

13. You also said: "I meant to say that the effect of BRR being
specified and implemented for CN is more reliable BCE at CN.  Let's have
the same level of reliability at HA." Man! Read the above. You seem not
to understand the difference!

14. You also said: "Or maybe we just want to stress that some HA
implementations do BRR.  Or do we want to forbid HA implementations to
do BRR." Again, I am not sure if you realize the difference in the BRR
applicability to CN BCE vs. HA BCE. IMO, the usecase you presented is
not worth to be discussed unless you believe and can prove that RFC3775
protocol is BROKEN and does not handle BU loss!

15. In your explanation of your earlier comment of "and thus reduces the
non-bound time from the entire lifetime to much less" You also said: "If
the BU is lost then MN will send another BU at the end of the current
lifetime. Instead of waiting for the current lifetime to expire it could
be triggered by a BRR received from the HA." :-(((( 

well, that is really an optimization for a HA implementation! 

Your statement is contradictory to what you said earlier. You said that
BRR is sent after the BCE lifetime expires and here you said that the HA
would send a BRR before the BCE expires. How the HA one time decides to
send a BRR before the end of BCE and some time after the lifetime
expires. On the other hand, why the BU/BA mechanism does not work for
the BU loss? You MUST explain why you think that it does NOT work? Do
you mean that the MN will send one single BU and that is it! Do you
assume that the MN does not use retransmission?

Also, you are assuming that the MN will wait until the last second of
its BCE lifetime and then send a BU!? On the other hand, have you ever
heard of the Binding Refresh Advice mobility option? Does the testing
client in your test bed understand this option, what about the HA does
it support that option? Please take a look and try to understand the
value of this option. May be after reading about it you would find what
is missing? IMO, all reliable MIP6 clients would initiate their BCE
lifetime refresh registration before the end of the home BCE lifetime!

16. In reference to RFC3775 text supporting your understanding of the CN
being a HA you said: " Right... difficult to find right now..." Cool
take your time and when you find it, please let me know. BTW: That is an
important piece of your reasoning for supporting this functionality:)
No?

17. finally you said: "When do we discuss BErr? (Binding Error)"
Probably after you show that you understand the difference in
applicability of BRR on the MN BCE at CN vs. MN BCE at HA.

Cheers!
Ahmad

> The BRR is sent only if the BU is not received at HA the end 
> of the lifetime.  It is not _always_ sent.  That is current 
> behaviour of CN.
> 
> No, no unnecessary traffic.  BRR sent only if at end of 
> lifetime the BU is not received.
> 
> It doesn't need to distinguish this - why do you think it 
> should distinguish?  (if it wants so then it has the HA 
> address thus it can answer the q you raise).
> 
> How does MN know BRR is from CN and not from HA?  I don't 
> think MNs implement BRR such as to be _only_ from CN.  It 
> can't distinguish the BRR coming from CN, it just sees an IP address.
> 
> No, not suggesting so.  I suggest in certain conditions when 
> the BU is lost, the HA using BRR leads to shorter wait for 
> BCE update (shorter than the current BU waiting for the next 
> lifetime) - less interruption at MN.
> 
> If the BU is lost then MN will send another BU at the end of 
> the current lifetime.  Instead of waiting for the current 
> lifetime to expire it could be triggered by a BRR received 
> from the HA.
> 
> >>> renew its BCE with a specific CN, the MN continues to be 
> reachable 
> >>> by other CNs at its HoA and CoA via its Home Agent BCE.
> >>>  In other words, a MN binding with another CN represent 
> the service 
> >>> (RO) between MN<->CN ONLY, however, in the case of HA it  
> represents 
> >>> the MN's MIP6 service and access to the whole internet. 
> Which also 
> >>> administratively governed. i.e. if the MN does not renew its BCE, 
> >>> then that is a clear indication for the HA to delete the MN BCE.
> >> 
> No, I meant it sends its BU as usual, (I think 4s before the 
> lifetime expires or so).
> 
> I meant to say that the effect of BRR being specified and 
> implemented for CN is more reliable BCE at CN.  Let's have 
> the same level of reliability at HA.
> 
> Or maybe we just want to stress that some HA implementations 
> do BRR.  Or do we want to forbid HA implementations to do BRR.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 26 Dec 2007 18:04:28 +0100

Hi,

i am trying to understand the impact of this in rfc3775 update

I don't think that whether it is a good idea to use BRR from the HA  
is relevant for the discussion of RFC3775 update (it is of course  
relevant for the mext ml but not imho for this particular process of  
updating rfc3775)

what imho is relavnt for the discussion of updating rfc3775 is  
whether rfc3775 is clear enough about whether HAs should send BRR or not

 From the text of rfc3775 that Alex sent in his original posting, it  
seems that only CNs should send BRR and BE and not by the HA, so, is  
there any text in rfc3775 that can possibly create confusion about  
HAs using BRR or BEs? Does anyone has interpreted rfc3775 in the way  
that HAs should send BRR and BEs?

again, while it may be a good idea that HAs do send BRR ad BE (i  
don't know) this is not what is relevant for rfc3775 update processs,  
but whether rfc3775 is unclear about that

Regards, marcelo

El 22/12/2007, a las 8:29, Ahmad Muhanna escribió:

> could
>> _
>> _

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Dec 2007 19:24:18 +0100

> that HAs should send BRR and BEs?

I will invite other implementers express whether it's clear or not who 
sends BRR and BErr.

For my reading, there are some occurences about the possibility of HA
being a CN, for example section 10.3.1 "Primary Care-of Address
Registration" in 10.3 "Processing Bindings" in 10 "HA Operation":

rfc3775:
[...]
> To begin processing the Binding Update, the home agent MUST perform 
> the following sequence of tests:
> 
> o  If the node implements only correspondent node functionality, or 
> has not been configured to act as a home agent,[...]

The 'node' (the home agent) can thus implement only CN functionality.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Dec 2007 12:46:25 -0600

Hi Marcelo,
Please see comments inline.

Regards,
Ahmad

> Subject: Re: [MEXT] RE: Reliability of sending BRR by the HA?
> 
> Hi,
> 
> I don't think that whether it is a good idea to use BRR from 
> the HA is relevant for the discussion of RFC3775 update 

[Ahmad]
I agree with you. That is inline with my initial comment.

> (it 
> is of course relevant for the mext ml but not imho for this 
> particular process of updating rfc3775)
> 
> what imho is relavnt for the discussion of updating rfc3775 
> is whether rfc3775 is clear enough about whether HAs should 
> send BRR or not
> 
>  From the text of rfc3775 that Alex sent in his original 
> posting, it seems that only CNs should send BRR and BE and 
> not by the HA,

[Ahmad]
TRUE. 

> so, is there any text in rfc3775 that can 
> possibly create confusion about HAs using BRR or BEs? Does 
> anyone has interpreted rfc3775 in the way that HAs should 
> send BRR and BEs?
> 
> again, while it may be a good idea that HAs do send BRR ad BE 
> (i don't know) this is not what is relevant for rfc3775 
> update processs, but whether rfc3775 is unclear about that

[Ahmad]
There is no mention anywhere in RFC3775 that HA can send BRR or BErr. I also may add that there is no confusion!:)

> >> MN sending BU to it.  What's the non-scaling factor 
> introduced by BRR 
> >> at HA?
> >
> > [Ahmad]
> > Read below.
> >
> >>
> >> Ah!  I didn't assume that all MNs send BUs simultaneously with 
> >> precisely the same lifetime.  You seem to assume so.  If 
> so then we 
> >> have a BU storm in first place, prior to BRR.
> >>
> simultaneously then 
> > experience. However, let me summarize what I want to say in 
> an easier 
> > to follow format:
> >
> > 2. Are you assuming that, for example all subscribers including 
> > prepaid ones will end having the same BCE lifetime?
> > 3. Are you assuming that there is only your own limited 
> understanding 
> > of how the HA handles the BCE lifetime?
> >
> > 5. However, If the answer is NO to any of 1-3 points, then 
> when a HA 
> > is able to support a high number of different types of subscribers 
> > BCE, then the possibility of too many BCE lifetimes to 
> expire at the 
> > same time is quite very very high and probably devastating 
> to the HA 
> > functionality.
> >
> > 7. You asked me if the BU/BAK/BRR is more reliable than the BU/BA, 
> > well, REGARDLESS!! since you admit that BU/BA is reliable, 
> then that 
> > all what we need and looking for. Your proposed enhancement is not 
> > needed, however, you can keep it specific to your own 
> implementation. 
> > Unless, you still believe that RFC3775 protocol is BROKEN 
> and does NOT 
> > handle BU loss!?
> >
> >
> > the BU is not received." ok; Why do you think that the HA needs to 
> > send a BRR message to the MN after the MN BCE lifetime has 
> expired. It 
> > seems to me that you need to pay close attention to the difference 
> > between a MN Home BCE at the HA and a MN BCE at a CN. 
> Please remember 
> > that the lifetime of these two are DIFFERENT! And 
> consequently what is 
> > applicable to the handling of BCE at the CN is not necessarily TRUE 
> > for the MN home BCE. One more time, an expiry of the BCE at the CN 
> > means RO with that CN is lost but the MN is still reachable 
> via the HA 
> > BCE!
> >
> > process it as usual."; excellent! Why then we need to 
> introduce this 
> > new functionality to do the same thing which is done by the BU/BA 
> > mechanism?
> >
> > lifetime expires, well, let me add one more thing and the MN is 
> > probably gone home and no longer there. What kind of 
> reliability you 
> > are achieving by sending a BRR for a MN which is probably 
> not there. 
> > This will be the vast majority of the scenarios that your 
> BRR will be 
> > addressing anyway. Let me ask one more time, do you still 
> think that 
> > is a better reliability? :)
> >
> > 11. You seem to understand that supporting BRR message at the HA 
> > nothing but sending a BRR message! This is unfortunate! 
> Supporting BRR 
> > is far more complex and a new functionality than you have 
> in mind and 
> > you ever thought! Just as a reminder, All RFC3775 HA operations and 
> > state machines is processing a request that generates a 
> reply in some 
> > form of Ack! Do you understand what does that mean and its 
> difference 
> > from supporting BRR?! Please think again.
> >
> > 12. However, if you are proposing that the MN is not 
> supposed to send 
> > a BU to renew its BCE lifetime except after it receives a 
> BRR message 
> > from its HA, then that probably a different discussion that needs 
> > another round which I am not willing to be part of and I 
> consider it a 
> > waste of time :-))))
> >
> > specified and implemented for CN is more reliable BCE at CN.  Let's 
> > have the same level of reliability at HA." Man! Read the above. You 
> > seem not to understand the difference!
> >
> > 15. In your explanation of your earlier comment of "and 
> thus reduces 
> > the non-bound time from the entire lifetime to much less" You also
> > said: "If
> > could be triggered by a BRR received from the HA." :-((((
> >
> > Your statement is contradictory to what you said earlier. You said 
> > that BRR is sent after the BCE lifetime expires and here 
> you said that 
> > the HA would send a BRR before the BCE expires. How the HA one time 
> > decides to send a BRR before the end of BCE and some time after the 
> > lifetime expires. On the other hand, why the BU/BA 
> mechanism does not 
> > work for the BU loss? You MUST explain why you think that 
> it does NOT 
> > work? Do you mean that the MN will send one single BU and 
> that is it! 
> > Do you assume that the MN does not use retransmission?
> >
> > value of this option. May be after reading about it you would find 
> > what is missing? IMO, all reliable MIP6 clients would 
> initiate their 
> > BCE lifetime refresh registration before the end of the home BCE 
> > lifetime!
> >
> > 16. In reference to RFC3775 text supporting your 
> understanding of the 
> > CN being a HA you said: " Right... difficult to find right now..." 
> > Cool take your time and when you find it, please let me know. BTW: 
> > That is an important piece of your reasoning for supporting this 
> > functionality:) No?
> >
> think MNs 
> >> No, not suggesting so.  I suggest in certain conditions 
> when the BU 
> >> is lost, the HA using BRR leads to shorter wait for BCE update 
> >> (shorter than the current BU waiting for the next
> >> If the BU is lost then MN will send another BU at the end of the 
> >> current lifetime.  Instead of waiting for the current lifetime to 
> >> expire it could be triggered by a BRR received from the HA.
> >>
> implemented 
> >> Or maybe we just want to stress that some HA 
> implementations do BRR.  
> >> Or do we want to forbid HA implementations to do BRR.
> >>

---

From: "K.Kawaguchi" <[email-masked]>
Date: Thu, 27 Dec 2007 12:09:51 +0900

Hi,

Couldn't we understand description in RFC3775 as follows?

BRR
  CN sends BRR.
  - Section 9.5 described Registration of CN.
    In it, section 9.5.5 described Sending BRR.

  HA does not send BRR.
  - Section 10.3 described Rigistration of HA.
    Although section 9.5.1 and section 9.5.4 were referred to, section 9.5.5 wasn't referred to.

BE
  CN sends BE (status=1) and BE (status=2).
  - Section 9.2 described Sending BE (status=2).
  - Section 9.3.1 described Sending BE (status=1).

  HA sends BE (status=1) and BE (status=2).
  - Section 10.2 described Sending BE (status=2) by the same processing as a section 9.2.
  - Section 10.3.1 described Sending BE (status=1) by the same processing as section 9.3.1.

  MN sends BE (status=2). MN does not send BE (status=1).
  - Section 11.2 described Sending BE (status=2) by the same processing as a section 9.2.
  - There is no section about Sending BE (status=2).

Best regards
---
Kiyoaki KAWAGUCHI

> The 'node' (the home agent) can thus implement only CN functionality.

Best regards
---
Kiyoaki KAWAGUCHI

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Dec 2007 00:14:34 -0600

> 
> > so, is there any text in rfc3775 that can possibly create confusion 
> > about HAs using BRR or BEs? Does anyone has interpreted 
> rfc3775 in the 
> > way that HAs should send BRR and BEs?
> > 
> > again, while it may be a good idea that HAs do send BRR ad 
> BE (i don't 
> > know) this is not what is relevant for rfc3775 update processs, but 
> > whether rfc3775 is unclear about that
> 
> [Ahmad]
> There is no mention anywhere in RFC3775 that HA can send BRR 
> or BErr. I also may add that there is no confusion!:)

[Ahmad]
Hi Marcelo,

hmmmm, technically this could be true with respect to Berr, However, I was referring to BRR! My bad I overlooked the BErr here. I will follow on the BErr discussion on the same thread in reply to Kiyoaki.

Regards,
Ahmad
> > >> A form of three-way handshake is better reliability than 
> a two-way 
> > >> exchange.
> > >>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Dec 2007 01:23:23 -0600

Hi Kiyoaki,

Regards,
Ahmad

> From: K.Kawaguchi [mailto:[email-masked]] 
> Sent: Wednesday, December 26, 2007 9:10 PM
> To: [email-masked]
> Cc: [email-masked]

[Ahmad]
I agree.

> processing as a section 9.2.

[Ahmad]
I agree.

> same processing as section 9.3.1.

[Ahmad]
I am not sure if this applicable to the Home Agent, unless I am missing
something. 

Under section 10.3.1., it says:
"
   o  A Home Address destination option MUST be present in the message.
      It MUST be validated as described in Section 9.3.1 with the
      following additional rule.  The Binding Cache entry existence test
      MUST NOT be done for IPsec packets when the Home Address option
      contains an address for which the receiving node could act as a
      home agent.
"

The above bullet clearly mentions that the Home Address destination
option MUST be present. It also, says that it MUST validate the Binding
Cache entry as per the rules mentioned in section 9.3.1. However, it
eliminates that check in the case IPsec is used and the receiving node
is a HA. i.e. if the receiving node a HA and IPsec is in used, these
checks are not applicable. 

Also as per section 9.3.1.: it says:

"
9.3.1.  Receiving Packets with Home Address Option

   Packets containing a Home Address option MUST be dropped if the given
   home address is not a unicast routable address.

   Mobile nodes can include a Home Address destination option in a
   packet if they believe the correspondent node has a Binding Cache
   entry for the home address of a mobile node.  Packets containing a
   Home Address option MUST be dropped if there is no corresponding
   Binding Cache entry.  A corresponding Binding Cache entry MUST have
   the same home address as appears in the Home Address destination
   option, and the currently registered care-of address MUST be equal to
   the source address of the packet.  These tests MUST NOT be done for
   packets that contain a Home Address option and a Binding Update.

   If the packet is dropped due the above tests, the correspondent node
   MUST send the Binding Error message as described in Section 9.3.3.
   The Status field in this message should be set to 1 (unknown binding
   for Home Address destination option).
"

The above three paragraphs list the following:

1. Packets containing a Home Address option MUST be dropped if there is
no corresponding Binding Cache entry.
2. If there is a corresponding binding cache entry, the following check
is required and if failed, packet is dropped:
"
   A corresponding Binding Cache entry MUST have
   the same home address as appears in the Home Address destination
   option, and the currently registered care-of address MUST be equal to
   the source address of the packet.
"
3. In the third paragraph is says, if the packet is dropped based on any
of the above two cases (1 & 2). The correspondent node MUST send the BE
as in section 9.3.3. with code 1 "unknown binding for Home Address
destination option.

However, the end of the second paragraph clearly says that the above two
tests are clearly NOT required in case of the packet has a Home Address
option and at the same time it contains a Binding Update, i.e. if the
receiving node is a HA, it will NOT perform this check and consequently
will not send a BE message with code 1.

Best Regards,
Ahmad

> > > whether rfc3775 is clear enough about whether HAs should 
> send BRR or 
> > > not
> > > 
> posting, it

---

From: "K.Kawaguchi" <[email-masked]>
Date: Thu, 27 Dec 2007 17:28:27 +0900

Hi, 

> will not send a BE message with code 1.

[kiyoaki]
I agree.

I forgot to add one more case.
It seems that this case is not clear at RFC3775.

It is a case where the home address option is added to some message which HA and MN receive.
A node without MIP6 function replys ICMPv6 Parameter Problem (Section 4 in RFC2460).
How are HA and MN?

I hope that this is described in the section of HA and MN.
And I think that it refers to as same as section 9.3.1 in RFC3775.

Best regards
---
Kiyoaki KAWAGUCHI

Best regards
---
Kiyoaki KAWAGUCHI