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

From: [email-masked]
Date: Wed, 8 Jan 2003 16:51:51 -0500

Rajeev,
I don't understand what you mean by saying CARD is not a protocol.
 There are several ways to implement the various components of the CARD protocol
and having a static map, IMO, is one way to implement the mapping to facilitate L2-L3
translation. Ofcourse, this is a simplistic and clearly not the best way to do it as 
explained in the issues draft.
Hope it is clear now.

-Govind.

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 4:40 PM
To: Krishnamurthi Govind (NRC/Boston)
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
interworking

[email-masked] wrote:

> Rajeev,
>
> What you describe as alternatives is just ways of performing CARD IMO, each one having pros and cons. One of the  functionalities of CARD (however you do it) is to fill up this mapping table.
> Doing it statically is just one way of doing it.
>

OK, if CARD means a set of options to chose from and not _a_ protocol, then
I agree with you. My impression was CARD is a protocol in works.

-Rajeev

>
> Govind.
>
> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Wednesday, January 08, 2003 1:01 PM
> To: Krishnamurthi Govind (NRC/Boston)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mobile-ip] RE: [Seamoby] CARD - FMIPv6 protocol
> interworking
>
> Govind,
>
> [email-masked] wrote:
>
> >
> > [Govind] What you describe there are carriers that take the messages from
> > and to the MN. I don't think anyone is discounting the fact that
> > if FMIPv6 is available and is adapted to the needs of CARD these
> > messages can be used as carriers. However, CARD also talks about
> > capabilities discovery and mapping capabilities to the requirements
> > of the MN. Also, FMIPv6 needs "something" to fill in the mapping
> > from link layer id to L3 id. CARD does that.
>
> This is not an accurate characterization. FMIPv6 can work without CARD.
> How the map containing the [AP-ID, AR-prefix] tuple is computed on the
> access router is orthogonal to the operation of FMIPv6. One could use CARD
> or static configuration, or any link state routing protocol (with extensions)
> for
> that matter to compute the map.
>
> -Rajeev
>
> >
> >
> > Are there other consumers, usage scenarios of CARD?
> > [Govind] Several potential uses are listed in the issues draft.
> >
> > alper
> >
> > > 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
> > >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 08 Jan 2003 14:44:36 -0800

> explained in the issues draft.

I don't mean to drag along this.. We disagree on whether static configuration
is part of a protocol. So, let's conclude.

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 08 Jan 2003 14:44:36 -0800

Thanks,

-Rajeev