Subject: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 08:47:19 -0600

Comments by Bruno Sousa:

>Here is my contribution to the draft-ietf-16ng-ipv6-over-ipv6cs-04,
>many of the issues I'm pointing come from the previous version of this
>draft.
>
>1) Typos (besides the ones pointed by Junghoon Jee)
> - inclide (page 5) --> include
> - service specific or service-specific (page 5 and others) I think we
>should be coherent.
> - enacapsulated (page 7) --> encapsulated
> - specfic (page 7, section 4.1) --> specific
> - sucesful (page 10, section 6.2 and page 17 appendix C) -->
>successful

Could not find this typo.

> - succesfull (page 10, section 6.2) --> successful
> - Hader (page 11, section 6.3) --> Header
>

Fixed the rest of the typos.

>
>2) Terminology (section 3 and section 5).
>I'm questioning myself why only the definition of the ASN?
>For instance, important terms, used through out the memo are IPv6 link,
>L2 link.
>I think these ones should also be clarified from the beginning.

The intent is to use common terminology and ASN is the only term that
is specific to this document. The rest of the terms are intended to be
included in the next rev of the 16NG PS I-D. The terminology proposed
for inclusion in the PS I-D is in the email:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html

>
>I agree with the term ASN here, nevertheless it does not appear cited on
>the document,
>with the exception of the appendixes A and C.
>I think it is important to refer it on the section 5,
>the generic network architecture, when talking on the access network.

If you were to look back to rev 2 of this I-D, you will see the WiMAX
specifics being a part of the normative part of the I-D. However based
on the WG objectives and the goal for this I-D, it was decided that
the draft would be applicable to a generic 802.16 network and not just
WiMAX. Hence the WiMAX specific parts are now in an appendix. Maybe I
could even move the term ASN to the appendix.
Adding WiMAX specific text in the main body of the I-D is not an
option. 

>
>
>3) IPv6 link (section 6)
>" A link is bounded by routers that decrement TTL."
>If we are talking about IPv6, shouldn't we refer Hop Limit instead of TTL?!
>

Yes, I agree. Fixed it.

>
>4) IPv6 link in 802.16
>"
>   In 802.16, there exists an L2 Transport Connection between an MS and
>   a BS which is used to transport user data, i.e IPv6 packets in this
>   case.  A Transport Connection is represented by a CID (Connection
>   Identifier) and multiple Transport Connections can exist between an
>   MS and BS.
>"
>I think the first sentence is somehow contradictory with the rest of the
>paragraph.
>It is possible to have more then one transport connection between MS and BS.
>These transport connections are defined on the MAC layer (L2),
>so why refer "there exists an L2 Transport Connection?!"
>
>(If my thoughts are correct) I propose to change the first sentence to:
>
>  In 802.16, the Transport Connection between an MS and a BS is used
>  to transport user data, i.e. IPv6 packets in this case.

Agreed. Incorporated the proposed sentence.

>
>
>5) Maximum transmission unit in 802.16 (section 6.3)
>
>"
>   The 802.16 MAC header is a 6 byte header followed by the payload and
>   a 4 byte CRC which covers the whole PDU (Protocol Data Unit).  The
>   length of the PDU is indicated by the Len parameter in the Generic
>   MAC HDR. 
>"
>As reading, we may think that the payload and the CRC are always present
>on the MAC frames.
>They are not included in all messages. So I suggest to rewrite this,
>starting with:
> 
>  The 802.16 MAC PDU (Protocol Data Unit) is composed by
>  a 6 byte header followed by an optional payload and
>  an optional CRC covering the header and the payload.
>

Okay... I changed the text in the I-D as proposed.

>This introduction has also the propose to clarify the covering of the
>CRC (header + payload)
>and not the whole PDU (since this one can include the CRC).
> 
>
>6) IPv6 prefix assignment (section 7)
>I suggest to add a reference to the RFC2461, to clarify where the
>on-link flag is defined:
>
> The prefixes are advertised with the on-link (L-bit) flag set as
>specified in RFC2461.

Okay. Done.

>
>
>This section starts with:
>"
>  Each MS can be considered to be on a separate subnet as a result of
>the point-to-point connection.
>"
>In the middle there is a sentence:
>"
>  Each MS MUST be considered to be on a separate subnet as a result of
>the point-to-point connection.
>"
>Shouldn't here we have a consensus also?
>(probably this is an issue related with RFC2119) So can or MUST?!
>And the sentences aren't repeating themselves in the same section?
>

Agree. Fixed it.

>
>7) Appendix D
>This section introduces the SDU size proposed by the WiMAX forum.
>I just want to point that there is no a relation with the SDU and
>the IPv6 payload spoken along the document.
>Shouldn't this be clarified?!

I dont think that is necessary. Within the main body of the text it is
clear what the MAX IPv6 payload size can be. And in the appendix, the
I-D is making a recomendation that the MAX MTU be 1400 bytes by
default but obviously can be anything between 1280 and 1500.

Thanks for reviewing and your comments on the I-D.

-Raj

>Kindly,
>Bruno Sousa

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 17:57:15 +0100

Hi, please allow me to interfere with clarifications.

> Comments by Bruno Sousa:
[skip parts I agree]
>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 Transport 
>> Connection between an MS and a BS which is used to transport user 
>> data, i.e IPv6 packets in this case.  A Transport Connection is 
>> represented by a CID (Connection Identifier) and multiple Transport
>>  Connections can exist between an MS and BS. " I think the first 
>> sentence is somehow contradictory with the rest of the paragraph. 
>> It is possible to have more then one transport connection between 
>> MS and BS. These transport connections are defined on the MAC layer
>>  (L2), so why refer "there exists an L2 Transport Connection?!"
>> 

But there are IPv6 packets that are sent on the Secondary Management
Connection as well (RS/RA at least) 6.3.9.10 802.16e-2005.  I suggest
saying that only _some_ of the IPv6 packets are transported on some 
Transport Connection, or along these lines.

Probably best for reader would be to enumerate the different types of
Connections the SS can handle and where do IPv6 packets appear.  What do
you think?

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 11:22:25 -0600

Alex,

Inline:

> Transport Connection, or along these lines.

The secondary management connection is typically not used for user data. As
the .16 spec says it can be used for address configuration, TFTP etc.
Also to be noted is the fact that secondary management connections are not
mandatorily required. The usage for which it has been defined can be
accomplished via a regular transport connection.
>From a practical standapoint, I do not see hosts or BS' implementing or
using the secondary management connection. So I can mention it in the text
of the I-D, but it would not be very useful.

> Connections the SS can handle and where do IPv6 packets appear.  What do

I don't think we should get into the details of the various types of
connections in the I-D. The reference to the .16 spec is sufficient for
that. But I can mention that there does exist the secondary management
connection which may be used for host configuration with a caveat that for
all practical purposes it is better to use a transport connection for the
same. 

The reason why the secondary management connection does not make sense is
because it is limited in its capability. Establishing a transport connection
instead allows you to do the same host configuration as well as use it for
user traffic. 

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 18:52:43 +0100

Basavaraj Patil wrote:
>>>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 
>>>> Transport Connection between an MS and a BS which is used to 
>>>> transport user data, i.e IPv6 packets in this case.  A 
>>>> Transport Connection is represented by a CID (Connection 
>>>> Identifier) and multiple Transport Connections can exist 
>>>> between an MS and BS. " I think the first sentence is somehow 
>>>> contradictory with the rest of the paragraph. It is possible to
>>>>  have more then one transport connection between MS and BS. 
>>>> In 802.16, the Transport Connection between an MS and a BS is 
>>>> used to transport user data, i.e. IPv6 packets in this case.
>> But there are IPv6 packets that are sent on the Secondary 
>> Management Connection as well (RS/RA at least) 6.3.9.10 
>> 802.16e-2005.  I suggest saying that only _some_ of the IPv6 
>> packets are transported on some Transport Connection, or along 
>> these lines.
> 
> The secondary management connection is typically not used for user 
> data. As the .16 spec says it can be used for address configuration, 
> TFTP etc.

Not only that it can but it must, by that spec.

> Also to be noted is the fact that secondary management connections 
> are not mandatorily required. The usage for which it has been defined
>  can be accomplished via a regular transport connection.

I don't think the 802.16 spec says anywhere that RS/RA could be sent on
anything else than Secondary Management Connection.  Do you?

>> From a practical standapoint, I do not see hosts or BS' 
>> implementing or using the secondary management connection. So I can
>>  mention it in the text of the I-D, but it would not be very
>> useful.
>> 
> 
>> Probably best for reader would be to enumerate the different types 
>> of Connections the SS can handle and where do IPv6 packets appear. 
>> What do you think?
> 
>  connections in the I-D. The reference to the .16 spec is sufficient
>  for that. But I can mention that there does exist the secondary 
> management connection which may be used for host configuration with a
>  caveat that for all practical purposes it is better to use a 
> transport connection for the same.
> 
> The reason why the secondary management connection does not make 
> sense is because it is limited in its capability. Establishing a 
> transport connection instead allows you to do the same host 
> configuration as well as use it for user traffic.

I am afraid the 802.16 spec clearly says RS/RA only happen on the
Secondary Management Connection and we can't suggest do it otherwise.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 12:12:06 -0600

Alex, 

Let me just say that in the current realizations of 802.16, the secondary
management connection is not used for either configuration or for sending
RAs or sending router solicitations.
Essentially the secondary management connection is not used at all.

It is true that IEEE 802.16 defines the secondary management connection but
is not mandatory that it be used.

A transport connection that is established for IPv6 is used for RA/RS,
DHCPv6 and everything else.

-Raj

On 1/12/07 11:52 AM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

> Not only that it can but it must, by that spec
>

---

From: Bruno Miguel Sousa <[email-masked]>
Date: Sat, 13 Jan 2007 11:42:58 +0000

Thanks Raj for taking into account my comments.

> Could not find this typo.
Strange, but better that way!
> http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html
Ok. I'm clarified!
> Adding WiMAX specific text in the main body of the I-D is not an
I agree with you. It's better to have the draft applied to a generic .16 
network, then a WiMAX network.
Probably the idea to move the term ASN to the appendix is not a bad 
idea. Since it comes from WiMAX spec.
> default but obviously can be anything between 1280 and 1500.
Ok. I agree with you.

Kindly,
Bruno Sousa