Subject: [NSIS] QoS NSLP - aggregation marking

From: Andrew McDonald <[email-masked]>
Date: Mon, 13 Mar 2006 17:58:06 +0000

Hi all,

Some thoughts/issues from thinking about the aggregation aspects of the 
QoS NSLP:

The current text in 4.6/4.7 is a bit too vague on what happens: "The 
marking MUST be accomplished by the Aggregator by modifying the QoS-NSLP 
default NSLP-ID value to a NSLP-ID predefined value."
What 'predefined value'?
Is only a single aggregation level being proposed (i.e. like RFC3175 
RSVP/RSVP-E2E-IGNORE protocol remarking, but not like RFC3175 RAO value 
remarking)?

Is there any reasoning for why a method using remarking is used?

Section 3.4 of the extensibility draft, draft-loughney-nsis-ext-02.txt, 
talks about the two ways that aggregation marking can be made to work:
1) all routers process at 'aggregation level 0'; routers are configured 
at the ingress remark messages to a higher level; routers at the egress 
remark messages to a lower level
2) routers are configured to process messages at a particular 
'aggregation level' and ignore all others; aggregate-related messages 
are marked at a different level to end-to-end messages; messages are 
never remarked

The extensibility draft says:
    The first technique requires aggregating/deaggregating routers to be
    configured with which of their interfaces lie at which aggregation
    level, and also requires consistent message rewriting at these
    boundaries.  The second technique eliminates the rewriting, but
    requires interior routers to be configured also.  It is not clear
    what the right trade-off between these options is.

There are also some differences when things go wrong:
- in (1), e2e (remarked) messages that 'escape' (e.g. misconfigured 
egress) get ignored at regular routers, but should probably also be 
flagged as an error if coming into an edge router on the wrong 
interface. Messages for an aggregate that 'escape' are essentially 
undetectable through basic NSLP processing - it may be picked up by 
policy control mechanisms.
- in (2), e2e messages are not remarked, so if they 'escape' they are 
correctly processed by routers outside the aggregation region. Messages 
for an aggregate that escape from the region are ignored at regular 
routers, but should probably also be flagged as an error if coming into 
an edge router on the wrong interface.

We should probably say something more about the error cases (at least 
the ones that we can potentially catch).

The QoS NSLP draft has chosen (1), but doesn't include any rationale. 
Given that the extensibility draft says "you have a choice" it might be 
useful to do so. I'm not sure why we've chosen (1), other than that is 
the way RFC3175 does it.

There were IESG concerns about the internet draft that became RFC3175, 
see past IETF proceedings:
http://www3.ietf.org/proceedings/00dec/00dec-138.htm
http://www3.ietf.org/proceedings/01mar/ietf50-142.htm
The concerns are focussed on the IP protocol remarking rather than the 
RAO value remarking. It appears that the concerns were addressed by 
changes in the security considerations section. In our case, the NSLP ID 
remarking is similar to the IP protocol remarking, and the security 
considerations are likely to be similar. (Since the choice of RAO value 
follows on from the NSLP ID choice, we need to decide the NSLP ID 
marking policy first.)

Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID combination 
stays constant along the path, which simplifies diagnostics. The failure 
case (described above) also seems better. So, it's not entirely clear to 
me why (1) is preferred over (2).

regards,
Andrew

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 14 Mar 2006 08:47:14 +0100 (MET)

Hallo Andrew

I thought that we have discussed this issue and decided to use (1).

Best Regards,
Georgios

---

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

Georgios,

I think Andrew just wants some extra explaination in the document.  The
extensibility draft basically says that for any NSLP (1) or (2) is
possible,
and my feeling is that it is up to the NSLP to decide which is better.

So, I think having some justification in the QoS NSLP would be a good
thing.

John

>-----Original Message-----
>From: ext Georgios Karagiannis [mailto:[email-masked]] 
>Sent: 14 March, 2006 09:47
>To: [email-masked]; [email-masked]
>Subject: Re: [NSIS] QoS NSLP - aggregation marking
>
>
>Hallo Andrew
>
>>marking MUST be accomplished by the Aggregator by modifying the 
>>QoS-NSLP default NSLP-ID value to a NSLP-ID predefined value."
>>What 'predefined value'?

>>changes in the security considerations section. In our case, the NSLP 
>>ID remarking is similar to the IP protocol remarking, and the security

>>Not remarking seems 'cleaner' in that the NSLP-ID+Session-ID 
>>combination stays constant along the path, which simplifies 
>>diagnostics. The failure case (described above) also seems better. So,

>>it's not entirely clear to me why (1) is preferred over (2).
>>
>>
>>regards,
>>Andrew
>>
>>

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 19 Mar 2006 09:07:28 -0600

My concern about this is that option (1) just seems like an inferior
approach, and I'd like to understand why I'm wrong.

Part of the concern is about resilience-against-misconfiguration
issue noted below: a domain which muddles up its remarking rules
breaks the end-to-end operation and has to depend on downstream
domains to detect the problem and guess how to fix things.
Misconfiguration in option (2) gets locally detected and fixed.
Related to this is that option (1) imposes quite a strict topology
constraint on how aggregation is done (they have to be simple and
convex).

It also just doesn't feel right. To me, the signalling message 
represents an end system's desire for a resource reservation. 
That desire didn't metamorphose into something else just because
an operator defined an aggregation region; what has happened is
that the routers in that region have decided not to be interested
in that sort of message, and that should be reflected in the 
router's own configuration.

For a concrete implication of this, suppose at some point in the
future that the QoS-NSLP/qspec/policy combination acquired more 
multi-hop knowledge (e.g. as part of some more sophisticated price
distribution mechanisms). You would probably protect payload elements
over those multiple hops, including the NSLPID. So it makes sense
(to me) to think of the NSLPID as something which is not changed
in handling this sort of requirement.

r.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 18 March 2006 12:10
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [NSIS] QoS NSLP - aggregation marking
> 
> 
> Georgios,
> 
> >>    The first technique requires aggregating/deaggregating 
> routers to
> be

---

From: <[email-masked]>
Date: Sun, 19 Mar 2006 18:12:04 +0200

Chair-hat off, I tend to concur with Robert.  Re-writing is also
something that tends to get the IESG nervous, so we should have
a good reason for doing the re-writing.

While re-reading the spec on my flight, I had similar concerns about
misconfiguration.  Also, just wondering if there could be situations
where re-rewriting doesn't occur, and the signaling escapes the local
network with the rewritten fields.  If this would happen, then the 
end-to-end signaling would be broken.

John

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 19 March, 2006 17:07
>To: Loughney John (Nokia-NRC/Helsinki); 
>[email-masked]; [email-masked]; [email-masked]
>My concern about this is that option (1) just seems like an 
>inferior approach, and I'd like to understand why I'm wrong.
>
>issue noted below: a domain which muddles up its remarking 
>rules breaks the end-to-end operation and has to depend on 
>downstream domains to detect the problem and guess how to fix things.
>Related to this is that option (1) imposes quite a strict 
>topology constraint on how aggregation is done (they have to 
>be simple and convex).
>
>That desire didn't metamorphose into something else just 
>because an operator defined an aggregation region; what has 
>happened is that the routers in that region have decided not 
>to be interested in that sort of message, and that should be 
>reflected in the router's own configuration.
>
>For a concrete implication of this, suppose at some point in 
>the future that the QoS-NSLP/qspec/policy combination acquired 
>more multi-hop knowledge (e.g. as part of some more 
>sophisticated price distribution mechanisms). You would 
>probably protect payload elements over those multiple hops, 
>including the NSLPID. So it makes sense (to me) to think of 
>the NSLPID as something which is not changed in handling this 
>sort of requirement.
>
>r.
>
>> I think Andrew just wants some extra explaination in the document.  
>> The extensibility draft basically says that for any NSLP (1) 
>or (2) is 
>> possible, and my feeling is that it is up to the NSLP to 
>decide which 
>> is better.
>> 
>> >>Given that the extensibility draft says "you have a 
>choice" it might
>> be