Subject: [NSIS] NSLP IDs and RAO values

From: Andrew McDonald <[email-masked]>
Date: Mon, 13 Mar 2006 14:59:24 +0000

Hi all,

In thinking about the aggregation parts of the QoS NSLP draft, there are 
some IANA-related issues:
- IANA considerations currently requests a single NSLP ID for the QoS 
NSLP, the aggregation mechanism as described in 4.6/4.7 needs multiple 
NSLP IDs
- the document doesn't mentioned what Router Alert Option (RAO) values 
should be used for the NSLP ID(s) that are allocated

For IPv6, it is fairly clear that we should be asking for (or referring 
to) allocations in the IPv6 Router Alert Option Values (RFC2711) 
registry (http://www.iana.org/assignments/ipv6-routeralert-values). This 
contains the aggregation RAO values from RFC3175.

For IPv4 (RFC2113), I can't see an appropriate registry. I seem to 
remember discussing this before, but don't think we reached a 
conclusion. RFC2113 defines a value of 0, and leaves others reserved. 
Allocation by IANA of additional values is not mentioned. Is it 
implicitly assumed to be in step with the IPv6 list? Do we need to do 
something to make this explicit?

This is an issue for the NSLP drafts, and also relevant for the 
extensibility draft.

regards,

Andrew

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 13 Mar 2006 18:32:18 +0100 (MET)

Hi Andrew

Yes, I think that it is needed to explicitly describe the allocation by
IANA of additional values.

Best Regards,
Georgios

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 15 Mar 2006 10:42:21 +0000

> IANA of additional values.

 From an off-list clarification (posted with permission):
Georgios Karagiannis wrote:
 > What I mean is:
 > In my opinion it is implicitly assumed to be in step with the
 > IPv6 list.
 > This should be made explicit in the QoS-NSLP draft, etc...

I would have thought this would need an update to RFC2113 (doing it in 
the QoS NSLP draft seems a bit odd to me from a process point of view).

Also, having checked a bit further, it doesn't look to me as if the 
IPv4/IPv6 RAO values are in step since:
IPv4: 0 - Router shall examine packet (RFC2113)
IPv6: 0 - Datagram contains a Multicast Listener Discovery message 
(RFC2710/RFC2711)

To add slightly more to my confusion, RFC2113 defines:
    Value:  A two octet code with the following values:
      0 - Router shall examine packet
      1-65535 - Reserved
<<<
and says:
    Hosts shall ignore this option.  Routers that do not recognize this
    option shall ignore it.  Routers that recognize this option shall
    examine packets carrying it more closely (check the IP Protocol
    field, for example) to determine whether or not further processing is
    necessary.  Unrecognized value fields shall be silently ignored.

    The semantics of other values in the Value field are for further
    study.
<<<
RFC3175 then says:
    The IPv4 Router
    Alert [RFC2113] has the option simply to ask the router to look at
    the protocol type of the intercepted datagram and decide what to do
    with it; the parameter is additional information to that decision.
<<<
and defines a use for the 'Reserved' values to indicate the aggregation 
level. However, there is no explicit update of RFC2113 to redefine (and 
provide new semantics for) those reserved values.

Andrew

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 16 Mar 2006 09:49:40 +0100

Hi all,

Good catch by Andrew on the NSLP IDs and RAO. The RAO value is also  
missing in the NATFW NSLP and is now issue No. 71 (https:// 
kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue71).
There is no need for the NATFW NSLP to have multiple RAO values,  
since there is no aggregation on this level.

More inline.

Am 15.03.2006 um 11:42 schrieb Andrew McDonald:

> I would have thought this would need an update to RFC2113 (doing it  
> in the QoS NSLP draft seems a bit odd to me from a process point of  
> view).

This is probably a procedural question:
What happens if there is a document specifying protocol values that  
actually should be administrated by IANA, *BUT* the request to IANA  
was not issued at the time the RFC was made?
Does this require a RFC 2113 bis or is it sufficient to get IANA on  
board by an IESG decision?

> IPv6: 0 - Datagram contains a Multicast Listener Discovery message  

There are not in step, since there is no IANA registry for IPv4 and  
IPv6 has already these entries (http://www.iana.org/assignments/ipv6- 
routeralert-values):
Value	 Description					 Reference
-----  	 --------------------------------------------- 	 ---------
     0    Datagram contains a Multicast Listener          [RFC2711]
          Discovery message                               [RFC2710]
     1	 Datagram contains RSVP message 		 [RFC2711]
     2    Datagram contains an Active Networks message    [RFC2711]
3-35    Aggregated Reservation Nesting Level		 [RFC3175]
36-65534 Reserved to IANA for future use
65535    Reserved					 [IANA]

> and defines a use for the 'Reserved' values to indicate the  
> aggregation level. However, there is no explicit update of RFC2113  
> to redefine (and provide new semantics for) those reserved values.

I see this as a big mistake of RFC 3175.
We could try to meet with the RFC 3175 authors and have a quick chat  
with them about it.

   Martin

---

From: <[email-masked]>
Date: Sat, 18 Mar 2006 20:03:18 +0200

Andrew,

Couple of questions:

>In thinking about the aggregation parts of the QoS NSLP draft, 
>there are some IANA-related issues:
>- IANA considerations currently requests a single NSLP ID for 
>the QoS NSLP, the aggregation mechanism as described in 
>4.6/4.7 needs multiple NSLP IDs

>From 4.6, it says:

     The marking MUST be accomplished by the Aggregator by
   modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined
   value. 

This text somewhat confuses me, and I confess that I missed this
earlier.
I guess the idea is to use different RAO for aggregated reservation
nesting? Would we have 1 NSLP-ID per nested reservation? Or something
else?

>- the document doesn't mentioned what Router Alert Option 
>(RAO) values should be used for the NSLP ID(s) that are allocated

This should be fixed in the QoS NSLP, IMO.  I think it should mention
how to match the RAO with NSLPIDs.

>to) allocations in the IPv6 Router Alert Option Values (RFC2711)
registry 
>(http://www.iana.org/assignments/ipv6-routeralert-values). 
>This contains the aggregation RAO values from RFC3175.

This is what we would use in the QoS NSLP, correct?  I guess the QOS
NSLP
should say something about this.

>For IPv4 (RFC2113), I can't see an appropriate registry. I 
>seem to remember discussing this before, but don't think we 
>reached a conclusion. RFC2113 defines a value of 0, and leaves 
>others reserved. 

I will check on this.

>Allocation by IANA of additional values is not mentioned. Is 
>it implicitly assumed to be in step with the IPv6 list? Do we 
>need to do something to make this explicit?

I think we need to say what RAO we need to use, and if we need
to allocate them, then that would be the IANA considerations.

>This is an issue for the NSLP drafts, and also relevant for 
>the extensibility draft.

Agreed. However, I think for the Extensibility draft, the general
relationship between the RAO & NSLP could be discussed, but I'm
not sure if there should be much else.  

Thoughts?
John

---

From: <[email-masked]>
Date: Sat, 18 Mar 2006 20:05:36 +0200

Andrew,

I'll try to sort out the RAO for IPv4 and get back with a solution.

John

>-----Original Message-----
>From: ext Andrew McDonald [mailto:[email-masked]] 
>Sent: 15 March, 2006 12:42
>To: Georgios Karagiannis
>Cc: [email-masked]
>Subject: Re: [NSIS] NSLP IDs and RAO values
>
>> Yes, I think that it is needed to explicitly describe the allocation 
>> by IANA of additional values.
>
> > In my opinion it is implicitly assumed to be in step with 
>the  > IPv6 list.
>I would have thought this would need an update to RFC2113 
>(doing it in the QoS NSLP draft seems a bit odd to me from a 
>process point of view).
>
>aggregation level. However, there is no explicit update of 
>RFC2113 to redefine (and provide new semantics for) those 
>reserved values.
>
>Andrew
>
>
>>> In thinking about the aggregation parts of the QoS NSLP 
>draft, there 
>>> are some IANA-related issues:
>>> NSLP, the aggregation mechanism as described in 4.6/4.7 needs 
>>> multiple NSLP IDs
>>> - the document doesn't mentioned what Router Alert Option (RAO) 
>>> values should be used for the NSLP ID(s) that are allocated
>>>
>>> registry (http://www.iana.org/assignments/ipv6-routeralert-values).