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

["Alper Yegin" <alper.yegin at yegin.org>]

> > > 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.

If you want to go into such "advanced" scenarios (multi-CoA, load balancing,
etc.) you would need additional specification, of course. But for single CoA
case, I don't see what you need other than standard Alt-CoA usage.

Alper



> 
> 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