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

From: [email-masked]
Date: Thu, 14 Jul 2005 10:33:06 -0500

Guys, do you mind if we copy these e-mails also on the MIHEP list?
Thanks

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Singh Ajoy-ASINGH1
> Sent: Thursday, July 14, 2005 10:25
> To: 'James Kempf'; [email-masked]'
> Cc: 'Marco Liebsch'; [email-masked]'
> Subject: [Mipshop] RE: [Mobopts]
> draft-kempf-mipshop-nhood-discovery-00.txt
> 
> 
> 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-dis
covery-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

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