Subject: [16NG] review of the new revision (ipv6 over ipcs)

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Jan 2007 21:04:39 +0200

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?

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

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

> Each MS belongs to
>    a different link.  No two MSs belong to the same link.
Duplication. Remove the first sentence.

Jari

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

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 23 Jan 2007 14:21:02 -0600

Hi Jari,

Responses inline:

On 1/23/07 1:04 PM, "ext Jari Arkko" <[email-masked]> wrote:

>>          | MS1 |----------/| BS1 |----------|     AR    |-----[Internet
>> 
<http://tools.ietf.org/html/draft-ietf-16ng-ipv6-over-ipv6cs-06#ref-Internet>>>
]
> 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.

> end is really not a key issue.

Okay. Will work on this text as suggested.

> 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.
 
> Duplication. Remove the first sentence.

Okay. Editorial fix.

Will submit a revised version with these changes.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Jan 2007 19:49:38 +0100

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

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.

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.

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?

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

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.

Basavaraj Patil wrote:
>> 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
>>> 
>>> +-----+         / +-----+          +-----------+ .           / 
>>> ____________ .     CIDn /        ()__________() +-----+      / L2
>>>  Tunnel | MSn |-----/ +-----+
>>> 
>>> 
>> 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
>>> 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.
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 24 Jan 2007 14:17:04 -0600

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:

> allow me the term IPv6CS).

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

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

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

> procedure.  What should the IPv6 stack implementer write?

Nothing.

> goal, but what to implementer means?

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

> the point where I was cited, see below.

Point about your uneasiness noted. Can we move on?

-Raj

>> <http://tools.ietf.org/html/draft-ietf-16ng-ipv6-over-ipv6cs-06#ref-Internet>
>> >>
>>  ]

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 25 Jan 2007 16:51:59 +0900

Dear Alex

Kindly find my in-line comments.

> But that doesn't mean that the IEEE spec isn't saying so.

As of my knowledge, 802.16 doesn't mandate which connection to use for RS/RA.

Actually in the beginning of IPv6 over 802.16 IP CS work, we gave much
thought on which connection to use for Neighbor Discovery messages
such as RS/ RA or NS/ NA. (because those messages can carry multicast
destination address and unspecified source address, special features
are required for the connection.)

Unfortunately 802.16 spec is not perfectly clear about this. While
there are a few vague statements which may be interpreted to recommend
the Secondary Management Connection, upon discussing with 802.16 &
WiMAX people, we found out that neither the statements were written
with that intention nor the actual 802.16 SS and BS were implemented
that way. Transport Connection (especially Initial Service Flow for
WiMAX case) is universally agreed as long as our experience &
knowledge goes. If there is something missing or wrong, kindly let me
know.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jan 2007 19:57:08 +0100

Basavaraj Patil wrote:
> 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.

Raj, I gave one opinion and I respect opinion of WG members and decision
by WG Chairs and AD.

About non-constructive comments: I gave several constructive comments
several times (entry procedure enhanced, RA bit, etc), including my
support to advance this document to delivery to IESG.  What you seem to
react to is its status (your remark on n MUSTs).  If you wish we can
discuss its status.

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

YEs, one point is to show I've read it.  Often I'm asked to read, so
I've tried to avoid this recommendation.

The second point is that there's nothing to be implemented in these
sections.

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

How does the network 'support' both?  How does the network switch
between the two modes?  That is left implementation-dependent.  Or this
implementation should follow this spec.

Constructive comment: the spec could specify a means in an ICMPv6
message enhancement to change between the modes.  I suggest one bit only.

>> Section 6.2 'IPv6 link establishment' which is the 802.16 
>> network-entry procedure.  What should the IPv6 stack implementer 
>> write?
> 
> Nothing.

Ok, so nothing to write about the network entry procedure.  Maybe
something to configure then.

Constructive comment: I suggest IPv6CS to offer configuration parameters
to the IPv6 stack, such that the IPv6 stack can enable/disable the use
of some features.  For example, PANA does auth at IP level, so the IP
stack could request disabling of the PKM MAC-layer auth features and
message exchanges.

This can happen as an extension to the BSD Socket interface.

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

YEs, it is, understandable, complete description, agreed in the WG.  The
comment is that an IPv6 stack implementer doesn't have to do anything
special about MTU to run on IPv6CS.  This is good - less work.

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

YEs, thanks about noting my point.  Let's move on.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Jan 2007 19:57:54 +0100

Dear JinHyeock, thanks for your reply.

Just one comment, I will not insist on this.

JinHyeock Choi wrote:
>>>>> 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.
>>> 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.
>> 
>> 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.
> 

Well I thought that mentioning of sl address autoconf happening on the
SMC, check citation below.

> Actually in the beginning of IPv6 over 802.16 IP CS work, we gave 
> much thought on which connection to use for Neighbor Discovery 
> messages such as RS/ RA or NS/ NA. (because those messages can carry 
> multicast destination address and unspecified source address, special
> features are required for the connection.)

What came out of the discussion?

> there are a few vague statements which may be interpreted to 
> recommend the Secondary Management Connection, upon discussing with 
> 802.16 & WiMAX people, we found out that neither the statements were 
> written with that intention nor the actual 802.16 SS and BS were 
> implemented that way. Transport Connection (especially Initial 
> Service Flow for WiMAX case) is universally agreed as long as our 
> experience & knowledge goes. If there is something missing or wrong, 
> kindly let me know.

Look.  Let's ignore WiMax for a very short moment.  All we're left with
is the 802.16-2005 spec:

> IPv6 Stateless Address Autoconfiguration [IETF RFC 2462] based on the
>  value of a TLV tuple in REG-RSP. Establishment of IP connectivity 
> shall be performed on the SS’s Secondary Management Connection (see 
> Table 110).

First issue is the use of SMC for RS/RA.

The second item is the value in REG-RSP.  That value is equivalent to
the M-bit in RA.

Both issues can be solved directly and solely in the IETF draft, until
the IEEE spec is updated.

I agree discussion and clarification happened, at least on the list, but
its results should be documented.  I agree that IEEE 802.16 may be fed
back and modified suggestions.  I would like that to happen.  If that
happens then some coherency is gained.

Remark we can't put deadlines on IEEE document advancement, so maybe
just hold on for a while.

Alex

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 26 Jan 2007 01:22:24 +0530

Hi Alex,

One quick comment inline.

[cut]
> implementation should follow this spec.

Network supporting both Eth CS and IP Cs is like having two different
mechanisms for accessing the network. It is like a router supporting
two different PHY interfaces.

An IP CS only MS cannot interwork with Eth CS only BS and vice versa..

An MS that has support for both Eth CS and IP CS, and wants switch,
it has to do the vertical handoff.

> message enhancement to change between the modes.  I suggest one bit only.

I do not see any need for this.

Thanks,
Syam

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 26 Jan 2007 10:33:20 +0900

Alex

thanks for your prompt reply.

> Just one comment, I will not insist on this.

glad to hear that. :-)

> >  multicast destination address and unspecified source address,
> > special features are required for the connection.)
>
> > shall be performed on the SS's Secondary Management Connection (see
> > Table 110).
>

The above citation may give the impression that SMC is for RS/ RA but
doesn't clearly mandate it. I don't think it's productive for us to
further debate how to interpret the expression. However, both issues
can bring forth some confusion and I guess maybe we'd better give
feedback to 802.16 to right them.

Best Regards

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Jan 2007 11:23:04 +0200

Alex,

Let me start by saying that I actually did share a little
bit of your unease given that the document has a lot
of focus on the configuration and network architecture
issues. However, I believe its a feature, not a bug when
most of the spec contains statements like "XXX is
performed as per RFC NNNN." There is indeed very
little new to implement here, because you run IPv6 as
it has already been defined, and you run L2 as
it has already been defined. That's great! Particularly
when a lot of different changes and other ways of
running IPv6 over this link have been suggested
in the past. Given this background, I think it is
also important for the specification to talk about
the configuration/architecture issues, because
those were the determining factor when we
decided that we do not actually need all these
new enhancements to run IPv6.

Jari

Alexandru Petrescu kirjoitti:
>>> happy with it. I found three small remaining issues which are listed
>>> below:
>>>> 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.
>>>> 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.
>>>> Each MS belongs to a different link.  No two MSs belong to the same
>>>> link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jan 2007 12:16:28 +0100

Jari, it is indeed a needed feature to have statements "XXX is performed
as per RFC NNNN".  There is value in that and it establishes a basis for
communication.  That is needed.

The Charter puts the document on Standards Track.  I hope that direction
  is taken with an eye on the fact that not all IETF's IPv6-over-foo
documents are Standards Track (optionally see rfc4392 and rfc3572).

IMHO an IPv6-over-foo document to be on Standards Track would be good to
have at least one _new_ recommendation, something like "IID is derived
from a non-48bit id, in this way".  Other example would be conversion
from multicast address to multicast CID, or conversion of IPv6 Traffic
Class to a 802.16 Service Class, or something similar.  Or an
IPv6-oriented network-entry procedure (not a link-layer network entry
procedure).  Or maybe a IANA action.

But please take this as just some thoughts on the document, not
necessarily as a disagreement.  Again the document looks good, it is
needed and I can live with it ok.  It is possible that later work can
enhance the basic features in this document.

Alex

Jari Arkko wrote:
> Alex,
> 
> Let me start by saying that I actually did share a little bit of your
>  unease given that the document has a lot of focus on the 
> configuration and network architecture issues. However, I believe its
>  a feature, not a bug when most of the spec contains statements like 
> "XXX is performed as per RFC NNNN." There is indeed very little new 
> to implement here, because you run IPv6 as it has already been 
> defined, and you run L2 as it has already been defined. That's great!
>  Particularly when a lot of different changes and other ways of 
> running IPv6 over this link have been suggested in the past. Given 
> this background, I think it is also important for the specification 
> to talk about the configuration/architecture issues, because those 
> were the determining factor when we decided that we do not actually 
> need all these new enhancements to run IPv6.

A few examples:

rfc4392 IP over InfiniBand, an Informational RFC describes some
architecture.

rfc3572, IPv6 over MAPOS, Informational, does describe new things to be
implemented, when deriving the IID from the HDLC address.

RFC3831 IPv6 over Fibre Channel, Stds Track, has at least one new thing
that needs to be implemented in an IPv6 stack: derive IID from Nx_Port_Name.

rfc3146m IPv6 over IEEE1394, StdsTrack, proposes at least new IANA
allocations and SLLAO/TLLAO encodings.

Alex

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