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

["Ahmad Muhanna" <[e-mail]>]

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]] 
> Sent: Friday, September 11, 2009 1:00 PM
> Subject: Re: [MEXT] I-D
Action:draft-ietf-mext-binding-revocation-12.txt
> 
> Ahmad
> 
> On 9/11/09 4:10 AM, "Ahmad Muhanna" wrote:
>  
> >> 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.
> 
> 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.
> 
> > 5. During the IESG review there was an explicit comment to 
> make this 
> > compromise clear in the document and that what I did.
> 
> Of course. The current text was too vague. :)
> 
> >> 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.
> 
> 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 
> > always work as intended.
> 
> You are assuming that the MN will do something in addition to 
> what is specified in RFC 3775. Won't work.
> 
> Vijay
> 
> > 
> > 
> >> 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
> > 
> >> 
> >> Section 8.1.1 also has similar text. I have issues with that too.
> >> 
> >> Vijay
> >> 
> >> 
> >> On 9/9/09 11:58 PM, "Ahmad Muhanna" wrote:
> >> 
> >>> 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: [e-mail] [mailto:[e-mail]]
> >> On Behalf
> >>>> Of [e-mail]
> >>>> Sent: Thursday, September 10, 2009 1:45 AM
> >>>> To: [e-mail]
> >>>> Cc: [e-mail]
> >>>> Subject: [MEXT] I-D
> >> Action:draft-ietf-mext-binding-revocation-12.txt
> >>>> 
> >>>> 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-re
> >>> vocation-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.
> >>>> 
> >>> _______________________________________________
> >>> MEXT mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mext
> >> 
> >> 
> 
>