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

James,

Please see my inline comments.

>>- 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.
>  
>
>
>I believe Mike responded on this.
>
>  
>
>>- 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 options have been used over ICMP on MN-AR interface and over
>SCTP/UDP over AR-AR interface.
>  
>
>
>The on-the-wire format of CARD is based on RFC 2461 Options. That isn't an
>appropriate format for a widely applicable solution, especially for 802.21.
>
>  
>
I don't see any base for this subjective statement. Could you elaborate 
this?

>>- 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. It can be used to other mobility
>>    
>>
>protocol as well.
>  
>
>
>I guess I didn't make my point very well. My main point is that CARD has
>singled out a specific application - cross link ARP - and designed in
>specific option types for that - L2 ID and Address - while others are
>carried in the Capability Container. From the point of view of a generalized
>protocol, that doesn't make much sense. It only makes much sense if one
>knows the history of CARD.
>
>  
>
You remember that SeaMoby WG produced drafts 
"draft-ietf-seamoby-card-requirements-02.txt" to which you also made 
contributions.
According to the draft, the requirements for CARD include the following:
- Identifying the IP address of a CAR (3.1)
- Support for inter-technology handoffs (3.2)
- capability discovery (3.4)
- dependence on a mobility management protocol --- CARD MUST NOT depend 
on a particular mobility management protocol (3.10)

Your message gives an impression that CARD was designed mainly for 
mapping AP address to AR IP address. But as you agreed on the CARD 
requirements draft, CARD was designed to support much more than the 
cross-link ARP. In particular, inter-technology handoff support is at 
least very very closely related to what 802.21's media indepent handoff 
is about.

The draft "draft-ietf-seamoby-card-issues-04.txt" to which you again 
contributed lists a number of possible application examples:
- Load balancing between ARs.
– Bandwidth-intensive applications.
– Minimization of cost.
– Inter-technology handovers.
– Adaptability to changing topology without Ad hoc routing schemes.

Certainly CARD is not designed to do everything human beings can 
imagine. But it was designed to be general enough to satisfy the above 
requirements and the above application examples, at least.

You are saying "from the viewpoint of a generalized protocol". What do 
you mean by "generalized protocol"?

>> 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.
>  
>
>
>It was explained, I didn't buy the explanation when I was WG chair (and
>neither did the expert reviewers BTW), and I don't buy it now. That's why
>this distinction isn't in NED.
>
>  
>
That's quite unfortunate. Please take a look at the requirements of 
802.21 IS compiled by 802.21 WG. They include filters. Even schemas are 
mentioned. For anyone to say something of CARD is not necessary for 
802.21 IS and to propose a kind of subset of CARD, she/he should refer 
to the 802.21 IS requirements.

Following the good method adopted by many IETF WGs,  I believe 802.21 IS 
requirements should be clarified first of all. Then existing protocols 
(primarily CARD in this case) should be compared to the requirements and 
discussed. Based on the result, we can say what is necessary and 
unnecessary and what needs to be changed, added or created.

>>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 nice if you would have involved CARD folks in
>>    
>>
>this discussion as well. I can't comment about something that I am not
>really aware of.
>  
>
>
>So everytime someone wants to use CARD for something they have to include
>the CARD folks into the design? Doesn't sound like a very scalable design
>process to me.
>
>  
>
Regards,

Eunsoo

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop