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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 14 Jul 2005 10:24:42 -0500

Hi James, 

Please find my inline comments. 

Regards,
Ajoy 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, July 13, 2005 4:18 PM
To: Singh Ajoy-ASINGH1; [email-masked]
Cc: [email-masked]; 'Marco Liebsch'; 'Eunsoo Shim'
Subject: Re: [Mobopts] draft-kempf-mipshop-nhood-discovery-00.txt

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.

Ajoy-> CARD is an IP layer protocol. Being a IP layer protocol, it can easily accommodate a scenario where MIH function is implemented on a standalone server or an AP that is reachable using IP based transport. 
Please note that 802.21 is defining MIH function for 802.XX, 3GPP2 and 3GPP and it is difficult to have a common MAC layer protocol that can be used in all of the above technologies. This was one of motivation why 802.21 is also looking at IP based transport. If this is not the case, you can extend 802.11 and 802.16 using MAC extension for the information service.  

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

Ajoy-> I do not quite understand your argument here. CARD is using TLV encoding and TLV encoding is used in 802.11 as well as most of IP based protocol. 

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

Ajoy-> CARD is NOT limited to FMIPv6. CARD can be used to other mobility protocol as well. 

 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.

Ajoy-> Again, I do not understand your comment. Preference and requirements are two different things. We have explained this earlier as well.  

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

Ajoy-> This depends upon the actual capability being used. Some potential padding is always possible in any protocol so I do not why it is bad.  

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

Ajoy-> It would have been if you would involved CARD folks in this discussion as well. I can't comment about something that I am not really aware of. 

As to "how the proposed draft solves the 802.21 problems better than CARD",
I'll leave answering that up to 802.21 people. 

Ajoy-> I have been part of 802.21 discussion. I do represent here my view of 802.21. 

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.

Ajoy-> I will definitely do. In fact I had discussion with Stefano on 802.21 list about CARD. 

            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

> 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: Rajeev Koodli <[email-masked]>
Date: Thu, 14 Jul 2005 11:04:19 -0700

Ajoy,

the motivation behind the NED draft was to

- present a single protocol framework for carrying Request-Reply
  messages between peers in a transport-independent fashion. This
  came about from a prolonged discussion regarding recharter items
  for MIPSHOP. I did not hear from you then..
- allow FMIP, CARD and 802.21 all to use a transport-independent protocol
   that defines message format and option formats. Each protocol can then
   define and use its own transport for its purpose. All three have 
their own
   purpose.
   - FMIP is interested solely in subnet information corresponding to an
      an AP-ID for fast routing purposes
   - CARD is interested is using the neighborhood information for target
      router selection. If this is *not* the primary purpose of CARD, then I
      question its relevance here.
   - 802.21 is interested in the IS, where .21-specific payload query and
      responses need to be supported. And, an L3 protocol does not exist 
yet.
- make use of the common IANA registry for allocating Type numbers for
   protocol-specific messages and options.

As it has turned out, the above protocols were not designed with a 
harmonized
message and option format in mind. One could argue that FMIP or CARD
_can be made to serve that purpose_, but that's a topic of past discussion.
We have decided to split the task into "generic message structure" and
"protocol-specific carrier", and believe that CARD should also benefit 
from it.

As FMIP editor, I am comfortable moving forward with NED as a
starting point. I see CARD as a potential companion protocol which
can help a Mobile Node in selecting a target router. I don't see it as the
protocol framework for other protocols to use.

Regards,

-Rajeev