Subject: [16NG] 2nd WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-04

From: "Daniel Park" <[email-masked]>
Date: Fri, 29 Dec 2006 08:48:09 +0900

Folks,

This is the 2nd WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-04 - IPv6
Over the IP Specific part of the Packet Convergence sublayer in 802.16
Networks.

The latest version can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-04.txt

It will expire on January 5. 2007

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

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

---

From: "Junghoon Jee" <[email-masked]>
Date: Fri, 29 Dec 2006 16:33:49 +0900

This I-D looks good in moving forward!
I found very minor two editorial errors.

1. [Page 8]
For transmission of IPv6 packets via the IP specific part of the
Packet CS of 802.16, the IPv6 layer interfaces with the 802.6 MAC
directly.  

s/802.6/802.16

2. 13.2.  Informative References

  [FRD]      Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router
              Discovery with L2 support", August 2006, <http://
              www.ietf.org/internet-drafts/draft-ietf-dna-frd-02.txt>.

 [RFC4135]  Choi, JH. and G. Daley, "Goals of Detecting Network
              Attachment in IPv6", RFC 4135, August 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4135>. 

Please check whether these are referenced.

-Junghoon

> -----Original Message-----
> From: Daniel Park [mailto:[email-masked]] 
> Sent: Friday, December 29, 2006 8:48 AM
> To: [email-masked]
> Subject: [16NG] 2nd WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-04
> 
> 
> Folks,
> 
> This is the 2nd WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-04 - 
> IPv6 Over the IP Specific part of the Packet Convergence 
> sublayer in 802.16 Networks.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 13:39:46 +0100

Daniel Park wrote:
> Over the IP Specific part of the Packet Convergence sublayer in 
> 802.16 Networks.
> 

I may be the only one thinking so but isn't this LC too short - ie 6
days out which at least 3 are non-working.

draft says:
> The AdvDefaultLifetime in the router advertisement MUST be either 
> zero or between MaxRtrAdvInterval and 43200 seconds.  The default 
> value is 2 * MaxRtrAdvInterval.

This formulation is ambiguous.  I'd prefer using 'MUST' followed by a
single sentence, not by an 'or'.

If the Router Lifetime is 0 then the BS or AR is not a Default Router.
Or I don't see a deployment scenario where the BS/AR are not default
routers for the SS.

draft:
> The MaxRtrAdvInterval value specified in this document over-rides the
>  recommendation in RFC2461 [RFC2461].  The MaxRtrAdvInterval MUST be
>  no less than 4 seconds and no greater than 21600 seconds.  Thee 
> default value for MaxRtrAdvInterval is 10800 seconds.

[nit: Thee]

Actually it only over-rides the upper limit and the default value (2461
says 1800s vs draft 21600s, and 600s vs draft 10800s respectively).
This draft does not override 2461's lower limit of 4s.

It means that an IPv6-over-IPv6CS handover would take a long 4s in the
worst case; which is too long.  But Mobile IPv6 3775 allows for
MaxRtrAdvInterval as low as 0.03s.  How does this draft position with
respect to 3775?  Can this draft be over-ridden by 3775 in addition to
over-riding 2461?

Alex

---

From: Bruno Miguel Sousa <[email-masked]>
Date: Fri, 29 Dec 2006 12:46:09 +0000

Hi folks,

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
 - succesfull (page 10, section 6.2) --> successful
 - Hader (page 11, section 6.3) --> Header

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.

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.

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

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.

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.

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.

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?

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

Kindly,
Bruno Sousa

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Dec 2006 14:08:12 +0100

Bruno Miguel Sousa wrote:
> 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 - 
> succesfull (page 10, section 6.2) --> successful - Hader (page 11, 
> section 6.3) --> Header
> 
> 
> 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.

I agree it makes sense to add short definitions of "IPv6 link" in the
Terminology section, eventually pointing to 2461.

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

I agree it is an issue to have ASN (and only ASN) in the terminology
section, it being used only in the Appendix.

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

I agree, we should refer to Hop Limit instead of TTL.

> 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?!"
> 
> 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.
> 
> 
> " 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
> 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.
> 
>  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:
> 
> 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?

I agree we should have coherence between MUST and can.

I'd add that for purposes of IPv6 over IPv6CS MS MUST be on separate
subnets for each point-to-point connection.  For IPv6 over ETHCS it's
not the case.

> 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 suggest text that the MTU be at least 1280.  That's all.  Short text
in the main body.  Besides, the current MTU section 6.3 is too long, and
badly formulated.

I don't know what the typical MTU on a IPv6-over-IPv6CS _deployment_ is. 
  I do know what I would like it to be, but not what is.

Appendix D mentioning SDU in WiMax is fine with me.

draft:
> The IPv6 payload can be a max value of 2038 bytes (MAC Hader - CRC).

The dash should spell minus for better reading (my reading, IMHO).  Or 
maybe say 'by not counting MAC header and CRC'?  And, if the CRC is 
sometimes absent it should be said so.

draft:
> The Max value of the IPv6 MTU for 802.16 is 2038 bytes and the 
> minimum value of 1280 bytes.  The default MTU for IPv6 over 802.16 
> SHOULD be the same as specified in RFC2460 which is 1500 octets.

rfc2460 specifies 1280, and 1500 _if_ ppp link.  This is not a ppp link.
  So the text could be clarified to just say 1280, IMHO.

Alex

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