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

From: Shahram Davari <[email-masked]>
Date: Mon, 26 Jun 2000 11:41:59 -0700

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

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.

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

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. 

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

Fine.

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

As mentioned in section 5.3, two scenarios may exist:

1) In case the node only supports configured E-LSP, the node does not
recognize Diffserv object at all -> "Unknown Object Error"

2) In case the node supports configured E-LSP and L-LSP, The node does not
recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"

Regards,
-Shahram

>-Puneet

---

From: Bora Akyol <[email-masked]>
Date: Mon, 26 Jun 2000 12:44:52 -0700

Shahram
Comments within.

> Please see my comments:

<<snipped>>

> recognize C-type = 1 (Signaled E-LSP) -> "Unknown Object C-type"

Why not have another error code for nodes that understand the DS object but can
not provide per-label context. This makes sense to me.