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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Mon, 6 Jan 2003 18:04:54 -0600

Erik,
Please find my inline reply.
Regards,
Ajoy

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

> We have been discussion the possibility of 
> defining CARD signaling as generic ICMP options.
> The idea is to allow piggybacking of 
> the generic ICMP options over any ICMP messages 
> including FMIPv6 messages (ProxyRouterSol and ProxyRouterAdv).
> Do you see any issue this approach? James, has indicated 
> some potential issue in the attached email.  
> I would appreciate your comments.  

I don't have enough context to understand. Is this written
up in an I-D already?

AJOY-> The detailed text is not yet available. But some high-level description 
is available in section 6.1 of http://www.ietf.org/internet-drafts/draft-ietf-seamoby-card-protocol-00.txt. 

I assume you mean Neighbor Discovery options and not ICMP options
since the ICMP message format doesn't have any options.

AJOY-> Yes 

  Erik
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 Jan 2003 21:02:14 +0100 (CET)

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.

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.

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 implementors providing the different protocols for
the same box.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 7 Jan 2003 21:02:14 +0100 (CET)

Erik

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 07 Jan 2003 15:55:53 -0800

Hi Erik,

> flexibility of different implementors providing the different protocols for

I might add that CARD could define options for MN - AR exchange, specify
that the two FMIPv6 messages be used whenever they are available. When FMIPv6
is not available for a CARD implementation, CARD _could_ use the
same format as PrRtSol and PrRtAdv for its carrier.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 07 Jan 2003 15:55:53 -0800

Hi Erik,

-Rajeev