Subject: draft-ietf-mpls-diff-ext-05.txt comments

From: Puneet Agarwal <[email-masked]>
Date: Fri, 23 Jun 2000 17:37:30 -0700

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.

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

3) pg 36, 3rd paragraph - recognizes --> recognize

4) pg 36, 5th paragraph: when a LSR can only support preconfigured
EXP <--> PHB mapping, if someone wants to set up the per label EXP <--> PHB
mapping, what error should the LSR return? Hopefully this error code is
different than "Diff-Serv Error" to differentiate it from invalid
EXP <--> PHB mapping.

-Puneet

---

From: Puneet Agarwal <[email-masked]>
Date: Mon, 26 Jun 2000 19:09:01 -0700

Shahram,

Please see my comments below.

>-----Original Message-----
>From: Shahram Davari [mailto:[email-masked]]
>Sent: Monday, June 26, 2000 11:42 AM
>To: 'Puneet Agarwal'; [email-masked]'
>Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>Puneet,
>
>Please see my comments:
>
>>-----Original Message-----
>>From: Puneet Agarwal [mailto:[email-masked]]
>>Sent: Friday, June 23, 2000 8:38 PM
>>To: [email-masked]'
>>Subject: draft-ietf-mpls-diff-ext-05.txt comments
>>
>>
>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."
>
>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."
>
>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.
>

The problem (as you stated) arises at the Penultimate LSR in the Uniform
model. If "Methods for providing this mapping awareness are outside the
scope of this specification", then you really have 2 choices for deployment:
(a) Invent your own protocol to signal the PHB-> EXP information from the
egress LSR to Penultimate LSR for each encapsulated LSP carried in the outer
LSP. The Penultimate LSR would still need to look at the encapsulted LSP to
figure out which PHB->EXP mapping to apply.
OR 
(b) Require that every encapsulated LSP have the same PHB-> EXP mapping as
the top LSP (being PHPed). This also implies that you cannot have E-LSPs
encapsulated in L-LSPs and vica-versa.

It would be nice to add this clarification to the draft (could be in an
appendix).

>This is also explained in Section 2.6.4:
>
>"the LSP Ingress, when performing the push operation, encodes 
>the       LSP
>Diff-Serv information in the label entry that is pushed       
>("outer label
>entry") and encodes the Tunneled Diff-Serv       Information in the
>encapsulated header (IP header or swapped      label entry)."
>
>And Section 2.6.6:
>
>"LSRs at different levels of LSPs are expected to operate in 
>the same or in
>different Tunneling Models."
>
>"For support of M levels of push in the Pipe Model:
> - when performing multiple push operations, the LSR:
>      o encodes Diff-Serv Information corresponding to the
>        Outgoing PHB in the transmitted label entry corresponding
>        to the LAST pushed label (ie the label pushed in the outer
>        label entry).
>      o encodes Diff-Serv Information corresponding to the
>Incoming PHB in the encapsulated header (swapped label
>        entry or IP header) as well as in the label entries for
>        all the pushed labels (except the last pushed label)."
>
>Which basically says that the LSR doing the PUSH operation 
>will encode each
>level of push according to its type, and the details of each type is
>described in E-LSP and L-LSP sections. 
>
I just wanted the draft to highlight that potentially the ingress LSR would
need to  encode a *different* PHB-> EXP mapping for *each* encapsulated
header. It would make it clear to hw designers the hw hooks they need to
implement in order to support multiple push operations. As written in the
current draft, it is very easy to miss this fact.

Thanks.

-Puneet

---

From: Eric Gray <[email-masked]>
Date: Tue, 27 Jun 2000 09:46:47 -0700

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

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

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 Egress LSR must know the mapping regardless of the type of 
> the LSP.
> 
  ... <snip> ...
> 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