The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Shahram,

	Thanks for the helpful pointers.

	Could you please explain how 1) the egress would
signal to the penultimate hop that it needs to do multiple
pops or 2) how the penultimate hop would be able to do it
on its own (given that it is not supposed to look at the
rest of the packet having popped one label)?  Has someone
secretly allocated the special label values '4' to mean
implicit NULL/PHP twice, '5' to mean implicit NULL/PHP
three times, and so on?  PHP is architecturally a signaled
- as opposed to a local - behavior.

	Also, see comments in line...

--
Eric Gray

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Monday, June 26, 2000 11:42 AM
> To: 'Puneet Agarwal'; 'mpls@uu.net'
> Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
> 
> 
> Puneet,
> 
> Please see my comments:
> 
> >-----Original Message-----
> >From: Puneet Agarwal [mailto:puneet@pluris.com]
> >Sent: Friday, June 23, 2000 8: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. 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.
> >
> >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.
> 
> Not necessarily. This restriction applies only to Uniform 
> model. In case of Pipe model, the PHP does not need to know 
> anything about lower LSP, it just pops and forwards the 
> packet without modifying the lower label.
> 
> The case of Uniform model is already mentioned in section 2.6.6:
> 
> "- when the multiple pop operations are performed by the 
> Penultimate LSR, note that to perform Encoding of Diff-Serv       
> Information, the Penultimate LSR needs to be aware of the 
> "Set of PHB-->Encaps mappings" for the label corresponding 
> to the exposed header after all the pop operations (or the 
> PHB-->DSCP mapping). Methods for providing this mapping 
> awareness are outside the scope of this specification."

As stated in my last call comments, the above text makes no
sense and should be removed.  Multi-pop PHP is a non-starter.

> 
> And section 2.6.3:
> 
> "Note that to do so, the Penultimate LSR needs to be aware 
> of the "Set of PHB-->Encaps mappings" for the label 
> corresponding to the exposed header (or the PHB-->DSCP 
> mapping). Methods for providing this mapping awareness are 
> outside the scope of this specification."

I don't think that you can punt on this one.  The specific
example that you yourself gave for when the Uniform model
is useful involved a usage of LSP tunnels in which DiffServ
and the LSP Tunnel usage were orthogonal.  In this case, the
mapping is presumably 'simple identity' (i.e. - within the 
same administrative domain, the PHB is likely to be 'uniform' 
throughout the administrative domain; therefore PHB-p maps to
PHB-q if and only if PHB-p = PHB-q).

No one has proposed an application for the Uniform model in
which this would not be the case.  In addition, the intuitive
meaning of 'Uniform' implies this behavior.  Therefore, not
stating this simplistic relationship leaves too many options
available to the implementer and will most likely lead to a
lot of interoperability problems.

> 
> The type of LSP is implicit in the PHB -> Encaps mapping. And 
> the Egress LSR must know the mapping regardless of the type of 
> the LSP.
> 
  ... <snip> ...
> 
> And Section 2.6.6:
> 
> "LSRs at different levels of LSPs are expected to operate in 
> the same or in different Tunneling Models."

This specific statement is also mentioned in my last call
comments.  Its informational content is dubious at best,
being analogous to "an orange is either the same as an apple
or different".

> 
  ... <snip> ...
> 
> Regards,
> -Shahram
> 
> >
> >-Puneet
> >
>