Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt

From: [email-masked]
Date: Wed, 9 Sep 2009 23:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.

	Title           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-mext-binding-revocation-12.txt
	Pages           : 43
	Date            : 2009-09-09

This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and the associated resources.  These
semantics are generic enough and can be used by mobility entities in
the case of Mobile IPv6 and its extensions.  This mechanism allows
the mobility entity which initiates the revocation procedure to
request its peer to terminate either one, multiple or all specified
binding(s).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 10 Sep 2009 01:58:43 -0500

FYI,

A new revision has been published which clarifies further the wild card
NAI as per Pasi's comment. It also uses proper RFC2119 requirements in
couple of places as per Ralph's comment.

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, September 10, 2009 1:45 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt
> 
> This document defines a binding revocation mechanism to 
> terminate a mobile node's mobility session and the associated 
> resources.  These semantics are generic enough and can be 
> used by mobility entities in the case of Mobile IPv6 and its 
> extensions.  This mechanism allows the mobility entity which 
> initiates the revocation procedure to request its peer to 
> terminate either one, multiple or all specified binding(s).
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Sep 2009 17:07:48 -0700

Hi Ahmad,

I have a question on the following paragraph.

   o  If the Global (G) bit is set and the Revocation Trigger field
      value is "Per-Peer Policy", the LMA MUST validate that the Proxy
      (P) bit is set and the MN-ID option is present with the mobile
      access gateway identity included.  In addition, the local mobility
      anchor MUST verify that the identified mobile access gateway as
      per the value in the MN-ID option is authorized to use the global
      revocation with revocation trigger value "Per-Peer Policy", see
      Section 13.  If the Acknowledge (A) bit is set and the local
      mobility anchor processes the Global Binding Revocation Indication
      message successfully, it MUST send a successful Binding Revocation
      Acknowledgement message.  However, if the Acknowledge (A) bit is
      not set, the local mobility anchor SHOULD silently discard the
      Binding Revocation Indication message.

The last two sentences were added in version 12. Why would you silently
discard the BRI message? Yes, there is an error in the BRI message - the 'A'
flag is not set, when the 'G' flag is set with "per-peer policy". But
silently discarding the message seems to be wrong.

Vijay

On 9/9/09 11:58 PM, "Ahmad Muhanna" wrote:

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Sep 2009 17:14:05 -0700

Hi Ahmad,

Can't we just remove the acknowledgement flag altogether? Make it simple by
always requiring a BRA message in response to a BRI message. I am pretty
sure most if not all implementations would set the 'A' flag when sending the
BRI message.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Sep 2009 17:37:29 -0700

Hi Ahmad,

>    o  The care-of address for the binding MUST be used as the
>       destination address in the packet's IPv6 header, unless an
>       Alternate Care-of Address mobility option is included in the
>       Binding Revocation Indication.  If an Alternate Care-of Address
>       option is included in the Binding Revocation Indication message,
>       the destination address in the packet's IPv6 header SHOULD be set
>       to the source IP address of the packet that carried the latest
>       successful Binding Update with the Alternate Care-of address
>       included.

We had extensive discussions on this in the past. According to RFC 3775 and
5213, we only store the care-of address (or the proxy care-of address) in
the binding cache entry. You need to extend the conceptual BCE structure, if
you want to store the original source address for the BU/PBU in addition to
the care-of address from the alternate care-of address option. This is
missing in the current specs we have.

There is also an issue. How do you know if the original source address is
still valid? For example, a MN could send a BU from the oldCoA updating the
binding to point to the newCoA during a handover while still attached to the
old router. After the handover, the oldCoA is gone. According to the text
above, the HA, would end up sending the BRI to the oldCoA to revoke the
binding. The MN would not receive it.

Section 8.1.1 also has similar text. I have issues with that too.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 00:46:31 -0500

Hi Vijay,

It is not a matter of removing it and restrict all implementations to
behave the same as if it is always set, it has been there since day one
and looking at MIP6, BU has an Acknowledge (A) bit too. I believe the
best way is to keep it and if there is places that have some concern we
need to fix it properly.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, September 10, 2009 7:14 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: Acknowledgements for Revocation Messages
> 
> Hi Ahmad,
> 
> Can't we just remove the acknowledgement flag altogether? 
> Make it simple by always requiring a BRA message in response 
> to a BRI message. I am pretty sure most if not all 
> implementations would set the 'A' flag when sending the BRI message.
> 
> Vijay
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 10 Sep 2009 22:50:47 -0700

> behave the same as if it is always set, it has been there since day one

I know its been there for a while. But removing the flag and all the text
around it will really simplify things. It shouldn't take too long to remove
all the relevant text.

> and looking at MIP6, BU has an Acknowledge (A) bit too.

Frankly, I have never seen a BU without the 'A' flag is set. Anyway, that is
not sufficient for justifying having the 'A' flag for the BRI message too.

> I believe the

I really think it is unnecessary.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 00:55:33 -0500

Hi Vijay,

> Sent: Thursday, September 10, 2009 7:08 PM
> Subject: Re: [MEXT] I-D 
> Action:draft-ietf-mext-binding-revocation-12.txt
> 
> Hi Ahmad,
> 
> The last two sentences were added in version 12. Why would 
> you silently discard the BRI message? Yes, there is an error 
> in the BRI message - the 'A'
> flag is not set, when the 'G' flag is set with "per-peer 
> policy". But silently discarding the message seems to be wrong.
[Ahmad]
Okay, you may have a point here! Probably what we need to say: If the
LMA processed the BRI successfully, the LMA MUST not send a BRA. 

Does that sound about right?

Regards,
Ahmad

> > A new revision has been published which clarifies further the wild 
> > card NAI as per Pasi's comment. It also uses proper RFC2119 
> > requirements in couple of places as per Ralph's comment.
> > 
> > Regards,
> > Ahmad
> >  
> > 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of [email-masked]
> >> Subject: [MEXT] I-D 
> Action:draft-ietf-mext-binding-revocation-12.txt
> >> 
> >> This draft is a work item of the Mobility EXTensions for 
> IPv6 Working 
> >> Group of the IETF.
> >> 
> >> 
> terminate a

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 05:39:02 -0500

Hi Vijay,

> Sent: Friday, September 11, 2009 12:51 AM
> Cc: Jari Arkko
> Subject: Re: Acknowledgements for Revocation Messages
> 
> I know its been there for a while. But removing the flag and 
> all the text around it will really simplify things. It 
> shouldn't take too long to remove all the relevant text.
[Ahmad]
That may be true but at the same time limits options for
implementations. I see that some implementations would rather send BRI
without the (A) bit is set. Depending on the severity of the BRI
message. I believe that this option should be available and we need to
make sure that if there is some clarification needed, we capture that
and fix the text.
> Frankly, I have never seen a BU without the 'A' flag is set. 
> Anyway, that is not sufficient for justifying having the 'A' 
> flag for the BRI message too.

[Ahmad]
TRUE for PBU/PBA because that is for setting up the mobility session and
it is very important to get the ACK back. However, for releasing the
session, it may not be as severe.

> 
> > I believe the
> > best way is to keep it and if there is places that have 
> some concern 
> > we need to fix it properly.
> 
[Ahmad]
Allowing the option for implementation to handle this is a useful thing,
IMO.

> >> Make it simple by always requiring a BRA message in 
> response to a BRI 
> >> message. I am pretty sure most if not all implementations 
> would set 
> >> the 'A' flag when sending the BRI message.
> >> 
> >> Vijay
> >> 
> >> 
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 06:10:07 -0500

Hi Vijay,
Please see inline.

Regards,
Ahmad

> Sent: Thursday, September 10, 2009 7:37 PM
> We had extensive discussions on this in the past. According 
> to RFC 3775 and 5213, we only store the care-of address (or 
> the proxy care-of address) in the binding cache entry. You 
> need to extend the conceptual BCE structure, if you want to 
> store the original source address for the BU/PBU in addition 
> to the care-of address from the alternate care-of address 
> option. This is missing in the current specs we have.
[Ahmad]
I very well remember that discussion. I also remember the chairs blocked
the binding revocation progress until this issue is resolved. That is
the reason for coming up with this compromise. The compromise is as
follows:

1. We do not mandate the extension of the BCE to store the source IP
address of the PBU/BU.
2. implementation which use the source IP address of the PBU/BU packet
to send the PBA/BA back use it as they are using it now. Later on, they
send the BRI to the pCoA as it was received in the Alt Care-of address.
3. implementations which choose to save the source IP address in the BCE
(extending BCE locally which has no issue of IOT) they can at a later
time send the BRI to either the source IP address or the pCoA.
4. This way all were happy.
5. During the IESG review there was an explicit comment to make this
compromise clear in the document and that what I did.

> 
> There is also an issue. How do you know if the original 
> source address is still valid? 
[Ahmad]
I believe if the source IP address would become at any point invalid,
the MN should inform the LMA/HA with this. The way I look at it is as
follows:

As per MIP6, my understanding is the following:
1. The default is that when the MN is attached to a link other than its
home link, the source IP address of the BU is the Care-of address.

2. If the MN use an IP address in the source of the BU and include the
Alt Care-of address option, the MN is communicating to the HA that:
although the source IP address is a valid one and supposed to be the
Care-of address, but the MN would like to use the IP address included in
the Alt Care-of address option as its Care-of address for terminating
the IP-in-IP tunnel.

3. At any time either one of these addresses become invalid or not valid
for reaching the MN, I believe the MN should update the HA accordingly.
If that happens, then whatever proposed in the binding revocation will
always work as intended.

> For example, a MN could send a 
> BU from the oldCoA updating the binding to point to the 
> newCoA during a handover while still attached to the old 
> router. After the handover, the oldCoA is gone. According to 
> the text above, the HA, would end up sending the BRI to the 
> oldCoA to revoke the binding. The MN would not receive it.
[Ahmad]
BUT, I believe this usecase is a pre-registration usecase. If that the
case, the protocol should be very clear to indicate that to the anchor
point (HA). Using the Alt Care-of address as you mentioned to address
pre-registration is NOT the best way to do it. IMO, it may have bad
consequences. We can go on discussing this but, I do not believe we need
to address this case as it is not a clean way to do pre-registration.

Even if that the case, I believe as soon as the MN becomes aware that
the oldCare-of address becomes invalid, the MN should update the HA with
another BU and use the newCoA as the source IP address of the BU, in
order to keep the HA in sync with the MN new reach ability condition.

Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 08:00:50 -0700

Hi Ahmad,

> make sure that if there is some clarification needed, we capture that

Which BRI is less severe and does not need the 'A' flag set? Can you give me
an example?

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 11:01:55 -0500

Hi Vijay,

> >>> behave the same as if it is always set, it has been there 
> since day 
> >>> one
> >> 
> >> I know its been there for a while. But removing the flag 
> and all the 
> >> text around it will really simplify things. It shouldn't take too 
> >> long to remove all the relevant text.
> > [Ahmad]
> Which BRI is less severe and does not need the 'A' flag set? 
> Can you give me an example?
[Ahmad]
IMO,
A BRI with the Global (G) bit is more severe than a BRI that is sent to
clear resources at the source MAG for a single mobility session, for
example, after a handoff. 

Similarly, I would categorize a BRI with revocation trigger
"Administrative Reason" is more sever too than a cleaning resources BRI
after handoff.

BUT that should be left for implementation to decide. I do not see any
problem keeping the Acknowledge (A) bit functionality in there.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 10:54:29 -0700

Hi Ahmad, 

> example, after a handoff.

Sure, global revocation is more severe. But I don't see the LMA not setting
the 'A' flag when revoking the binding at the old MAG. You do want the ack
for the revocation message you just sent.
 
> problem keeping the Acknowledge (A) bit functionality in there.

I do. The recent changes, adding text related to the "A" flag throughout the
document, has actually made it a bit harder to read. It seems to be an
unnecessary function, not adding anything to the protocol. Removing it
actually simplifies the document as well as the implementation.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 10:59:37 -0700

Ahmad

> 4. This way all were happy.

Figuring out which destination address to use on the BRI message cannot be
left implementation specific. If you do want to use the original source
address for the BU for the BRI, why don't you just extend the conceptual
binding cache data structure to include the original source address in
addition to the address in the alternate CoA option, in case they are
different. 

This "compromise" you are referring is bad. I would prefer specifying this
explicitly.

But there would still be an issue related to the old CoA not being valid. We
need to address that.

> compromise clear in the document and that what I did.

Of course. The current text was too vague. :)

> for reaching the MN, I believe the MN should update the HA accordingly.

The MN did already. When it sent the BU from the old CoA binding the new CoA
to the home address, it told the HA to start using the new CoA. Now you have
the binding revocation document specifiying that the HA should use the old
CoA for sending the BRI. This is wrong.

> If that happens, then whatever proposed in the binding revocation will

You are assuming that the MN will do something in addition to what is
specified in RFC 3775. Won't work.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 11:14:35 -0700

Hi Ahmad,

> Does that sound about right?

Not really. Is the BRI valid? It looks like it is not valid, since the
document says the 'A' MUST be set when the 'G' bit is set. Shouldn't the LMA
send an error back without removing the set of bindings?

Your proposal above says the LMA should go ahead, process the BRI and remove
a set of bindings and not send an Ack. This is contradictory to the above.

Just removing the 'A' bit would help. :)

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 16:10:33 -0500

Hi Vijay,

> Sent: Friday, September 11, 2009 12:54 PM
> > A BRI with the Global (G) bit is more severe than a BRI 
> that is sent 
> > to clear resources at the source MAG for a single mobility session, 
> > for example, after a handoff.
> 
> Sure, global revocation is more severe. But I don't see the 
> LMA not setting the 'A' flag when revoking the binding at the 
> old MAG. You do want the ack for the revocation message you just sent.
>  
> > "Administrative Reason" is more sever too than a cleaning resources 
> > BRI after handoff.
> > 
> I do. The recent changes, adding text related to the "A" flag 
> throughout the document, has actually made it a bit harder to 
> read. It seems to be an unnecessary function, not adding 
> anything to the protocol. Removing it actually simplifies the 
> document as well as the implementation.
[Ahmad]
I am open for any changes that you think is needed to improve the text;
I do not see any problem in that. On the other hand, the comments I got
from the IESG review is that rev. 12 is much better. I also would like
to emphasize that leaving the (A) bit in a very reasonable thing. If an
implementation wants to set the (A) bit all the time, let it be. No
problem at all. However, other implementations may choose to do it
differently.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 16:31:53 -0500

Hi Vijay,

> >> The last two sentences were added in version 12. Why would you 
> >> silently discard the BRI message? Yes, there is an error 
> in the BRI 
> >> message - the 'A'
> policy". But 
> Not really. Is the BRI valid? It looks like it is not valid, 
> since the document says the 'A' MUST be set when the 'G' bit 
> is set. Shouldn't the LMA send an error back without removing 
> the set of bindings?

[Ahmad]
NO. :)
Because, if the LMA sends the BRI without setting the Acknowledge (A)
bit, why the LMA would keep tracking the BRI as an outstanding BRI. That
is actually my problem.

In a nutshell, if the initiator does NOT set the (A) bit, it does NOT
retransmit the BRI nor keep the BRI in the outstanding BRI list for a
matching BRA. Even if the MAG sends a BRA, the LMA will never know about
it. It would be silently dropped. NO?

> 
> Your proposal above says the LMA should go ahead, process the 
> BRI and remove a set of bindings and not send an Ack. This is 
> contradictory to the above.
[Ahmad]
Because, rev. 12 text says that the LMA SHOULD silently discard the BRI
message and you objected and I was trying to work to hopefully satisfy
what you are looking for.

However, If the (A) bit is NOT set in the BRI with (G) bit is set, the
receiving node SHOULD silently discard the message. WHY?

1. The sending node is fully aware of the severity of the BRI with the
(G) bit set and revocation trigger="Per-Peer Policy", thus the initiator
which comply to this specification knows that it is doing something
illegal and wrong.

2. On the other hand, even if the receiving node would like to send a
BRA with a status "unsuccessful", there is NO guarantee that the
initiator will ever process that message and learn what happened,
because it does NOT track the BRI in the outstanding BRI messages list,
because it did not set the (A) bit.

So, I was wrong, will keep the existing text.:)

Regards,
Ahmad

> >>>> A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> >>>> directories.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 14:49:11 -0700

Hi Ahmad,

> So, I was wrong, will keep the existing text.:)

You have confused the heck out of me. :) Ok, back to the issue. The MAG
sends a bulk revocation message with the 'G' flag set, but with the 'A' flag
not set. What is the LMA behavior for this?

The current text says the LMA must silently discard the BRI. This doesn't
make sense.

Can you first explain what the LMA should do before we try to change any
text?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 14:58:25 -0700

Hi Ahmad,

On 9/11/09 2:10 PM, "Ahmad Muhanna" wrote:

> to emphasize that leaving the (A) bit in a very reasonable thing.

Thanks.

> If an

Question is are there any? I don't see anyone not setting the 'A' bit for a
revocation message. Anyway, the binding revocation document is supposed to
specify the binding revocation mechanism. If you remove the "A" flag,
implementations will follow that. If you have a valid use case for not
setting the "A" flag, then its ok. Otherwise, IMO, we should remove it.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 17:12:43 -0500

Hi Vijay,

> Sent: Friday, September 11, 2009 4:49 PM
> >> Your proposal above says the LMA should go ahead, process 
> the BRI and 
> >> remove a set of bindings and not send an Ack. This is 
> contradictory 
> >> to the above.
> > [Ahmad]
> > Because, rev. 12 text says that the LMA SHOULD silently discard the 
> > BRI message and you objected and I was trying to work to hopefully 
> > satisfy what you are looking for.
> > 
> > (G) bit set and revocation trigger="Per-Peer Policy", thus the 
> > initiator which comply to this specification knows that it is doing 
> > something illegal and wrong.
> > 
> > because it does NOT track the BRI in the outstanding BRI messages 
> > list, because it did not set the (A) bit.
> > 
> You have confused the heck out of me. :) Ok, back to the 
> issue. The MAG sends a bulk revocation message with the 'G' 
> flag set, but with the 'A' flag not set. What is the LMA 
> behavior for this?
> 
> The current text says the LMA must silently discard the BRI. 
> This doesn't make sense.
> 
> Can you first explain what the LMA should do before we try to 
> change any text?
[Ahmad]
Agreed. I was thinking that the message comes from the LMA to the MAG :(

1. If the MAG does not set the (A) bit, it is communicating to the LMA
that it is NOT interested in getting back a BRA.
2. Consequently, when the MAG does not set the (A) bit, it does not
retransmits the BRI and it does not track the BRI as one of the
outstanding BRI messages.

3. NOW, when the LMA receives such message, as per this specification
the MAG MUST have set the (A) bit in this case, but it did not. What the
options for the LMA:

3.1. Process the message and remove all bindings without sending a BRA,
but the MAG did violate the protocol and mandating that the MAG set the
(A) bit in this case means something.
3.2. Process the message and send a BRA with an unsuccessful status
code, well, the LMA can do that, BUT unfortunately it wont help in
anything. Because as I said the MAG is NOT expecting a BRA and is not
tracking the BRI as an outstanding message.
3.3. LMA consider this BRI as a violation of the protocol and does not
remove the mobility sessions based on this message. In addition, since
the (A) bit is not set, the LMA does not send a BRA. This means, LMA
discard the message. 

IMO, option No. 3 is the correct one and that what rev 12 text says.

Hope it is clearer this time.

Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 15:19:12 -0700

Hi Ahmad

> IMO, option No. 3 is the correct one and that what rev 12 text says.

Option 3 is the least acceptable to me. Silently discarding the message
without letting the MAG know that something is wrong doesn't make sense.

Option 2 makes sense. If there is an error in a message you send, you should
always be ready to process the response that points to the error. We might
need to come up with a new status for this.

This actually proves that leaving the ack optional makes no sense.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 17:43:45 -0500

Hi Vijay,

> Sent: Friday, September 11, 2009 5:19 PM
> issue. The 
> >> MAG sends a bulk revocation message with the 'G'
> behavior for 
> >> this?
> >> Can you first explain what the LMA should do before we try 
> to change 
> >> any text?
> > [Ahmad]
> > Agreed. I was thinking that the message comes from the LMA 
> to the MAG 
> > :(
> > 
> > the MAG MUST have set the (A) bit in this case, but it did 
> not. What 
> > the options for the LMA:
> > 
> > 3.1. Process the message and remove all bindings without sending a 
> > BRA, but the MAG did violate the protocol and mandating 
> that the MAG 
> > set the
> Option 3 is the least acceptable to me. Silently discarding 
> the message without letting the MAG know that something is 
> wrong doesn't make sense.
[Ahmad]
BUT did NOT the MAG violate the protocol to start with. If the MAG would
like to hear back from the LMA it MUST have followed the protocol and
set the (A) bit. We are not here trying to develop a protocol for NON
behaving MAGS:)

> 
> Option 2 makes sense. If there is an error in a message you 
> send, you should always be ready to process the response that 
> points to the error. We might need to come up with a new 
> status for this.
[Ahmad]
Well, I am not sure why it makes sense. The MAG is misbehaving and
violating the protocol. It already knows that it MUST set the (A) bit.
Also, the MAG knows that if it did not set the (A) bit, the LMA will
discard the message, so it is better to set the (A) bit then.

> This actually proves that leaving the ack optional makes no sense.

[Ahmad]
No at all. Look what RFC3775 says:

   Binding Acknowledgement

      A Binding Acknowledgement is used to acknowledge receipt of a
      Binding Update, if an acknowledgement was requested in the Binding
      Update, ...................

There more text in 3775 talks about the (A) bit; of course in the case
of BU/BA.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 17:47:52 -0500

Thanks Vijay!

Let us move on with this and if there is any missing text or the text
needs improvement, will be more than happy to fix it. 

Regards,
Ahmad

> Sent: Friday, September 11, 2009 4:58 PM
> >> Sure, global revocation is more severe. But I don't see 
> the LMA not 
> >> setting the 'A' flag when revoking the binding at the old 
> MAG. You do 
> >> want the ack for the revocation message you just sent.
> >>  
> >> throughout the document, has actually made it a bit harder 
> to read. 
> >> It seems to be an unnecessary function, not adding anything to the 
> >> protocol. Removing it actually simplifies the document as 
> well as the 
> >> implementation.
> > [Ahmad]
> > I am open for any changes that you think is needed to improve the 
> > text; I do not see any problem in that. On the other hand, the 
> > comments I got from the IESG review is that rev. 12 is much 
> better. I 
> > also would like to emphasize that leaving the (A) bit in a 
> very reasonable thing.
> 
> Thanks.
> 
> > If an
> Question is are there any? I don't see anyone not setting the 
> 'A' bit for a revocation message. Anyway, the binding 
> revocation document is supposed to specify the binding 
> revocation mechanism. If you remove the "A" flag, 
> implementations will follow that. If you have a valid use 
> case for not setting the "A" flag, then its ok. Otherwise, 
> IMO, we should remove it.
> 
> Vijay
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 15:49:35 -0700

Hi Ahmad,

> set the (A) bit. We are not here trying to develop a protocol for NON

The LMA should either send a ICMP error (parameter problem with offset set
to the flags field) or send a BRA message with an error status that says the
message was nor processed because the flags are inconsistent.

The LMA shouldn't drop the messages silently.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Sep 2009 15:50:45 -0700

:) 

I still think we should just remove the 'A' flag and all the associated
text. BRI messages are always acked with BRA messages.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 11 Sep 2009 17:56:38 -0500

Appreciate you thinking that way, but I do not see any compelling
technical reason to change this functionality which had the wg consensus
sine day one. :-)

Regards,
Ahmad

> Sent: Friday, September 11, 2009 5:51 PM
> I still think we should just remove the 'A' flag and all the 
> associated text. BRI messages are always acked with BRA messages.
> 
> Vijay
> 
> 
> >> Question is are there any? I don't see anyone not setting 
> the 'A' bit 
> >> for a revocation message. Anyway, the binding revocation 
> document is 
> >> supposed to specify the binding revocation mechanism. If 
> you remove 
> >> the "A" flag, implementations will follow that. If you 
> have a valid 
> >> use case for not setting the "A" flag, then its ok. 
> Otherwise, IMO, 
> >> we should remove it.
> >> 
> >> Vijay
> >> 
> >> 
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 12 Sep 2009 02:32:28 -0500

Hi Vijay,

> >> Option 3 is the least acceptable to me. Silently discarding the 
> >> message without letting the MAG know that something is 
> wrong doesn't 
> >> make sense.
> > [Ahmad]
> > BUT did NOT the MAG violate the protocol to start with. If the MAG 
> > would like to hear back from the LMA it MUST have followed the 
> > protocol and set the (A) bit. We are not here trying to develop a 
> > protocol for NON behaving MAGS:)
> 
> The LMA should either send a ICMP error (parameter problem 
> with offset set to the flags field) 

[Ahmad]
Hmmm... Very interesting! What is the relation here.
Did the IP packet included:
1.  Erroneous header field encountered,
2.  Unrecognized Next Header type encountered, OR
3.  Unrecognized IPv6 option encountered

Which one of these?
The issue here is of a MAG that on the protocol level is NOT compliant
to this specification. Why do we need to worry about it?

> or send a BRA message 
> with an error status that says the message was nor processed 
> because the flags are inconsistent.
[Ahmad]
As I said earlier, 
1. The MAG violated the protocol by NOT setting the (A) bit.

2. As the MAG did NOT set the (A) bit, it is ASKING the LMA NOT to send
back a BRA; unless we would like to second guess what the MAG should
have done or intended to do. An implementation that does NOT follow the
specification and we need to have this specification customized to
address that implementation short coming.

3. Even, if the LMA sends a BRA, the MAG will never be able to intercept
it, unless, again, this MAG is a kluge implementation that does not
follow the protocol by NOT setting the (A) bit BUT at the same time it
waits for a BRA!

BTW: what could cause the MAG to NOT set the (A) bit in this scenario
and violates the protocol?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 12 Sep 2009 13:27:01 -0500

> Sent: Friday, September 11, 2009 1:00 PM
> Subject: Re: [MEXT] I-D
> >> We had extensive discussions on this in the past. According to RFC 
> >> 3775 and 5213, we only store the care-of address (or the proxy 
> >> care-of address) in the binding cache entry. You need to 
> extend the 
> >> conceptual BCE structure, if you want to store the original source 
> >> address for the BU/PBU in addition to the care-of address from the 
> >> alternate care-of address option. This is missing in the current 
> >> specs we have.
> > [Ahmad]
> > I very well remember that discussion. I also remember the chairs 
> > blocked the binding revocation progress until this issue is 
> resolved. 
> > That is the reason for coming up with this compromise. The 
> compromise 
> > is as
> > follows:
> > 
> > to send the PBA/BA back use it as they are using it now. Later on, 
> > they send the BRI to the pCoA as it was received in the Alt 
> Care-of address.
> > 3. implementations which choose to save the source IP 
> address in the 
> > BCE (extending BCE locally which has no issue of IOT) they can at a 
> > later time send the BRI to either the source IP address or the pCoA.
> Figuring out which destination address to use on the BRI 
> message cannot be left implementation specific. If you do 
> want to use the original source address for the BU for the 
> BRI, why don't you just extend the conceptual binding cache 
> data structure to include the original source address in 
> addition to the address in the alternate CoA option, in case 
> they are different. 
> 
> This "compromise" you are referring is bad. I would prefer 
> specifying this explicitly.
> 
[Ahmad]
Hi Vijay,

This has been the consensus of the work group. All what rev. 11 & 12 has
is clarifications to what is already there. There is no new
functionality. Do you find any there?

Also, what do you mean when you said "figuring out where to send the BRI
can not be left for implementation"?
Is that what the text says?

What bothers me in all of this is what you are arguing in all of these
posting is: NO issues and all these things have been discussed before
and agreed upon based on WG consensus. I believe keep going back to
re-discuss issues that have consensus in the wg is a bad thing,
especially at this stage. It does not help the wg achieve its goals,
badly hinders progress, and waste valuable time.

At this stage, I hope we all focus on things that enhance the document
readability and clarity. 

Regards,
Ahmad

> But there would still be an issue related to the old CoA not 
> being valid. We need to address that.
> 
> >> There is also an issue. How do you know if the original source 
> >> address is still valid?
> > [Ahmad]
> > 1. The default is that when the MN is attached to a link other than 
> > its home link, the source IP address of the BU is the 
> Care-of address.
> > 
> > Care-of address, but the MN would like to use the IP 
> address included 
> > in the Alt Care-of address option as its Care-of address for 
> > terminating the IP-in-IP tunnel.
> > 
> > 3. At any time either one of these addresses become invalid or not 
> > valid for reaching the MN, I believe the MN should update 
> the HA accordingly.
> 
> The MN did already. When it sent the BU from the old CoA 
> binding the new CoA to the home address, it told the HA to 
> start using the new CoA. Now you have the binding revocation 
> document specifiying that the HA should use the old CoA for 
> sending the BRI. This is wrong.
> 
> You are assuming that the MN will do something in addition to 
> what is specified in RFC 3775. Won't work.
> 
> Vijay
> 
> > 
> > 
> newCoA during 
> >> a handover while still attached to the old router. After the 
> >> handover, the oldCoA is gone. According to the text above, the HA, 
> >> would end up sending the BRI to the oldCoA to revoke the 
> binding. The 
> >> MN would not receive it.
> > [Ahmad]
> > consequences. We can go on discussing this but, I do not believe we 
> > need to address this case as it is not a clean way to do 
> pre-registration.
> > 
> > the oldCare-of address becomes invalid, the MN should update the HA 
> > with another BU and use the newCoA as the source IP address 
> of the BU, 
> > in order to keep the HA in sync with the MN new reach 
> ability condition.
> > 
> > Regards,
> > Ahmad
> > 
> >>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Sep 2009 13:40:43 +0300

At this point we are only changing the document if there's a technical 
problem somewhere.

That being said, I believe there were/are issues in the rules that 
specify when a BRA is going to be sent. So something has to be fixed in 
any case. The fix can be:

1. Make it clear what the rules are, and ensure that the rules are 
logically consistent. RFC 3775 Section 9.5.4 should be default approach, 
and I don't really see no reason to deviate from that approach if we 
have the A bit to begin with. I'm not sure I like the rules that mix G 
and A bits; I would rather keep separate things separate. In any case, 
what the specific issues Ben and Vijay raised need to be fixed.

2. Remove the A bit and make the spec simpler. I do not personally 
believe the flexibility is useful in this context, so I do not object to 
removing it. However, given that we are so far in the process, we should 
not do this change if there are people who are opposing it. Ahmad, since 
you were the one arguing that there is a need, can you re-think this in 
view of whether your objections are about real-live business needs or 
reducing late changes? If its more about the latter, maybe the right 
thing is to get rid of the bit.

Jari

---

From: <[email-masked]>
Date: Mon, 14 Sep 2009 16:23:52 +0200

> thing is to get rid of the bit.

I agree with the view that if removing the A bit will simplify the spec, we
should do so. And from the current thread at least, I am not convinced that
there is a good use case for it.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 03:36:12 -0500

Hello Jari,
Sorry for taking so long before getting back to you. Please see
responses inline.

Regards,
Ahmad

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, September 14, 2009 5:41 AM
> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli
> Cc: [email-masked]
> At this point we are only changing the document if there's a 
> technical problem somewhere.
[Ahmad]
Thanks! 
I believe features that already had the wg consensus are not supposed to
be removed for the sake of just removing it or because all of a sudden
some people believe it is not necessary. Unless, there is a technical
issue and problem in the respected functionality (something broken),
IMO, it should not be removed.

> 
> That being said, I believe there were/are issues in the rules 
> that specify when a BRA is going to be sent. So something has 
> to be fixed in any case. 
[Ahmad]
IMO, they are not technical issues that breaks the protocol. I believe
we received good comments from Ben to clarify few points about the
protocol handling and setting of the Acknowledge (A) bit. These
clarifications have been agreed upon and the next revision will captured
all of these clarifications.

> The fix can be:
> 
> 1. Make it clear what the rules are, and ensure that the 
> rules are logically consistent. RFC 3775 Section 9.5.4 should 
> be default approach, and I don't really see no reason to 
> deviate from that approach if we have the A bit to begin 
> with. 
[Ahmad]
What I am struggling with here is: in MIP6, the message exchange is
usually between the MN and the HA or the MN and the CN; with the BA
always coming from either the HA or the CN. However, in the case of
Binding Revocation, every single node may send or receive a BRA; except
the MN which always send a BRA.

May be the right approach is: after addressing all of Ben's comments, it
would be good if we can identify what is missing? Or what is NOT there
that breaks the protocol. That will be a great help.

> I'm not sure I like the rules that mix G and A bits; I 
> would rather keep separate things separate. 
[Ahmad]
Hmmm... I am not sure we should call it mixing:) Because what would you
call the following text in RFC3775:
"
   ..............................................  .............. After
   selecting a new primary care-of address, the mobile node MUST send a
   Binding Update containing that care-of address to its home agent.
   The Binding Update MUST have the Home Registration (H) and
   Acknowledge (A) bits set .."

Is that mixing the (H) and (A) bits?

IMO, in order to have a robust and sane protocol, crucial and critical
scenarios need to be identified and explicit recommendation is needed.
In the whole binding revocation draft, there is only one case that the
Acknowledge (A) bit setting is mandated when another bit is set. It is
when the BRI has the capabilities to wipe out all of the BCEs between
the MAG and its LMA peer, or vice versa. I believe that scenario is
crucial and critical enough for this specification to make sure that the
sending node REQUEST a BRA back by setting the (A) bit.

> In any case, what 
> the specific issues Ben and Vijay raised need to be fixed.

[Ahmad]
I guess, we need to separate between the two sets of comments. Ben's
comments has the following basic logic, the (A) bit should have the
authoritative power to mandate the receiving node to send back a BRA.
That is actually a good comment and all of my debate with Ben was on the
cases when the receiving node is NOT able to send a BRA, in this case,
it is the mobile node. Even that one, we closed it too!

However, with respect to Vijay's comments, He is raising comments
against text that have the wg consensus and I disagree that these are
issues to start with before thinking of whether they need to be fixed or
not. Here they are:

1. Removing the (A) bit from the BRI and BRA and assume that the (A) bit
is always set and a BRA is mandated for each BRI. (I DISAGREE, please
see below)

2. If we have a careless implementation that sent a BRI with the (G) bit
set and the revocation trigger value "Per-Peer Policy" and the (A) bit
is NOT set (against the specification recommendation), Vijay wants the
receiving node to send a BRA with status error or in his late posting to
use ICMP error message. Neither one should work. IMO, a BRA MUST NOT be
SENT because the sending node does NOT expect one! Now, we can agree on
whether the receiving node discard the message or accept it, I am open
for either one, but I favor discarding it. In order to make sure that
the sending node take a note and make sure that if it needs this to
work, the (A) bit needs to be set. 
IMO, A CARELESS SENDING NODE SHOULD NOT BE REWARDED!:)

3. The issue of Alternate care of address use. Well, the text was
clarified based on specific questions from Ben. The clarification text
did not change any functionality or add anything new other than spell
out what everyone knows. Vijay raised the issue that in case of MIP6,
the source address of the IPv6 packet that carried the BU with Alternate
Care-of address option included, MAY become invalid, that because this
mechanism is used as a pre-registration mechanism to register a new
care-of address by sending a BU from the old Care-of address. Honestly,
I am not sure of the validity of this usecase in the scope of MIP6
(RFC3775). IMO, pre-registration needs to be clearly signaled to the HA.
Because, how the HA would know when the source IP address becomes
invalid? Although, it has just sent the BA to that address! 

> 
> 2. Remove the A bit and make the spec simpler. 
[Ahmad]
I disagree that will make the protocol simpler. It rather makes the
protocol incomplete!
Binding revocation covers a wide range of usecase that all of them CAN
NOT be treated with the same severity. The funny thing here is that for
sometime people argued on the ml that Binding Revocation can be
addressed via a generic notification (send it and forget about it) and
all of a sudden, we are going to the other extreme! Binding revocation
is always authoritative and critical and a BRA MUST be sent all the
time. That is a very rigid approach which lacks the full realization of
the binding revocation usecases. 

NOT only that, but a protocol which is used for creating a new BCE
(MIP6) uses the (A) bit optionality while a protocol which allows the
home anchor point to release the resources of a mobile node session, all
of a sudden MUST be as rigid as a rock and a BRA is ALWAYS sent back! 

I can go on and on with respect to this but, IMO, this is a recipe for
killing creativity and the chance for implementations to differ from one
another. Those implementations which fall in love with assuming the (A)
bit is set all the time can simply make the choice to set the (A) bit in
every BRI message and be ready for retransmission. That is absolutely
fine and is currently allowed by the protocol.

> I do not 
> personally believe the flexibility is useful in this context, 
> so I do not object to removing it. However, given that we are 
> so far in the process, we should not do this change if there 
> are people who are opposing it. 
[Ahmad]
Please see comments above.

> Ahmad, since you were the one 
> arguing that there is a need, can you re-think this in view 
> of whether your objections are about real-live business needs 
> or reducing late changes? If its more about the latter, maybe 
> the right thing is to get rid of the bit.

[Ahmad]

In simple words, I respectfully disagree. Let me explain why.
As I mentioned above, Binding Revocation mechanism addresses a wide
range of usecases with various severity and consequences. Some of which
are documented in the draft and many others are not. WHY when the LMA/HA
would like to revoke a BCE of an important fellow needs to handle that
as when revoking the BCE of NO-ONE-KNOWS-ABOUT-COPPER=USER-X? Sending a
BRI message with the (A) bit cleared in certain cases, reduces
signaling, retransmission, and makes a lot of sense. 

Best Regards,
Ahmad

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 16 Sep 2009 13:46:28 -0400

Hello,

I was asked to post the text for the changes I would like to see for
fixing the issue of using the altCoA option with the BRI message and
sending the BRI message to an old CoA that may not be valid. So here are
the changes I would like to see.

In section 7.1 (HA sending a BRI)

OLD:

NEW:

   o  The destination address for the Binding Revocation Indication 
      message SHOULD be set to the Care-of Address stored in the 
      corresponding binding cachen entry.

In section 8.1.1 (LMA sending a BRI)

OLD:

   o  The care-of address for the binding MUST be used as the
      destination address in the packet's IPv6 header, unless an
      Alternate Care-of Address mobility option is included in the
      Binding Revocation Indication message.  If an Alternate Care-of
      Address option is included in the Binding Revocation Indication
      message, the destination address in the packet's IPv6 header
      SHOULD be set to the source IP address of the packet that carried
      the latest successful Proxy Binding Update with the Alternate
      Care-of address included.

NEW:

   o  The destination address for the Binding Revocation Indication 
      message SHOULD be set to the Proxy Care-of Address stored in 
      the corresponding binding cachen entry.

In section 5.1, delete the following.

   o  Alternate Care-of Address mobility option [RFC3775].  This option
      MAY be included to indicate the Care-of Address of the mobile
      node's binding that is being revoked.  In the case when the Global
      (G) bit set, this option identifies all the mobility bindings that
      share the same care-of address.  Additionally, if the Global (G)
      bit set, more than one Alternate Care-of Address mobility options
      MAY be present in the Binding Revocation Indication message.

In section 8.2.1, delete the following.

      However, if one or more Alternate Care-of Address
      options are included in addition to the mobile node identifier
      option, the local mobility anchor MUST revoke all mobile nodes
      bindings which proxy Care-of Address matches one of the Care-of
      address(es) in the Alternate Care-of Address option(s).

In section 9.2.1, delete the following.

      In addition, the mobile
      access gateway MAY include one or more Alternate Care-of Address
      option(s).  The Alternate Care-of Address option(s) contain the
      proxy Care-of address(es) the bindings of which are being impacted
      by this Binding Revocation Indication message.   

Regards,
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Sep 2009 10:50:39 -0700

Hi Ahmad,

Many time such errors are used either to do bad configuration or an
implementation missing something. When the MAG does not set the 'A' bit when
the 'G' bit is set, it does mean it is a "kludgy" implementation. :) So the
right behavior for a node that receives this BRI is to send an error back.
Not silently drop the BRI message.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 16 Sep 2009 11:19:49 -0700

Hi Ahmad, Jari,

> IMO, A CARELESS SENDING NODE SHOULD NOT BE REWARDED!:)

It is not about a care less implementation being rewarded. It is about
returning a appropriate error response whenever possible. It makes it very
hard to debug an issue, if the signaling messages are discarded silently.
IMHO, in general signaling message should never be silently discarded,
unless you detect a DoS attack.

> invalid? Although, it has just sent the BA to that address!

See the following text in RFC 3775.

   Normally, a Binding Update specifies the desired care-of address in
   the Source Address field of the IPv6 header.  However, this is not
   possible in some cases, such as when the mobile node wishes to
   indicate a care-of address which it cannot use as a topologically
   correct source address (Section 6.1.7 and Section 11.7.2) or when the
   used security mechanism does not protect the IPv6 header (Section
   11.7.1).

It has always been possible for a mobile node to register a new CoA with the
HA before attaching to the subnet where the new CoA is valid. This was
explicitly discussed when RFC 3775 was being standardized. The text above,
which talks about binding a care-of address that cannot yet be used by the
mobile node as a topologically correct source address, supports the scenario
I am talking about.

FMIPv6 is another protocol that makes use of this.

So please don't dismiss it.

> fine and is currently allowed by the protocol.

You haven't yet explained an use case, where it would be beneficial not to
request an acknowledgement for a BRI message. Considering that, it would
make sense to remove the 'A' bit.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 16:29:27 -0500

Hi Vijay,

> Sent: Wednesday, September 16, 2009 1:20 PM
> To: Muhanna, Ahmad (RICH1:2H10); Jari Arkko
> Cc: [email-masked]
> > 2. If we have a careless implementation that sent a BRI 
> with the (G) 
> > bit set and the revocation trigger value "Per-Peer Policy" 
> and the (A) 
> > bit is NOT set (against the specification recommendation), 
> Vijay wants 
> > the receiving node to send a BRA with status error or in his late 
> > posting to use ICMP error message. Neither one should work. 
> IMO, a BRA 
> > MUST NOT be SENT because the sending node does NOT expect 
> one! Now, we 
> > can agree on whether the receiving node discard the message 
> or accept 
> > it, I am open for either one, but I favor discarding it. In 
> order to 
> > make sure that the sending node take a note and make sure 
> that if it 
> > needs this to work, the (A) bit needs to be set.
> It is not about a care less implementation being rewarded. It 
> is about returning a appropriate error response whenever 
> possible. 
[Ahmad]
WELL, the sending node does not track the outstanding BRI unless it sets
the (A) bit. Sending a response in this case nothing but spaghetti not a
sound signaling protocol. We keep unnecessarily, IMO, arguing the same
point again and again. May be it is a standard practice that we keep
arguing for at least a couple of weeks:)

> It makes it very hard to debug an issue, if the 
[Ahmad]
Very interesting!:)
The sending node is saying that I do not care about a response in this
case and I do not want to see a BRA, Not only that, but the sending node
also says BTW: I am NOT tracking a response either. But, you are still
expecting to see a trace of a returned BRA on your box which *violated*
the specification? What kind of logic is this? Again, that is
categorized as rewarding sloppiness and bad implementations! Not good.

> signaling messages are discarded silently.
> IMHO, in general signaling message should never be silently 
> discarded, unless you detect a DoS attack.
[Ahmad]
NOT TRUE. Just as one example, Check RFC3775 a BA is NOT returned in
other cases.
BTW: if we are fighting against certain wording, we can change the text
of "silently discard the message" to "The receiving node SHOULD NOT send
a BRA" 

Would that help in here?

> > the source address of the IPv6 packet that carried the BU with 
> > Alternate Care-of address option included, MAY become invalid, that 
> > because this mechanism is used as a pre-registration mechanism to 
> > register a new care-of address by sending a BU from the old Care-of 
> > address. Honestly, I am not sure of the validity of this usecase in 
> > the scope of MIP6 (RFC3775). IMO, pre-registration needs to 
> be clearly signaled to the HA.
> It has always been possible for a mobile node to register a 
> new CoA with the HA before attaching to the subnet where the 
> new CoA is valid. This was explicitly discussed when RFC 3775 
> was being standardized. The text above, which talks about 
> binding a care-of address that cannot yet be used by the 
> mobile node as a topologically correct source address, 
> supports the scenario I am talking about.
> 
[Ahmad]
No problem, Just not to keep arguing this case, IMO, I do not think that
is the best way to define pre-registration and how it should work. But,
I am fine to update the case of *MIPv6* to always send the BRI message
to the primary care of address. 

Is that acceptable? Does it close this one?

> > NOT be treated with the same severity. The funny thing here is that 
> > for sometime people argued on the ml that Binding Revocation can be 
> > time. That is a very rigid approach which lacks the full 
> realization 
> > of the binding revocation usecases.
> > 
> > home anchor point to release the resources of a mobile node 
> session, 
> > all of a sudden MUST be as rigid as a rock and a BRA is 
> ALWAYS sent back!
> > 
> > killing creativity and the chance for implementations to 
> differ from 
> > one another. Those implementations which fall in love with assuming 
> > the (A) bit is set all the time can simply make the choice 
> to set the 
> > (A) bit in every BRI message and be ready for 
> retransmission. That is 
> > absolutely fine and is currently allowed by the protocol.
> 
> You haven't yet explained an use case, where it would be 
> beneficial not to request an acknowledgement for a BRI 
> message. Considering that, it would make sense to remove the 'A' bit.
[Ahmad]
Very interesting!
If I remember correctly, you also did not see the usecase for binding
revocation not to be sent as a generic notification one for some time:) 
What I can not understand is: If you care about having the (A) bit being
set all the time, why just NOT make sure that your implementation does
that all the time and move on.

On the other hand, If what I mentioned above is not a valid usecase for
you, I yet to see any technical argument that proves the (A) bit set is
breaking the protocol and needs to be removed.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 19:25:53 -0500

Hello Vijay,

I have no problem with the proposed text under section 7.1. and 8.1.1.,
if the WG ACCEPT! :)
Please see more inline.

Regards,
Ahmad

> Sent: Wednesday, September 16, 2009 12:46 PM
> Subject: RE: [MEXT] I-D 
> I was asked to post the text for the changes I would like to 
> see for fixing the issue of using the altCoA option with the 
> BRI message and sending the BRI message to an old CoA that 
> may not be valid. So here are the changes I would like to see.
> 

[Ahmad]
Although, I believe the case of pre-registration you mentioned about
RFC3775 is NOT applicable to Proxy MIP6, but I am fine pending the WG
consensus.

>       by this Binding Revocation Indication message.  

[Ahmad]
The text in the above three sections were based on a lot of discussion
on the mailing list. I am not sure if you followed that discussion; But
the idea was as follows:

When the (G) bit is set, it may impact many different mobile nodes.
Those mobile nodes MAY have different pCoA served by the same MAG. In
order to identify these sessions at the LMA, the MAG includes all pCoA
that have sessions with its LMA peer and needs to be revoked. In other
words, this will allows the LMA to lookup all these session based on
these pCoA. NOW: If these is only one pCoA for all of these sessions,
the Alt care-of address is NOT used. I am not sure if you had this in
mind when you suggested deleting these texts.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Sep 2009 00:49:26 -0500

Hi Vijay,

I agree with you if the (A) bit is set, the receiving node MUST send an
error if it rejects the BRI. Sending a BRA when the (A) bit is NOT set
does not help and does not solve the problem of this *kluggy*
implementation.

Please see my other email in which I proposed to replace silently
discard the message with "the receiving node SHOULD NOT send a BRA" and
let me know if that is good enough. I am also open for the idea to let
the receiving node accept the BRI, i.e., execute the BRI with (G) bit
set, but since the (A) bit was NOT set, the receiving node SHOULD NOT
send a BRA.

Hopefully, we can close on this one.

Regards,
Ahmad

> Sent: Wednesday, September 16, 2009 12:51 PM
> Many time such errors are used either to do bad configuration 
> or an implementation missing something. When the MAG does not 
> set the 'A' bit when the 'G' bit is set, it does mean it is a 
> "kludgy" implementation. :) So the right behavior for a node 
> that receives this BRI is to send an error back.
> >> The LMA should either send a ICMP error (parameter problem with 
> >> offset set to the flags field)
> > 
> > [Ahmad]
> > 1.  Erroneous header field encountered, 2.  Unrecognized 
> Next Header 
> > type encountered, OR 3.  Unrecognized IPv6 option encountered
> > 
> > Which one of these?
> >> with an error status that says the message was nor 
> processed because 
> >> the flags are inconsistent.
> > [Ahmad]
> > As I said earlier,
> > 2. As the MAG did NOT set the (A) bit, it is ASKING the LMA NOT to 
> > send back a BRA; unless we would like to second guess what the MAG 
> > should have done or intended to do. An implementation that does NOT 
> > follow the specification and we need to have this specification 
> > customized to address that implementation short coming.
> > 
> > 3. Even, if the LMA sends a BRA, the MAG will never be able to 
> > intercept it, unless, again, this MAG is a kluge 
> implementation that 
> > does not follow the protocol by NOT setting the (A) bit BUT at the 
> > same time it waits for a BRA!
> >

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Sep 2009 11:36:23 +0300

Vijay, Ahmad,

> does not help and does not solve the problem of this *kluggy*

I don't think we should use different design criteria in the same 
protocol family. Right or wrong, RFC 3775 took the approach that if 
there's an A bit, then acknowledgments are sent if the bit is set and 
are also sent if there's a serious error.

You can construct various arguments about what the right approach is -- 
I think both positions can be supported by rational arguments. However, 
if we keep the A bit, I think the behaviour should not be radically 
different from RFC 3775.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Sep 2009 13:37:32 +0300

Ahmad,

> all of these clarifications.

That's good, but the point is that there were and possibly are 
clarifications. Draft -12 says, for instance about bulk revocation:

"If the local mobility anchor processes the Binding
Revocation Indication message successfully and the Acknowledge (A)
bit is set, the local mobility anchor responds to the mobile access
gateway by sending Binding Revocation Acknowledgement message."

Does this mean that if an error is detected, no Ack is sent? Maybe this 
is specified somewhere else, but on quick read I didn't find that. 
Obviously, we need an Ack in this case...

If you think about the situation as a table, have you specified what 
happens with a all combinations of
- success / error in processing the message
- A bit set / not set
- G bit set / not set

> Is that mixing the (H) and (A) bits?

It is... but in my opinion not a great example to follow.

> signaling, retransmission, and makes a lot of sense.

Fair enough. That's a use case for the A bit.

To explain my personal position a little bit better: I feel that the use 
cases that I've seen are more in the class of nice to have than 
something that would be absolutely required. The added complexity is not 
in my opinion worth the trouble.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Sep 2009 08:31:28 -0500

Hi Jari,

> Sent: Thursday, September 17, 2009 5:38 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [email-masked]
> > clarifications have been agreed upon and the next revision will 
> > captured all of these clarifications.
> >   
> 
> That's good, but the point is that there were and possibly 
> are clarifications. Draft -12 says, for instance about bulk 
> revocation:
> 
> Revocation Indication message successfully and the 
> Acknowledge (A) bit is set, the local mobility anchor 
> responds to the mobile access gateway by sending Binding 
> Revocation Acknowledgement message."
> 
> Does this mean that if an error is detected, no Ack is sent? 
> Maybe this is specified somewhere else, but on quick read I 
> didn't find that. 
[Ahmad]
Sure.

> 
> If you think about the situation as a table, have you 
> specified what happens with a all combinations of

[Ahmad]
Sure, let me verify that and make sure that all scenarios are covered.
If not, will add a subsection for sending BRA similar to section 9.5.4
and share with you and list before publishing.

Regards,
Ahmad
> > Hmmm... I am not sure we should call it mixing:) Because what would 
> > you call the following text in RFC3775:
> > "
> > range of usecases with various severity and consequences. Some of 
> > which are documented in the draft and many others are not. WHY when 
> > the LMA/HA would like to revoke a BCE of an important 
> fellow needs to 
> > handle that as when revoking the BCE of 
> > NO-ONE-KNOWS-ABOUT-COPPER=USER-X? Sending a BRI message 
> with the (A) 
> > bit cleared in certain cases, reduces signaling, 
> retransmission, and makes a lot of sense.
> >   
> 
> To explain my personal position a little bit better: I feel 
> that the use cases that I've seen are more in the class of 
> nice to have than something that would be absolutely 
> required. The added complexity is not in my opinion worth the trouble.
> 
> Jari
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Sep 2009 08:36:32 -0500

Hi Jari,

> Sent: Thursday, September 17, 2009 3:36 AM
> > implementation missing something. When the MAG does not set the 'A' 
> > bit when the 'G' bit is set, it does mean it is a "kludgy" 
> > implementation.  :)  So the right behavior for a node that 
> receives this BRI is to send an error back.
> > I agree with you if the (A) bit is set, the receiving node 
> MUST send 
> > an error if it rejects the BRI. Sending a BRA when the (A) 
> bit is NOT 
> > set does not help and does not solve the problem of this *kluggy* 
> > implementation.
> >   
> 
> I don't think we should use different design criteria in the 
> same protocol family. Right or wrong, RFC 3775 took the 
> approach that if there's an A bit, then acknowledgments are 
> sent if the bit is set and are also sent if there's a serious error.
[Ahmad]
I agree. 
I understand serious error is the case when the sending node has a state
that will continue to be in error and out of sync until it receives a
response to indicate and help correct that state. RFC3775 mentioned
three examples where none of them is applicable to the current Binding
Revocation; an expired nonce, sequence number being out of window, and
insufficient resources.

> 
> You can construct various arguments about what the right 
> approach is -- I think both positions can be supported by 
> rational arguments. However, if we keep the A bit, I think 
> the behaviour should not be radically different from RFC 3775.
{Ahmad]
I agree.
In addition of what I mentioned in my other email response for making
sure all cases are covered or adding a subsection similar to 9.5.4. in
RFC3775, I would like to address the specific case Vijay raised as
follows:

Under section 8.2.1.

OLD TEXT:
=========

NEW TEXT:
=========

   o  If the Global (G) bit is set and the Revocation Trigger field
      value is "Per-Peer Policy", the LMA MUST validate that the Proxy
      (P) bit is set and the MN-ID option is present with the mobile
      access gateway identity included.  In addition, the local mobility
      anchor MUST verify that the identified mobile access gateway as
      per the value in the MN-ID option is authorized to use the global
      revocation with revocation trigger value "Per-Peer Policy", see
      Section 13. If the local mobility anchor processes the Global
Binding
      Revocation Indication successfully and the Acknowledge (A) bit is
set, 
      it MUST send a successful Binidng Revocation Acknowledgement
message.
      However, if the Acknowledge (A) bit is not set, the local mobility

      anchor SHOULD accept the message and it SHOULD NOT send a Binding
      Revocation Acknowledgement message.

Hope this addresses this specific issue.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Sep 2009 16:50:42 -0700

Hi Ahmad

Thanks.

> mind when you suggested deleting these texts.

If the MAG uses multiple proxy care-of addresses, one proxy CoA for a set of
mobility sessions, how does the LMA know that these proxy CoAs belong to the
same MAG? There is nothing in the Proxy Binding Update.

In the scenario above, wouldn't the LMA send one BRI per set of mobile nodes
(or actually a set of mobility sessions) with the 'G' bit set?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 17 Sep 2009 16:57:39 -0700

Hello,

> in my opinion worth the trouble.

IMO, it is actually not a "nice to have" feature. I don't see anyone sending
a Binding Update without the 'A' flag set or a BRI message with the 'A' flag
is set. It is just unnecessary text in the specification. And in some cases,
it is not correctly specified. Sure, we can fix all these, but a simpler
option would be to avoid having these issues. :)

It is not too late to simplify the binding revocation mechanism by just
removing the 'A' flag.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 21 Sep 2009 14:44:46 -0500

Hi Vijay,

> Sent: Thursday, September 17, 2009 4:51 PM
> >>       (G) bit set, this option identifies all the mobility 
> bindings 
> >> that
> > on the mailing list. I am not sure if you followed that discussion; 
> > But the idea was as follows:
> > 
> If the MAG uses multiple proxy care-of addresses, one proxy 
> CoA for a set of mobility sessions, how does the LMA know 
> that these proxy CoAs belong to the same MAG? There is 
> nothing in the Proxy Binding Update.
[Ahmad]
These different pCoA(s) appears in different PBU for different mobility
sessions of different mobile nodes. 
Currently, I believe, the ID for the MAG is the MAG-IP-Address which
could be the pCoA. If the source IP address is not the pCoA, then we
need to include the pCoA in the Alternate CoA in the BRI.

May be we need some clarification on this, we need a note or something
to say that the LMA MUST validate that all the pCoA(s) included in the
BRI are supported by the current MAG or reject the BRI.

> 
> In the scenario above, wouldn't the LMA send one BRI per set 
> of mobile nodes (or actually a set of mobility sessions) with 
> the 'G' bit set?

[Ahmad]
I assume that you meant to say the MAG not the LMA, because in the case
of the LMA, the assumption is the LMA always have the same LMAAddress
and it always appears as the source of the IPv6 packet.

Yes, the MAG can send a single BRI with the (G) bit set for each set of
mobility sessions that share the same pCoA. Even in that case, we still
need to allow the Alternate CoA inside the BRI. On the other hand, if
the LMA is able to verify that the included pCoA(s) do really belong to
that MAG, then it will be more efficient to send a single BRI. In that
case, multiple pCoA(s) are communicated in the BRI using multiple
Alternate Care-of address options.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 26 Sep 2009 20:46:48 -0500

Hi Raj,
Seems that I missed your posting.

Sure, I think we can remove the Acknowledge (A) bit to simplify the
logic as Vijay and Jari suggested.

All,
If anyone feels that we SHOULD not remove the (A) bit, please let us
know now. We are planning to spin a new revision in the next few days,
hopefully before end of day Tuesday.

Regards,
Ahmad

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, September 14, 2009 9:24 AM
> To: [email-masked]; Muhanna, Ahmad (RICH1:2H10); 
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEXT] Acknowledgements for Revocation Messages
> 
> 
> 
> > believe the flexibility is useful in this context, so I do 
> not object 
> > to removing it. However, given that we are so far in the 
> process, we 
> > should not do this change if there are people who are opposing it. 
> > Ahmad, since you were the one arguing that there is a need, can you 
> > re-think this in view of whether your objections are about 
> real-live 
> > business needs or reducing late changes? If its more about 
> the latter, 
> > maybe the right thing is to get rid of the bit.
> 
> I agree with the view that if removing the A bit will 
> simplify the spec, we should do so. And from the current 
> thread at least, I am not convinced that there is a good use 
> case for it.
> 
> -Raj
> 
> > 
> > Jari
> >