Subject: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol interworking

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 7 Jan 2003 16:57:12 -0600

Erick,
Thanks for your feedback. Please find my 
inline reply. I am also posting this to 
Mobile/IP WG as this may affect 
FMIPv6 protocol. 
Regards,
Ajoy

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Tuesday, January 07, 2003 2:02 PM
To: Singh Ajoy-ASINGH1
Cc: 'Erik Nordmark'; [email-masked]; 'James Kempf'; [email-masked]
Subject: RE: [Seamoby] CARD - FMIPv6 protocol interworking

Part of the tradeoffs with piggybacking has to do with implementation
considerations.
In order to do piggybacking of CARD on e.g. FMIPv6 the same piece
of software needs to implement both protocols. Thus you loose some 
implementation flexibility if you want piggybacking which, depending
on how CARD and FMIPv6 are deployed, might make deployment harder.

For instance, if FMIPv6 is already implemented and deployed by vendor X and Y
but those vendors do not have plans to update their implementations to add
CARD, then you can't really deploy CARD as an add-on piece of software that
people can download.

AJOY-> Good point. So, I guess we should define both generic ICMP options 
as well as the carrier of the generic options (new messages) in the base CARD 
draft. This will eliminate the issue raised by you. Additionally, the FMIPv6 
draft may describe how to piggyback CARD options on FMIPv6 messages. 
This will enable FMIPv6 implementation to take advantage of the 
efficient implementataion of the CARD. I do agree in this case both CARD
and FMIPv6 must be developed by same vendor which is ok. 

But if most people that are going to implement one of the protocols is
going to implement the other as well then this wouldn't be a concern.

AJOY-> I think this will be the most common scenario. Hence, it makes
sense to piggyback CARD options on FMIPv6 messages.
But I guess this is mostly an FMIPv6 issue and probably should be addressed
in FMIPv6 draft. What other's think?

So I think it all depends on whether most people view this as two pieces
of the same protocol, or merely two different protocols operating between
the same set of nodes. In the latter case I think you want the implementation
flexibility of different implementers providing the different protocols for
the same box.

  Erik

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 7 Jan 2003 17:59:58 -0800

We also need to look at the consumer(s) of CARD.
If we are talking about mapping link-layer identifier
of the next access router to its IP address and prefix
information for fast handovers, FMIPv6 protocol already
covers this funcitonality with PrRtSol and PrRtAdv.

Are there other consumers, usage scenarios of CARD?

alper