Subject: Re: [Int-area] draft-manner-router-alert-iana WGLC

From: Jari Arkko <[email-masked]>
Date: Mon, 05 May 2008 15:58:10 +0200

I have not seen any reviews yet. Please take the time to look at this
draft, as several reviews are necessary in order to move the document
forward.

(And I'll mention that the document is short and easy to read.)

Jari

Jari Arkko kirjoitti:
> This message marks the start of an Intarea Last Call for reviewing the
> router alert document. Please take a look at this document before
> Tuesday, May 6th.
>
> The document can be found from here:
>
> http://tools.ietf.org/html/draft-manner-router-alert-iana
>
> Jari
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>
>   

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Roland Bless <[email-masked]>
Date: Mon, 05 May 2008 17:37:58 +0200

Hi Jari and all,

> draft, as several reviews are necessary in order to move the document

The overall document is fine for me, but there could be a statement
about the alignment or non-alignment of IPv4/IPv6 RAO value registries.
So as far as I read the document both registries are independently
managed by IANA. If this is the case, please state so in section 3. If
an allocation request in one registry should automatically allocate
the same value in the other registry it should be mentioned. If there
are technical reasons to not align the registries for future
allocations, there should also be statement in the draft.

Other than that I have only some minor editorial comments:
sec. 1:
   There can be up to 65536 values for the RAO.  Yet, currently there is
   only a repository for IPv6 values.  No repository or allocation
   policies are defined for IPv4.

I find the term repository somewhat confusing and I'd prefer
the term registry (as usual and mentioned in RFC 2711). So I propose the
following text change:

   There can be up to 65536 values for the RAO.  Yet, currently there is
   only an IANA managed repository for IPv6 values as specified in RFC
   2711.  No registry or allocation policies are defined for IPv4 RAO
   value so far.

sec. 2:
   One difference betwen the specifications for the IPv4 and IPv6 Router

s/betwen/between

   values (1-65535) are reserved.  No mechanism is provided for the
   allocation of these values by IANA.
proposed change to:
   values (1-65535) are reserved.  Neither a management mechanism
   (e.g., such as an IANA registry) nor an allocation policy are
   provided for the IPv4 RAO values.

sec. 3.2:
   currently).  The reason is that it is a duplicate value, aggreagation

s/aggreagation/aggregation

Regards,
 Roland

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 May 2008 07:41:55 +0200

Here's Bob Hinden's directorate review. Thanks for the review, Bob!

> I think the biggest issue I see with this document is change the IPv6
> RAO "3" to be reserved.  See the comments I wrote in 3.2.  It's not
> clear to me if this will break any running code or where the error was
> introduced.  It may have been in RFC3175.
>
> This looks to me like the scope of the document was reduced to not
> change IPv6 allocation methods, but the text wasn't updated to be
> consistent with that change.
>
> There are still issues with some of the allocations that are left
> ambiguous.
>
> The text needs a "which hunt".  I think most uses of "which" should be
> "that".
>
> Many specific comments below.
>
> Bob
>
>
>>
>>
>>
>> Network Working Group                                        A. McDonald
>> Internet-Draft                                              Siemens/Roke
>> Updates: RFC2113, RFC2711                                      J. Manner
>> (if approved)                                                        TKK
>> Intended status: Standards Track                       February 25, 2008
>> Expires: August 28, 2008
>>
>>
>>      IANA Considerations for the IPv4 and IPv6 Router Alert Option
>>                    draft-manner-router-alert-iana-02
>
> ....
>
>> Abstract
>>
>>    This document provides new instructions to IANA on the allocation of
>>    IPv4 and IPv6 Router Alert Option Values.
>>
>
> This isn't correct.  The current draft does not provide new
> instructions for IANA on the allocation of IPv6 Router Alert Option
> Values.  Quoting from Section 3.2:  "The registry for IPv6 Router
> Alert Option Values should continue to be maintained as specified in
> [RFC2711]."  It does change two assignments, but the procedure doesn't
> change.
>
> ...
>
>>
>>
>> 1.  Introduction
>>
>>    The IP Router Alert Option is defined for IPv4 in [RFC2113].  A
>>    similar IPv6 option is defined in [RFC2711].  When one of these
>>    options is present in an IP datagram, it indicates that the contents
>>    of the datagram may be interesting to routers.  The Router Alert
>>    Option (RAO) is used by protocols such as RSVP [RFC2205] and IGMP
>>    [RFC3376].
>>
>>    Both the IPv4 and IPv6 option contain a two octet value field to
>>    carry extra information.  This information can be used, for example,
>>    by routers to determine whether or not the packet should be more
>>    closely examined by them.
>>
>>    This document proposes the creation of a new IANA registry for
>>    managing IPv4 Router Alert Option Values.  In conjunction with this,
>>    it also proposes an update to the way in which IPv6 Router Alert
>>    Option Values are assigned in the existing IANA registry, and
>>    proposes small changes to the current allocations.
>
> ditto as above.
>
>> 2.  Use of the Router Alert Option Value Field
>>
>>    Alert Options is the way in which values for the value field are
>>    managed.  In [RFC2113], the IPv4 Router Alert Option value field has
>>    the value 0 assigned to "Router shall examine packet".  All other
>>    The IPv6 Router Alert Option has an IANA managed registry
>>    [IANA-IPv6RAO] containing allocations for the value field.  All
>>    values in this registry are assigned by IETF consensus.
>>
>>    In [RFC3175] the IPv4 Router Alert Option Value is described as a
>>    parameter which provides "additional information" to the router in
>>    making its interception decision, rather than as a registry managed
>>    by IANA.  As such, this aggregation mechanism makes use of the value
>>    field to carry the reservation aggregation level.  For the IPv6
>>    option, this document requests a set of 32 values to be assigned by
>>    IANA for indicating reservation levels.  However, since other
>>    registrations had already been made in that registry these values are
>>    from 3-35 (which is actually a set of 33 values).
>>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 3]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    Although it would be desirable to have the same values being used in
>
> s/it would be/it might have been/
>
>>    both the IPv4 and IPv6 registries, the initial allocations in
>>    [RFC2711] and the aggregation level allocations in [RFC3175] have
>>    made this impossible.  The following table shows the allocations in
>>    the IPv6 registry and values used in the IPv4 registry, where the
>>    latter have been deduced from [RFC2113] and [RFC3175] with the
>>    assumption that the number of aggregation levels can be limited to 32
>>    as in the IPv6 case.  Entries for values 6 to 31 have been elided for
>>    brevity.
>>
>>    +----------+-------------------------+------------------------------+
>>    | Value    | IPv4 RAO Meaning        | IPv6 RAO Meaning             |
>>    +----------+-------------------------+------------------------------+
>>    | 0        | Router shall examine    | Datagram contains a          |
>>    |          | packet [RFC2113]        | Multicast Listener Discovery |
>>    |          | [RFC2205] [RFC3376]     | message [RFC2711] [RFC2710]  |
>>    |          | [RFC4286]               | [RFC4286]                    |
>>    | 1        | Aggregated Reservation  | Datagram contains RSVP       |
>>    |          | Nesting Level 1         | message [RFC2711] [RFC2205]  |
>>    |          | [RFC3175]               |                              |
>>    | 2        | Aggregated Reservation  | Datagram contains an Active  |
>>    |          | Nesting Level 2         | Networks message [RFC2711]   |
>>    |          | [RFC3175]               | [Schwartz2000]               |
>>    | 3        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 3         | Nesting Level 0 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | 4        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 4         | Nesting Level 1 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | 5        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 5         | Nesting Level 2 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | ...      | ...                     | ...                          |
>>    | 32       | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 32        | Nesting Level 29 [RFC3175]   |
>>    |          | [RFC3175]               |                              |
>>    | 33       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 30 [RFC3175]   |
>>    | 34       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 31 [RFC3175]   |
>>    | 35       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 32(?)          |
>
>
> The question mark (discussion below) needs to be resolved.  This would
> be better if the "?" was replaced with an "*" and the text below was a
> note.
>
>
>>    |          |                         | [RFC3175]                    |
>>    | 36-65534 | Reserved                | Reserved to IANA for future  |
>>    |          |                         | use                          |
>>    | 65535    | Reserved                | Reserved [IANA-IPv6RAO]      |
>>    +----------+-------------------------+------------------------------+
>>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 4]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    The entry in the above table for the IPv6 RAO Value of 35 (Aggregated
>>    Reservation Nesting Level 32) 2 has been marked with a question mark
>>    due to an inconsistency in the text of [RFC3175], which is
>>    consequently reflected in the IANA registry.  In that document the
>>    values 3-35 (i.e. 33 values) are defined for nesting levels 0-31
>>    (i.e. 32 levels).
>
> The above should be a note.  Should this document define how to
> resolve this issue? I don't know the answer.
>
>>    It is unclear why nesting levels begin at 1 for IPv4 (described in
>>    section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
>>    [RFC3175]).
>
> I would guess because IPv4 tended to keep zero values reserved, and
> IPv6 did not.  This is just a guess.
>
>>
>>
>> 3.  IANA Considerations
>>
>>    This section contains the proposed new procedures for managing Router
>>    Alert Option Values.  This requires the creation of a registry for
>
> s/Router Alert Option/IPv4 Router Alert Option/
>
>>    IPv4 Router Alert Option Values (described in Section 3.1) and
>>    changes to the way in which IPv6 Router Alert Option Values are
>>    managed (described in Section 3.2).
>
> There isn't any changes to the way that IPv6 Router Alert Options
> Values are managed.
>
>>
>> 3.1.  IANA Considerations for IPv4 Router Alert Option Values
>>
>>    The value field, as specified in [RFC2113] is two octets in length.
>>    The value field is registered and maintained by IANA.  The initial
>>    contents of this registry are:
>>
>>     +-------------+--------------------------------------+-----------+
>>     | Value       | Description                          | Reference |
>>     +-------------+--------------------------------------+-----------+
>>     | 0           | Router shall examine packet          | [RFC2113] |
>>     | 1-32        | Aggregated Reservation Nesting Level | [RFC3175] |
>>     | 33-65502    | Reserved to IANA for future use      |           |
>>     | 65503-65534 | Reserved for experimental use        |           |
>>     | 65535       | Reserved                             |           |
>>     +-------------+--------------------------------------+-----------+
>>
>>    New values are to be assigned via IETF Consensus as defined in
>>    [RFC2434].
>>
>> 3.2.  IANA Considerations for IPv6 Router Alert Option Values
>>
>>    The registry for IPv6 Router Alert Option Values should continue to
>>    be maintained as specified in [RFC2711].
>>
>>    In addition, the following value should be removed from the IANA
>>    registry and reserved for possible future use (not to be allocated
>>    level 0 means end-to-end signaling, and this already has an IPv6 RAO
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 5]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    value "1" assigned.
>>
>>    3: "RSVP Aggregation level 0"
>
>
> I don't know if this change will effect any implementations.  If
> anyone is using the "3" value, then this would require this code to
> change.  This needs to be better understood before making this
> change.  Was this a mistake in RFC3175?  If so, this should be
> described and this document should be an update to RFC3175 as well. 
> But again, if this breaks running code, than the change probably
> shouldn't be made.
>
> Also, the above text is a little hard to parse.  It took me a while to
> figure out that it was the 3: value being changed.
>
>>
>>    The following IPv6 RAO values should be reserved for experimental
>>    use:
>>
>>    65503-65534: "Experimental use"
>>
>>
>> 4.  Security Considerations
>>
>>    Since this document is only concerned with the IANA management of the
>>    IPv4 and IPv6 Router Alert Option values registry it raises no new
>>    security issues beyond those identified in [RFC2113] and [RFC2711].
>>
>>
>> 5.  Acknowledgements
>>
>>    Thanks to Robert Hancock, Martin Stiemerling, Alan Ford and Francois
>>    Le Faucher for their helpful comments on this document.
>>
>>
>> 6.  References
>>
>> 6.1.  Normative References
>>
>>    [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
>>               February 1997.
>>
>>    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>>               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
>>               October 1998.
>>
>>    [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
>>               RFC 2711, October 1999.
>>
>>    [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
>>               "Aggregation of RSVP for IPv4 and IPv6 Reservations",
>>               RFC 3175, September 2001.
>>
>>  6.2.   Informative References
>>
>>     [IANA-IPv6RAO]
>>                "IANA Registry for Internet Protocol version 6 (IPv6)
>>               Router Alert Option Values" .
>>
>>               <http://www.iana.org/assignments/ipv6-routeralert-values>
>
>
> Since this document is changing the above, it should be a Normative
> reference.
>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 6]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
>>               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
>>               Functional Specification", RFC 2205, September 1997.
>>
>>    [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
>>               Listener Discovery (MLD) for IPv6", RFC 2710,
>>               October 1999.
>>
>>    [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
>>               Thyagarajan, "Internet Group Management Protocol, Version
>>               3", RFC 3376, October 2002.
>>
>>    [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
>>               RFC 4286, December 2005.
>>
>>    [Schwartz2000]
>>               Schwartz, B., Jackson, A., Strayer, W., Zhou, W.,
>>               Rockwell, D., and C. Partridge, "Smart Packets: Applying
>>               Active Networks to Network Management", ACM Transactions
>>               on Computer Systems (TOCS) Volume 18 ,  Issue 1,
>>               February 2000.
>>
>>
>
>

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 7 May 2008 04:37:51 -0500

Jari,

	I have two comments on this draft.

1.
	In section 3.1, it is not absolutely clear that the range
33 - 65502 is meant to be used when assigning IETF consensus 
defined values by IANA.  The table says the values are for IANA
future use (without specfying what that use is), while the text
that follows the table does not specify a range (or row entry).

	I suggest replacing "... IANA for future use" with "...
IANA for future assignment."

2.
	In section 3.2, I would suggest inserting a properly dis-
ambiguated table (similar to the one in 3.1) as a visual aid to
understanding the text in this section.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Monday, May 05, 2008 9:58 AM
> To: Internet Area
> Cc: [email-masked]
> Subject: Re: [Int-area] draft-manner-router-alert-iana WGLC
>