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

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

Hi Vijay,


> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]] 
> Sent: Friday, September 11, 2009 5:19 PM
> To: Muhanna, Ahmad (RICH1:2H10); [e-mail]
> Subject: Re: [MEXT] I-D 
> Action:draft-ietf-mext-binding-revocation-12.txt
> 
> Hi Ahmad
> 
> On 9/11/09 3:12 PM, "Ahmad Muhanna" wrote:
> 
> 
> >> 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.
> 
> 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.

> 
> Vijay
> 
> > 
> > Hope it is clearer this time.
> > 
> > Regards,
> > Ahmad
> > 
> >> 
> >> Vijay
> >> 
> >>> 
> >>> Regards,
> >>> Ahmad
> >>> 
> >>>> 
> >>>> Just removing the 'A' bit would help. :)
> >>>> 
> >>>> Vijay
> >>>> 
> >>>>> 
> >>>>> Regards,
> >>>>> Ahmad
> >>>>> 
> >>>>>> 
> >>>>>> 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
> >>>>>> 
> >>>>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> 
>