Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01)

["Premec, Domagoj" <domagoj.premec at siemens.com>]

> > BTW, I am planning to submit a draft on the Data Plane Address 
> > mobility option, for separation of control and data plane, 
> before the 
> > draft submission deadline. Let me know if you are 
> interested in contributing.
> 
> I still think use of Alt-CoA already accomplishes that and no 
> additional spec is needed. Thank you nevertheless.

The alt-CoA works only in one direction,  MAG->LMA. If the LMA has several blades and would like to load balance between them, we need to specify how this is done in the other direction, too. 

domagoj


> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin at yegin.org] 
> Sent: 21. listopad 2008 10:28
> To: 'Vijay Devarapalli'
> Cc: 'Ahmad Muhanna'; Premec, Domagoj; 'Netlmm'; mext at ietf.org
> Subject: RE: Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment 
> ondraft-ietf-mext-binding-revocation-01)
> 
> Vijay,
> 
> > > I couldn't trace back where the RFC said what you said 
> "the binding 
> > > ack
> > is
> > > always sent to the CoA and not to the source address of 
> the BU. If 
> > > the AltCoA option is used, then the binding ack would go 
> back to the 
> > > address that appeared in the AltCoA option." Wherever it 
> is, it is 
> > > in direct conflict (a BUG) with the text quoted above. 
> Don't you think so?
> > 
> > I am not sure. This should perhaps be clarified in 3775bis. 
> > Practically thinking, the MN should be able to receive the 
> binding ack 
> > irrespective of whether it was sent to the source address 
> on the BU or 
> > to the address in the AltCoA option. It should be perfectly 
> valid for 
> > a HA implementation to send a Binding Ack to the CoA always.
> 
> As Brian said that's not the case for TAHI-tested implementations.
> Besides, according to the following RFC 3775 text, the 
> destination address of BA "MUST be" copied from the source 
> address of BU. The text is clear.
> 
> >>>    If the Source Address field of the IPv6 header that carried the
> >>>    Binding Update does not contain a unicast address, the Binding
> >>>    Acknowledgement MUST NOT be sent and the Binding 
> Update packet MUST
> >>>    be silently discarded.  Otherwise, the acknowledgement 
> MUST be sent
> >>>    to the Source Address.
> 
>  
> > The FBU message in the predictive mode of FMIPv6 is the 
> only scenario 
> > that I know of when the MN sends a BU with the source address being 
> > different from the contents of the AltCoA option. In FMIPv6, the 
> > previous access router sends an FBACK to both the oldCoA 
> and the newCoA.
> > 
> > BTW, I am planning to submit a draft on the Data Plane Address 
> > mobility option, for separation of control and data plane, 
> before the 
> > draft submission deadline. Let me know if you are 
> interested in contributing.
> 
> I still think use of Alt-CoA already accomplishes that and no 
> additional spec is needed. Thank you nevertheless.
> 
> Alper
> 
> 
> 
> 
> 
> 
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext