The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Puneet,

	Please see embedded comments below...

--
Eric Gray

> -----Original Message-----
> From: Puneet Agarwal [mailto:puneet@pluris.com]
> Sent: Friday, June 23, 2000 5:38 PM
> To: 'mpls@uu.net'
> Subject: draft-ietf-mpls-diff-ext-05.txt comments
> 
> 
> 1) The draft needs to detail the usage of hierarchical tunnel (HT)
> especially
> in the case of PHP. 
> 
> For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
> needs to know the PHB -> EXP mapping of the underlying 
> encapsulated tunnels. ...

This is not exactly true, although the effect is almost
the same.  The penultimate hop may need to know how the 
EXP field in the label being popped maps to the EXP field
in the next label.  This is not the same as having to 
know how the next downstream 'LSR' maps this new EXP value
to a PHB.  In addition, it is not clear that the penultimate
LSR would ever have to _change_ the value in a tunneled 
label's EXP field since it is likely that the EXP field value 
in the label being popped was derived from the EXP field value 
in the existing label when an initial label was pushed at the 
LSP-tunnel's ingress.

> ... Moreover, if a LSP is carrying multiple LSPs with 
> different PHB-> EXP mapping, the penultimate LSR and even 
> the egress LSR (in case of no PHP) would need to determine 
> (after Pop), the type of the underlying LSP.

The penultimate LSR would not care.  It would determine the
output interface, appropriate queue and other forwarding 
information from the label it received and it would pop that
label and blind-forward the remaining packet.  That is pretty
much the definition of PHP.

The downstream LSR, on the other hand, should already know 
what type of LSP the LSP-tunneled packet is on based on the
label that it assigned in the first place, that it is now
receiving.

> 
> Another example to illustrate this complexity:
> 
> Consider the case when a L-LSP is sent over a prior established 
> E-LSP. (The) Penultimate LSR for the E-LSP has no knowledge of 
> tunnels that are hierarchically going through it. Hence when it 
> does the penultimate POP, it has no knowledge about the PHB->EXP 
> encoding for the underlying L-LSP.
> In order to do this correctly, one would need to maintain 
> additional state associated with the outer E-LSP in order to do 
> the correct PHB-> EXP map for the encapsulated L-LSP.

Assuming I understand the question, the answer is 'No'.

The PHP makes an output queuing decision based on the label 
it received - prior to popping that label.  Again, this is
how PHP is done.  The newly exposed label of the packet it 
is about to forward has only an indirect relationship to the 
PHB that the penultimate LSR needs to apply in forwarding it.

> 
> 2) pg 21 - In the Pipe Model, when performing multiple push 
> operations, the LSR may need to be able to encode different 
> PHB->EXP markings for each pushed label in the stack

Yes.  However, the LSR that pushes a label onto the stack
is - by definition - the ingress for the LSP corresponding
to that label.  This is true regardless of how many labels
it pushes onto the stack.

Because an LSR is necessarily a part of the MPLS domain for 
LSPs for which it is the ingress, it should be possible to
configure PHB <==> EXP mappings for each such LSP.  Note 
that I am not saying that all such LSPs must be part of the
same domain - just that the LSR that acts as an ingress to
all such LSPs must be within the MPLS domain for each such
LSP (it can be part of multiple MPLS domains).

> 
> ...
> 
> -Puneet
>