The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Eric

See my comments

Eric Gray wrote:

> 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.
>

This depends whether it is PIPE or UNIFORM model. If it is uniform, then
the PHP LSR may need to change the EXP field of the inner tunnel.


>
> > ... 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.
>

Your statement here is what I would like to see as part of the spec, but
what the spec actually says is that the E-LSP must know what it is
carrying inside if it is doing PHP so that it can offer appropriate
treatment for E-LSPs vs L-LSPs.
Of course, it punts on how you actually get this information after the
fact.


>
> >
> > 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
> >

My opinion of this spec is that it is much better than the 04 version
but still requires more text on the corner cases and maybe less
repetitive text as was pointed out earlier.