Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs))

[Basavaraj Patil <[e-mail]>]

Alex,

Why don't you try and implement the I-D first? All I see from you is
non-constructive comments.
I think the chairs, ADs and the IESG will form their own opinion about the
track for this I-D. And since when is it required that a standards track RFC
MUST specify "n" number of MUSTS and SHOULDS and MAYS.

Other comments inline:

On 1/24/07 12:49 PM, "ext Alexandru Petrescu"
<[e-mail]> wrote:

> Raj, Jari, thanks for having this exchange public on the mailing list.
> 
> I will precede this mail with a high-level unease I have about
> advancement of this draft towards a Standards Track RFC.  This can be
> solved by several ways, eg change its name into 'Goals for ...' or maybe
> change status, or other way one may think of.  The draft is definitely
> well written, complete in its own and self-contained, a piece of text
> worth the effort to submit to IESG.
> 
> Usually a a Standards Track RFC gives clear directions about what should
> be implemented.  This document doesn't: there's no new message format,
> no new message exchange, no new issues with other implementation, 'MUST'
> occurs only two times and it's for lifetimes in RA - no new lifetime in
> RA suggested, 'SHOULD' appears once to say MTU should be what 2460
> recommends (which is good), 'MAY' never appears.  It doesn't offer a
> implementer anything special that should be done about running an
> existing IPv6 stack over a new kind of link (802.16 IPv6CS in this case,
> allow me the term IPv6CS).

There is nothing special needed for an implementer other than what is stated
in the I-D. 

> 
> Section 2 Introduction describes what the IEEE standard describes.  It
> also describes what WiMax thinks the architecture should be.
> 
> Section 3 Terminology describes a new term 'ASN' which is a WiMax term.
> 
> Sections 4 and 5 are architectural descriptions, from IEEE documents.

So whats your point above other than the fact that you have read the
document and noted the section numbers and their content?

> 
> One very important part in Section 4, giving indication to which
> specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS or
> IPv6CS?) is left implementation-dependent (who implements that?  how?) -
> is there an RA-overIPv6CS enhancement that says use ETHCS vs use IPv6CS.

As I said IPv6 can be run over 802.3 (which runs on the EthCS) or directly
over the IPv6 CS. The choice depends on the host. The clarification that has
been put in is the fact that the network will need to support both. And that
is sufficient.

> 
> Section 6 'IPv6 link' makes recommendation about how to configure
> things, but nothing to implement.
> 
> Section 6.2 'IPv6 link establishment' which is the 802.16 network-entry
> procedure.  What should the IPv6 stack implementer write?

Nothing.

> 
> Section 6.3 'MTU' says MTU should be what it should be.  This is a good
> goal, but what to implementer means?

I do not see anything in this section that would not be understandable by an
IPv6 implementer.

> 
> Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on a
> different prefix.  This is (1) different than any other IPv6-over-foo
> documents (and there are other point-to-point links out there not
> recommending this) and (2) a configuration management issue, nothing to
> be implemented.
> 
> Section 8 "Router Discovery" is standard behaviour nothing new, nothing
> to implement.
> 
> Section 9 "IPv6 addressing for hosts" - nothing new.  I could think of
> SeND issues with the MS having the same link-local address on all its
> 802.16 connections (subnets) but that's all.
> 
> These are the reasons I have that uneases.  That said, let me address
> the point where I was cited, see below.

Point about your uneasiness noted. Can we move on?

-Raj

> 
> Basavaraj Patil wrote:
>> Hi Jari,
>> 
>> Responses inline:
>> 
>> 
>> On 1/23/07 1:04 PM, "ext Jari Arkko" <[e-mail]> wrote:
>> 
>>> Basavaraj, all
>>> 
>>> I reviewed the new version of this spec, and I'm generally quite
>>> happy with it. I found three small remaining issues which are
>>> listed below:
>>>> +-----+   CID1    +-----+          +-----------+ | MS1
>>>> |----------/| BS1 |----------|     AR    |-----[Internet
>>>> 
>> <http://tools.ietf.org/html/draft-ietf-16ng-ipv6-over-ipv6cs-06#ref-Internet>
>> >>
>>  ]
>>>> +-----+         / +-----+          +-----------+ .           /
>>>> ____________ .     CIDn /        ()__________() +-----+      / L2
>>>>  Tunnel | MSn |-----/ +-----+
>>>> 
>>>> 
>>>> Figure 5: The IPv6 AR is separate from the BS, which acts as a
>>>> bridge
>>>> 
>>> The part about the BS acting as a bridge seems surprising. Is this
>>>  really the case? A standard bridge function?
>> 
>> I did'nt mean bridge from the "standard bridge function" definition.
>>  I will delete it from the document. Basically the BS is an L1/L2
>> entity, but I do not believe I will not to elaborate on that.
>> 
>>>> This section presents a model for the last mile link, i.e. the
>>>> link to which MSs attach themselves.
>>> I would remove this sentence. You need to explain how the link
>>> looks like from an IP perspective. And I think you are doing that.
>>>  Whether there is a distributed or integrated BS/AR at the other
>>> end is really not a key issue.
>> 
>> Okay. Will work on this text as suggested.
>> 
>>>> IEEE 802.16 also defines a secondary management connection that
>>>> can be used for host configuration.  However support for
>>>> secondary management connections is not mandatory.  A transport
>>>> connection has the advantage of it being used for host
>>>> configuration as well as for user data.
>>> Are you specifying something about the use of the management
>>> connections? If not, take it out.
>>> 
>> 
>> Not really specifying anything w.r.t the management connection. This
>>  came up during discussion with Alex Petrescu and I added it just for
>>  the sake of completeness. Within the scope of this I-D, the
>> management connection has no relevance. I can take it out.
> 
> Yes, the issue is that 802.16 recommends the RS/RA to happen on a
> Secondary Management Connection (instead of on a Transport Connection).
>   Clarifications on the list suggested that probably nobody uses a SMC.
> But that doesn't mean that the IEEE spec isn't saying so.
> 
> So one could  write in the draft that "contrary to the IEEE Spec, this
> draft recommends the use of a normal transport connection for an RS/RA".
> I would suggest that actually.  But there may be other oppinions as well.
> 
> Another thing that was mentioned in the list, and it was agreed by me
> and Tim, is that there may be an issue with the indication of how to
> auto-configure an address: statelessly or statefully.  This indicator
> comes from an RA in an IP-only world but in 802.16 it comes from a
> link-layer message too.  This is an obvious risk for interoperability:
> what if the BS says stateless but AR says stateful.  In this line of
> thought some may remark (from my experience in other WGs) that people
> should be capable to configure their networks ok, and these
> clarifications shouldn't be specified.  But here we talk things to be
> done at MAC layer vs at Network layer, and maybe it's not the same
> people doing it.
> 
> So I would suggest to at least clarify that IPv6-over-IPv6CS recommends
> to ignore that link-layer indicator.  But there may be other oppinions
> on this topic too.
> 
> Finally, even with all these clarifying remarks I'm making in the inner
> body of the mail, I think there is still nothing new to be implemented -
> which is good in a good sense, less work :-)
> 
> Alex
> 
> 
>> 
>>>> Each MS belongs to a different link.  No two MSs belong to the
>>>> same link.
>>> Duplication. Remove the first sentence.
>>> 
>> 
>> Okay. Editorial fix.
>> 
>> Will submit a revised version with these changes.
>> 
>> -Raj
>> 
>>> Jari
>>> 
>> 
>> 
>> _______________________________________________ 16NG mailing list
>> [e-mail] https://www1.ietf.org/mailman/listinfo/16ng
>> 
> 


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng