Subject: [Mipshop] RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 12 Jul 2005 21:34:13 -0500

Hi James, 

I finally managed to read your proposed nhodd draft. 
After reading the draft, I am not really convinced why we need to define a new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I am still trying to understand how the newly proposed draft solves the problem of IEEE 802.21 any better than existing CARD protocol. In my view perhaps taking the CARD protocol to standard track is better idea than trying to invent a new protocol to solve the problem. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Kempf
Sent: Friday, July 08, 2005 11:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

Folks,

I've posted the Neighborhood Discovery draft by Rajeev and myself to the
Internet Drafts directory. Until it is available, you can find it here:

http://www.geocities.com/kempf42/draft-kempf-mipshop-nhood-discovery-00.txt

This is the same draft as I previously posted for Mobopts, except I changed
the filename to reflect the fact that this topic is now going to be
discussed in MIPSHOP (I think, discussion is still ongoing).

This draft is intended to partially fufill the IEEE 802.21 requirement for
network information discovery.

Please send comments if you have any.

            jak

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

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Jul 2005 14:18:23 -0700

Hi Ajoy,

Here is a list of problems Rajeev and I had when we tried to use CARD to
define NED:

- The information source is always an AR. If the source is an "information
server" or an L2 device like an AP but with IP capability, or even involves
an L2.5 transport protocol like EAPoL, then CARD isn't relevent. But let's
suppose you can extract the options out of CARD and try to use them. Then
you run into the problems below.
- Most 802 protocols don't like the CARD format of a bunch of disconnected
blocks of bits. CARD's format was strictly defined by it's transport
mechanism, namely as options over ICMP ND messages. Once you liberate the
application from that transport format, the disconnected blocks format
doesn't make sense anymore. Something like EAP (after which NED is modelled)
does.
- CARD privileges certain network information elements (like resolution of
AP addresses to AR addresses) above others. This is due to the built in
design assumption that the primary application for CARD is a kind of
cross-link ARP or ND to find the router's address (which, by the way,
duplicates what FMIP does). Now, there is no reason to priviledge this
particular application above others in 802.21 InfoElements, and NED doesn't.
All applications use the IANA registry, and must be defined. NED still uses
AP/BS addresses as the initial identifier for the network, because that is
what the host will see so it is really the only way the host can tell the
server what network it is interested in.
- CARD has two ways to do capability querying (preferences and
requirements). I've never seen the logic of having two ways to do the same
thing, and despite the objections of an expert reviewer about the
questionable nature of this design decision when Seamoby was completing the
draft, the WG opted to include both in the final design.
-  CARD handles fragmentation of final results using a "context-id". This is
necessary because of the blocks of bits format and ICMP transport. I think
it makes more sense to define the InfoElements logically, and let the
transport handle the fragmentation.
- The length field in CARD options is 8 bits, due to the blocks of bits
format. This required us to define the units of the length as "8 octets"
which leads to some potential for wasted padding.

We honestly *did* really try to use CARD for NED, in fact, I wrote an
initial draft for it, but it was really not very satisfying from a design
standpoint. So, in the end, the only thing we ended up reusing is the IANA
registry for network capabilities and for L2 Technologies, because they are
really crucial for exensibility.

As to "how the proposed draft solves the 802.21 problems better than CARD",
I'll leave answering that up to 802.21 people. Suffice to say, Rajeev and I
believe NED does solve those problems, and we're prepared to work with
802.21 and MIPSHOP to fill any gaps that they may find.

Also, BTW, I suggest you read Stefano and Greg's draft. They've also
proposed an InfoElements protocol.

            jak

----- Original Message -----
From: "Singh Ajoy-ASINGH1" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "'Marco Liebsch'" <[email-masked]>;
"'Eunsoo Shim'" <[email-masked]>
Sent: Tuesday, July 12, 2005 7:34 PM
Subject: RE: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

> After reading the draft, I am not really convinced why we need to define a
new CARD like protocol in IETF again. I am aware of IEEE 802.21 activity. I
am still trying to understand how the newly proposed draft solves the
problem of IEEE 802.21 any better than existing CARD protocol. In my view
perhaps taking the CARD protocol to standard track is better idea than
trying to invent a new protocol to solve the problem.