Re: [Mipshop] Review of Transient Binding Spec

[Vijay Devarapalli <vijay at wichorus.com>]

Hi Ahmad,

Lets keep the discussion just technical please. I am sure there is a better
way to respond than just saying "you don't understand" or you need to read".

Lets try to come up with some text that says that the problem can be solved
with implementation specific mechanisms at the LMA and buffering at the nMAG
when the L2 is not setup. But this document proposes a mechanism that
addresses the problem better.

Vijay


On 8/17/09 4:35 AM, "Ahmad Muhanna" wrote:

> Hi,
> inline.
> 
> Regards,
> Ahmad
> 
>>  
>> Hi Vijay, All,
>> 
>> I have reviewd the draft.
>> 
>> It is generally well-written.
> [Ahmad]
> Hmm..... That's good.
> 
>> I do have several comments.
>> 
>> First, the draft scope. It is claimed that it handles
>> intra-technology (i.e., single radio) handovers. But, the
>> draft is primarily about multi-interface handovers. There is
>> a sub-section 3.1, but the focus is mostly on multi-interface
>> handovers (I do have several comments on 3.1 below). So, I
>> suggest the scope to clearly state that the draft is
>> primarily about multi-radio handovers.
> 
> [Ahmad]
> I think the scope of this draft and work item have been discussed many
> times and agreed upon. Let us move on.
> 
>> 
>> Second, there are three main parts in this ID: 1) handling
>> uplink packets at the LMA during transition from one i/f to
>> another, 
>> 2) handling downlink packets arriving at the nMAG
>> and, 3) forwarding packets to pMAG (and when to switch path).
>> 
> [Ahmad]
> See Marco response.
> 
>> Is 2) applicable only in scenarios where address
>> configuration at the MN takes longer than PBU/PBA signaling?
>> If not, what other scenarios are there? For 3), there is
>> still an issue with in-transit packets being sent towards old
>> Proxy-CoA when the LMA changes path to the nMAG. These
>> packets can only be forwarded if there is some form of
>> forwarding from pMAG to nMAG; this needs to be mentioned.
>> And, for 1), folks have mentioned multiple times that LMA
>> internal mechanisms can handle this; although there is some
>> good discussion in Appendix B (parts of which I don't agree
>> with), I am missing is a clear Applicability Statement in the
>> main part of the ID, perhaps following the Introduction.
>> 
>> My suggested text:
>> 
>> X. Applicability
>>    
>>    There can be packet loss at the LMA when the BCE is updated with a
>>    new Proxy-CoA address and in-transit packets continue to arrive
>>    with old Proxy-CoA address. This can be handled internally at an
>>    LMA as implementation-dependent mechanism, e.g., by accepting
>>    packets for both Proxy-CoA addresses for a short period of
>>    time. However, some deployments may prefer an explicit signaling
>>    mechanism to avoid packet loss at LMA. In such cases, the protocol
>>    specified here is applicable.
> 
> [Ahmad]
> We have discussed this many times and if you still do not understand any
> specifics, you always can seek clarification to what you do not
> understand. IMO, this is nothing but a waste of time and a recipe for
> delaying this draft which is NOT acceptable. Appendix B clearly captures
> the applicability of the usecases of this draft. If you have anything to
> improve this appendix, you are welcome to provide your CLEAR COMMENTS.
> Second, if you have a problem understanding the difference between the
> different cases, you probably can refer to the many times this have been
> discussed on the mailing list. The last one, my clarification response
> to Vijay's clear comments on Appendix B.
> 
>> 
>>    Similarly, there can be packet loss in the downlink when the PMIP6
>>    signaling and MN-internal mechanisms, such as address
>>    auto-configuration, cannot be synchronized. As compared to MIP6, a
>>    MN is not in charge of initiating Binding Update based on its
>>    interface readiness. This can cause packets to arrive at the new
>>    MAG when the MN may not have completed its address
>>    configuration. In such cases, packet loss can occur if the new MAG
>>    is unable to buffer incoming packets, especially on links where
>>    address resolution [RFC4861] takes place. The protocol specified in
>>    this document provides a better control of sequencing of events
>>    when it is desirable to avoid packet loss in the downlink.
>> 
>>    The detailed comparison of static configuration versus the protocol
>>    specified in this document are specified in Appendix B.
>> 
> [Ahmad]
> Please see Marco's responses.
>   
>> More comments.. (Sorry cut and paste makes it look longer)
>> 
>> Section 1:
>> 
>>    "In case the LMA prematurely
>>    forwards packets towards the mobile node's new interface, some
>>    packets may get lost or experience major packet delay."
>> 
>> RKo> It is not clear why LMA would prematurely forward packets. Under
>>    what conditions does PBU reach LMA when the interface on the MN is
>>    not set up? This unfolds only later where there can be PBU/PBA
>>    signaling ahead of address configuration.
>> 
>> Section 2.2
>> 
>>  o  Activation of a Transient Binding Cache Entry.  Initiates leaving
>>       the transient state of a Binding Cache Entry to become active.
>> 
>> RKo> You mean Transient to Active transition? The word
>> Activation is in
>> general confusing..
>> 
>> 3.1.  Handover using a single interface
>> 
>>    "In some active handover scenarios, it is necessary to prepare the
>>    handover target MAG prior to the completion of the link layer
>>    handover procedures.  Packets sent by the LMA to the target MAG
>>    before the completion of the link layer handover procedure will be
>>    lost or need to be buffered."
>> 
>> RKo> The normal sequence of operation is that the link-layer comes up,
>>    followed by the IP-layer signaling. If you mean this is not the
>>    case above, it helps to explain what you mean.
> [Ahmad]
> May be you can understand this more if you think of what PFMIP does in
> preparing the lateral tunnel between MAGs. Instead, this case do the
> preparation with the LMA directly. May be looking/reading at some of the
> referenced documentation in the draft where this case is relevant would
> help.
> 
>> 
>>  " In some systems, the target MAG will be the recipient of uplink
>>    traffic prior to the completion of the procedure that
>> would result in
>>    the PBU/PBA handshake.  These packets cannot be forwarded
>> to the LMA."
>> 
>> RKo> please explain why the packets cannot be forwarded to the LMA. Is
>>    it because the target MAG does not know about the LMA? LMA's BCE
>>    has not been updated yet?
> 
> [Ahmad]
> This is a basic principle in all IP mobility protocols that is mentioned
> in the second paragraph of the Introduction. We felt that there is no
> need to mention this again as it is obvious, however, if it is NOT clear
> to the community, we can repeat the same text here.
> 
>> 
>> "During an intra-technology handover, some of the MN's uplink traffic
>>    may still be in transit through the pMAG.  Currently and as per
>>    PMIPv6 base protocol [RFC5213], the LMA forwards the MN's uplink
>>    traffic received from a tunnel only as long as the source
>> IP address
>>    of the MN's uplink traffic matches the IP address of the mobile
>>    node's registered Proxy-CoA in the associated BCE.  As a result,
>>    packets received at the LMA from the MN's pMAG after the LMA has
>>    already switched the tunnel to point to the nMAG will be dropped."
>> 
>> RKo> This is a general problem with MIP6 and *MIP6 protocols.
>> Please see draft-mitsuya-keep-old-bc-00.txt and reference the document
>>    (as I have mentioned previously). We have discussed how
>> this could be handled as an implementation matter at the LMA.
>> 
> [Ahmad]
> Your comments is confusing. Every time you use this mentioning
> differently! Your previous mentioning reference all cases. You now,
> refer to your mentioning under this case. We mentioned and documented
> several times that we have NO problem with that for this case. This is
> already documented under Appendix B.
> 
> The main thing: Initially all of this was part of the document body and
> based on the wg feedback, we moved it to the Appendix.
> 
>> Section 3.2
>> 
>>   "According to
>>    the PMIPv6 base protocol [RFC5213], the Access
>> Authentication and the
>>    Proxy Binding Update (PBU) are triggered in the access
>> network by the
>>    radio attach procedure, transparently for the MN.  In addition, a
>>    delay for the MN's new interface's address configuration is not
>>    considered in the handover procedure.  As a consequence, the
>>    immediate update of the MN's BCE after the PBU from the
>> MN's nMAG has
>>    been received at the LMA impacts the performance of the
>> MN's downlink
>>    traffic as well as its uplink traffic.  Performance aspects of
>>    downlink as well as uplink traffic during a handover between
>>    interfaces are analyzed in the subsequent subsections."
>> 
>> RKo> I am still struggling to see why nMAG would prematurely send PBU
>> to LMA without completing the link-layer and access
>> authentication procedures.
> [Ahmad]
> Where does it say that the nMAG will send a prematurely PBU?
> 
>> 
>> 3.2.1
>> 
>>  In order to
>>    complete the address auto-configuration on its new
>> interface, the MN
>>    needs to send a router solicitation and awaits a router
>>                                            ^^^^ wait for
>> 
>>  "Upon receiving a router advertisement from the new
>>    MAG, the MN can complete its address configuration and perform
>>    Duplicate Address Detection (DAD) [RFC4862] on the new interface.
>>    Only then the MN's new interface is ready to receive packets."
>> 
>> RKo> DAD may not be performed on all links, especially on links of
>> interest here.
>> 
>> 
>>    "Address configuration can take more than a second to complete.  If
>>    the LMA has already switched the mobile node tunnel to point to the
>>    nMAG and started forwarding data packets for the MN to the nMAG
>>    during this time, these data packets may get delayed or
>> lost because
>>    the MN's new interface is not yet ready to receive data."
>> 
>> RKo> Well, this is not fully drawn out. The packets that arrive at the
>>    nMAG will trigger ND on links where address resolution is
>>    necessary. The nMAG typically buffers the incoming packets until
>>    address resolution completes on such links. The size of
>> the buffer is
>>    implementation-dependent. So, it is not entirely accurate to say
>>    that arriving packets will be lost.
>> 
>>     "However,
>>    delaying the PBU, which is sent from the new MAG to the
>> LMA after the
>>    MN's new interface has attached to the network, is not possible, as
>>    the new MAG retrieves configuration data for the MN from
>> the LMA in.."
>> 
>> RKo> explain or reference what you mean by configuration data. Since
>>   nMAG already went to the LMA, it should have enough information
>>    about the MN already. Please differentiate this from what else that
>>    the nMAG needs from LMA which forces the PBU to be sent earlier.
>> 
>> RKo> I see below that HNP is such a parameter. Without HNP, the MN can
>>    still continue to use the previously assigned HNP, right? From MN's
>>    point of view, if it thinks that it's on the same default router,
>>    it continues to use the assigned/advertised prefix unless NUD
>>    [rfc4861] fails. For this, the MN needs to receive the RA
>> from same link-local
>>    address as before.
>> 
>> 
>>  "In case an access technology needs the MN's IP address or HNP to set
>>    up a radio bearer between an MN's IF2 and the network
>> infrastructure,
>>    the responsible network component might have to wait until the nMAG
>>    has received the associated information from the LMA in the Proxy
>>    Binding Acknowledgment.  Delay in forwarding packets from
>> the nMAG to
>>    the MN's IF2 depends now on the latency in setting up the radio
>>    bearer."
>> 
>> RKo> It is a bit strange that nMAG can determine LMA's address as well
>> as possibly MN-ID (e.g., MN-NAI) through some means but not
>> complete the access authentication.. Such scenarios need to
>> be justified clearly.
>> 
>> 3.2.2
>> 
>> "According to
>>    section 5.3.5 of the PMIPv6 base specification [RFC5213], the LMA
>>    will drop all subsequent packets being forwarded by the
>> MN's pMAG due
>>    to the updated BCE, which refers now to the nMAG as
>> Proxy-CoA.  Thus
>>    make-before-break handover is currently not supported by PMIPv6."
>> 
>> RKo> This is not unique to PMIP (As I mentioned earlier). The
>>    in-transit packets from PCoA will be dropped at the HA when the BCE
>>    is updated with NCoA. So, implementations must be able to handle
>>    this. 
> [Ahmad]
> This funny.
> On one hand, you mentioned that this can be addressed via some static
> configuration. NOW: you say that application should be able to handle
> this. Which point you want to make? Also, everyone knows that
> application can handle missing packets, but, I thought that optimized
> handover is for application that delay/(missing packets) sensitive.
> 
>> 
>> 4.1
>> 
>>  " During the transient state, the LMA accepts uplink packets
>> from both
>>    MAGs, the pMAG and the nMAG, for forwarding.  To benefit from the
>>    still available downlink path from pMAG to MN, the LMA forwards
>>    downlink packets towards the pMAG until the transient BCE gets
>>    activated.  Such downlink forwarding characteristic is denoted as
>>    'Late path switch' (L). "
>> 
>> RKo> You mean by "activated" above, the transient BCE is no longer
>>    used? Because, I would expect the LMA to keep forwarding to the
>>    pMAG until it has a confirmed binding for nMAG. This would be the
>>    normal mode of operation, and if it is called 'Late path switch' in
>>    *MIP6, that's a cool phrase we have not used yet.
>> 
>> 
>>  "This specification considers an optional state during the activation
>>    of a transient BCE with a late path switch, which keeps
>> the pMAG for
>>    some more time as forwarding entry in the transient BCE, solely to
>>    ensure forwarding of delayed uplink packets from the pMAG."
>>  
>> RKo> Late path switch previously refered to downlink packets.. Here it
>>    is 'solely' for delayed uplink packets?
>> 
>> B.1
>> 
>>  "Allowing the LMA to forward the received uplink traffic
>> from the nMAG
>>    to the Internet is a violation of all mobility protocols which.."
>>                          ^^^^^^ ??
>> 
>>  "..require secure signaling exchange between the nMAG and
>> the LMA before
>>    forwarding such traffic to the Internet.  Otherwise, the
>> LMA will be
>>    modifying the mobile node routing entry based on an unsecured data
>>    traffic packet coming from the nMAG."
>> 
>> RKo> This is not accurate. One can expect security association between
>> nMAG and LMA, and that can suffice for the LMA to accept
>> uplink packets from the nMAG.
> [Ahmad]
> That is WRONG understanding! MAY be you need to read what has been
> posted on this mailing list before. Also, Where is that DOCUMENTED? Or
> that your own understanding and interpretation? If that is the case,
> there is no problem, we can move forward. I suggest that you revisit
> your understanding of IP mobility concepts and the REQUIRED security
> between the MAG and LMA for PMIPv6.
> 
>> The above description needs to
>> be reworded.  
>> Perhaps to something like "in deployments where pre-existing
>> trust between the nMAG and the LMA is not sufficient for the
>> LMA to forward uplink packets without first receiving the PBU
>> from the nMAG, this protocol provides a mechanism which can
>> be useful."
> 
> [Ahmad]
> NO. That is NOT Correct. We go with the default Security between the MAG
> and the LMA as per RFC5213. MAY be you have different deployments in
> MIND, that is the exception and we do NOT need to document that here.
> 
>> 
>>    Therefore, this case can not be addressed by any statically
>>    configured information on the LMA.
>> 
>> Rko> I do not agree.
> 
> [Ahmad]
> See above. I guess that is your opinion which I believe is false.
> 
>> 
>> B.2
>> 
>> However, using a statically configured information MAY not address
>>    all handoff circumstances over all types of access networks.
>> 
>> Rko> Why?
> 
> [Ahmad]
> You NEED to READ!
> 
>> 
>> 
>> B.3.  Late Switching of Downlink Traffic to nMAG
>> 
>>    One main use case of transient bindings is the late switching of
>>    downlink traffic routing at the LMA.  This allows to perform IP
>>    mobility protocol signaling between nMAG and LMA
>> independently of the
>>    link layer connectivity, e.g. for interfaces with time
>> consuming link
>>    setup procedure or for a make-before-break handover between
>>    interfaces.
>> 
>>    LMA behaviour according to [RFC5213] does not allow for late path
>>    switching.  LMA according to [RFC5213] can only act upon
>> the Handover
>>    Indicator and has no information on the time of completion of link
>>    layer setup.  Even if an LMA implementation would be configured to
>>    delay the path switching by a fixed time, which would violate
>>    [RFC5213], this would not lead to smooth handover performance but
>>    would even add latency to the handover.  Only additional
>> signaling as
>>    provided by this document provides the information that late
>>    switching is applicable and enables a synchronization of
>> the handover
>>    sequence, .i.e. the switching is adapted both to the
>> finalization of
>>    the link between mobile terminal and nMAG and to the release of the
>>    link between mobile terminal and pMAG, whatever comes
>> first.  Secure
>>    and stable handover performance is achieved.
>> 
>> RKo> well, late switching can also be addressed by extending the
>> buffering at the MAG. This should be pointed out here.
>> _______________________________________________
>> Mipshop mailing list
>> Mipshop at ietf.org
>> https://www.ietf.org/mailman/listinfo/mipshop
>> 
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop