The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

Philip,

At 00:24 17/03/2001 -0500, Philip Matthews wrote:
>Francois:
>
>Sorry, but I am a bit behind in my MPLS WG mailing list reading.
>Back in February, you posted the following comment to the MPLS WG
>mailing list.
>
>
>Francois Le Faucheur wrote:
>> Subsequent to the MPLS WG Last Call, a special Diff-Serv WG Last Call was
>> issued on <draft-ietf-mpls-diff-ext-07.txt> at the request of the Area
>> Directors.
>> 
>> We received comments relating to two items. Below are the details of the
>> planned resolution for both items.
>
>..snip ... 
>
>> Incoming PHB Determination with Pipe Model
>> ===========================================
>> We received pretty much the same comment from several people (Service
>> Providers as well as vendors) on one detailed aspect of the Pipe model:
>> output scheduling at egress of a Pipe LSP.
>> "xx-07.txt" specifies that, in the Pipe model, the egress LSR does incoming
>> PHB determination based on the "inner header" (ie after the POP). We
plan to:
>>         - keep such a behavior, but make it an optional variation of the
Pipe model
>>         - define an alternative behavior where the egress LSR does
incoming PHB
>> determination based on the "outer header" (ie before the POP). This will be
>> the normal egress behavior for the Pipe Model.
>> All the other aspects of the Pipe model are unchanged.
>> 
>> The rationale for using "outer header" by default on egress of Pipe is the
>> following:
>>         - the typical application of the Pipe model is where a Service
Provider
>> (SP) transports traffic from a customer who uses a different Diff-Serv
>> policy to the SP's Diff-Serv policy. Doing scheduling on LSP Egress based
>> on the outer header (and assuming no PHP) allows the Service Provider to
>> configure scheduling based on its own Diff-Serv policy. Doing scheduling
>> based on the inner header forces the Service Provider to be aware of each
>> and every customer Diff-Serv policy and forces the SP to configure
>> scheduling differently for each customer Diff-Serv policy. The most common
>> situation will be that the SP does not want to be even aware of the
>> Customer Diff-Serv policy and thus need to use the outer header.
>> (There will be cases where the SP may accept the operational overhead of
>> being aware of the customer's Diff-Serv policy and sell "egress scheduling
>> based on customer's policy" as a value add; this is why we keep the use of
>> inner header as an option. But this will be less common.)
>
>It seems very strange to me to schedule the packet based on the outer header,
>but forward the packet based on the inner header.
>

>From a Service Provider's viewpoint this is not strange at all. It simply
means 
that the SP will be doing scheduling on the egress interface based on his 
Diff-Serv policy rather than on one of many many different end-customer's own 
Diff-Serv policy.
Typically, the "pipe" model is precisely used so that the end-customer's
Diff-SErv 
policy is hidden from SP and vice-versa. So , often, the SP has no idea
whatsoever 
about what EXP=eee means in the inner header.

Really, the PIpe Model can be looked at as extending the SP Diff-SErv
policy right 
through to the egress interface of the egress LSR (wheras with the Short
PIpe, 
the egress interface of egress LSR should be looked at as within the
end-customer 
Diff-Serv domain). From my discussions with SPs, by and large, they prefer
the model 
where they run their own Diff-Serv policy on all egress interfaces rather
than one 
differnet Diff-Serv policy on every egress interface.

Cheers

Francois

>This solution seems particularly strange to me when the router is popping
>two or more labels; that is, terminating two or more pipe-model LSPs at once.
>In this case, using the outermost header seems particularly arbitrary.
>
>I make these comments while in the middle of implementing this draft.
>The way it was before makes for a very logical implementation, while this
>new proposal will add some weirdness.
>
>It seems to me that what the service providers really want is a form of PHP:
>that is, they want to both schedule and forward the packet based on the outer
>header, but pop the header just before forwarding the packet. 
>
>Comments?
>
>- Philip Matthews
>  Nortel Networks
>