Re: [Mipshop] Review of Transient Binding Spec

["Koodli, Rajeev" <rkoodli at starentnetworks.com>]

Hi Marco,

A concern is the lack of proper description of the applicability of this
protocol. 
Whereas Appendix B is good, I would like to see a clear statement about
what problem this protocol addresses and where it is applicable.

Please see below..

>> So, I suggest the scope to clearly state that 
>> the draft is primarily about multi-radio handovers.
>>   
> The applicability to single-radio handover is clearly 
> described. The protocol is the same. So why should the 
> protocol specification then limit to single radio handover?
> 

My point is to state that the primary focus is multi-radio, but also
indicate that it may be applicable to single-radio handovers.

Most part of the draft deals with multiple interfaces. There is a
relatively small section on single-radio handovers, and I do not think
that it is comprehensive.


> > 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).
> >   
> I don't see three parts, but maybe you refer to the problem 
> statement section.

Hmm.. I wasn't referring to any particular section but a high-level
summary of the protocol.
If it does more than this please state.

> 
> > 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?
> delay due to radio bearer setup, as covered by the problem statement

If there is delay due to radio bearer set up, why is the MAG sending PBU
prematurely?
Perhaps you have answer below..
 
> >  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.
> this is only a problem in case of single radio handover, 
> where we focus applicability to radio technologies, which 
> provide such forwarding. You don't need forwarding between 
> MAGs, but forwarding between radio access networks (level 
> below MAGs) is sufficient.
> Such use case is described in A.1.
> 

I would at least state this when you first mention how in-transit
packets are handled, and refer to Appendix for the details.


> >  And, for 1), folks have
> > mentioned multiple times that LMA internal mechanisms can handle
this;
> >  
> thath's why we included a stement about 
> implementation-specific solutions in the appendix.

I would like to have a clear statement in the main part of the draft.
We discussed this at the SFO meeting. 


> > 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.
> >   
> We cannot assume the existence of such implementation 
> specifics, as they are not part of the standard. As tehy are 
> also not part of this protocol, I feel that it's more 
> suitable to have this statement in the appendix.
> 

Well, there are people here saying this is feasible! Appendix is good,
but the main part of the ID must have a clear statement. When there are
folks who believe that implementation may be sufficient, it needs to be
properly represented.


> > 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.
> >   
> That's what B.2 decribes.

Okay, but I would like to see it upfront.

> 
> >    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.
> This description is covered in the problem statement...
> 
> >  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. 
> >   
> ..and this is part of the protocol sepcification section. I 
> don't see an advantage to repeat these things in an 
> additional paragraph.
> 

I am asking for a brief section following the Introduction. Not whether
Appendix is good enough or not (for which I have provided separate set
of comments).


> PBU/PBA is used to retrieve the HNP from the LMA. So, nMAG 
> can send the RtAdv with the prefix to the MN after that step. 
> And the MN can perform address configuration only after 
> having receive dthe HNP. That's where the order comes from.
> 

As I pointed out elsewhere, you don't need HNP. The MN only needs to
know it is on the same router for handover purposes. The way it is
currently defined, it looks like the order described is the way it is
supposed to work, which I am questioning.


> > RKo> You mean Transient to Active transition? The word Activation is

> > RKo> in general confusing..
> >   
> The term has been introduced at the beginning and in the 
> terms section. 
> If you know what's behind,
> it should be clear throughout the document. We prefer having 
> a short description of this state change rather than writing 
> always about transition between state A and state B... Did 
> not receive complaints so far.
> 

Well, you have at least Vijay now on the confusing side. It is up to you
if you would like to improve the readability..

> Yes, good point. Maybe we need to add 1-2 more sentences here 
> and maybe also a reference to radios where this problem 
> appears. Or we refer to the use case A1, where we have more 
> text about this.

Ok, I would like to see this..

> Yes, same as above, maybe we have to spend a bit more text 
> about this issue to allow understanding.

Ok.

> > 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.
> >   
> Yes. And Appendix B.2 describes this. However, the protocol 
> has this feature implicit. So, no need to implement this as 
> separate mechanism.
> 

I don't follow.. Are you saying that to handle the uplink packet loss at
LMA, we have to implement this protocol? I hope not.. I am agreeing to
this document assuming that the scope is clearly defined. 

Are you agreeing to reference the ID above?


> 
> > Section 3.2
[snip]
> >
> > RKo> I am still struggling to see why nMAG would prematurely send
PBU
> > to LMA without completing the link-layer and access authentication 
> > procedures.
> >   
> Maybe a misunderstanding, but the text does not say that the 
> nMAG sends the PBU before completing link-layer and access 
> authentication. Let me check again.

Please do so.

> 
> > 3.2.1
> 
> >  "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.
> >   
> True, so we could include "may" here, as there is still the 
> possibility that DAD will or has to be performed. Just for 
> curiosity: What are links of interest?

Well, you should include ".. The MN can configure address configuration
and perform DAD if necessary.."

P-P links are not using DAD. 

> > 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.
> >   
> depends on the bitrate of the data stream. ND buffer has a 
> default size of 3.
> We evaluated this even with larger buffer sizes and the 
> packet loss was very large... even without DAD...And even if 
> you go for huge buffers (costs?) the MN still suffers from jitter.

How many packets arrive from LMA is a function of how soon you send PBU
to the LMA.

You need to be clear about this. There are loose ends here: why is the
PBU being sent in advance? The reason quoted (i.e., retrive HNP) is not
clear to me; it is perhaps sufficient to get an RA from the same
link-local address of the router.

> > 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. 
> >   
> Not sure the MN really thinks. 

:-) Not in the AI sense of course.


> You can implement a lot on the MN, true. 
> But according to the
> standard, it's still the LMA that assigns the HNP. The MN 
> should wait for the assigned HNP before setting up an IP 
> address on the MN's new interface.

I am not referring to anything specific to a MN that's not a standard.

All I am saying is that it can assign the same prefix it already has
since it does not detect a change of router.


> 
> >
> >  "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.
> >   
> the text does not describe an issue with access 
> authentication. It refers to the delay caused by setting up 
> the radio bearer.
> 

Okay. However, you still did not explain why the "acces technology"
needs HNP.


> > 3.2.2
[snip]
> > 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. 
> >   
> Yes, they could and we say that clearly in the Appendix. But 
> as said, there is no need as it comes with the transient BCE 
> extension.
> 

This is where I am having a problem I think. I know I can do this
without transient BCE.
You seem to be saying: "may be but you don't have to". That's a good
seeling point, but we are beyond that now, don't you think? :-)



> > B.1
[snip]
> > 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. 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."
> >   
> Will think about it..

Okay, I would like to see this clearly mentioned.

> 
> >    Therefore, this case can not be addressed by any statically
> >    configured information on the LMA.  
> >
> > Rko> I do not agree.


> >
> > B.3.  Late Switching of Downlink Traffic to nMAG
> >
> > RKo> well, late switching can also be addressed by extending the
> > buffering at the MAG. This should be pointed out here. 
> >   
> Please see above and in the problem statement.
> 

Well, I would like to see better description of 

A) why there is premature update of PBU at the LMA.
B) why HNP is necessary and not an RA from the same link-local address
C) why the radio bearer set up takes more time while PBU is already sent
out.

Thanks,

-Rajeev


> > _______________________________________________
> > Mipshop mailing list
> > Mipshop at ietf.org
> > https://www.ietf.org/mailman/listinfo/mipshop
> >   
> 
> 
>