Subject: [Diffserv] RE: MPLS Diffserv Extensions related questions/comments

From: Shahram Davari <[email-masked]>
Date: Thu, 1 Jun 2000 10:19:51 -0700

Hi Bora,

Please see my comments below:

>-----Original Message-----
>From: Bora Akyol [mailto:[email-masked]]
>Sent: Thursday, June 01, 2000 12:28 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: MPLS Diffserv Extensions related questions/comments
>
>
>I have a few questions on the 4th revision of this draft. 
>(Possibly with
>more to follow)
>
>1. Does this draft assume that an E-LSP is associated with 
>only one prefix?
>At least in our implementation, we can direct more than one 
>prefix into a
>single LSP.

No. An E-LSP is associated with one FEC. That FEC may include one or more
prefixes (see section 3.1).

>
>2. What happens when penultimate hop popping is used for an E-LSP? The
>penultimate hop really does not have knowledge about the EXP 
>mappings in the
>ultimate hop?

Let me extend your question to the two cases in the draft, (i.e.,Pipe and
Uniform tunnels):

1) Pipe: in this model there is no need for the penultimate hop to convey
the top label's diffserv information (i.e., before popping) to the ultimate
hop. What happens is that the top label's diffserv information is used by
the penultimate hop only for the diffserv scheduling and queuing treatment
in that node, while the packet is sent to the ultimate hop, without
modifying the lower label (the label after pop). Therefore there is no need
for the penultimate hop to know anything about EXP <=>PHB mapping of the
lower label entry.

1) Uniform: In this case the penultimate hop must convey the top label's
diffserv information to the ultimate node by encoding the lower label entry.
Therefore the penultimate hop SHOULD know (either by configuration or other
means) about the EXP <=>PHB mapping of the lower label and/or the LSP type
(E-LSP or L-LSP), otherwise PHP can't be used. In fact this applies to both
E-LSPs and L-LSPs in the Uniform model with PHP. So you are correct in this
case, and if my co-authors have no objection , we could add this restriction
to the draft. 

>
>3. How does one tie the output of the policing element in the 
>model to the
>EXP bits on the output direction of the label. Even though the 
>picture in
>the draft shows this connection, the text does not cover this.
>

It is explained in section 3.5 and 4.5  "Encoding Diffserv information in to
encapsulation layer on outgoing E-LSP and L-LSP". Basically after policing a
packet belonging to a PHB you derive a new PHB and then you can encode this
new PHB in to the EXP field using procedures explained in these sections.

>4. Why does the draft have so many forward references 
>especially in Chapter
>2. It would have been much better to first complete the 
>discussion on E-LSPs
>fully, then focus on L-LSPs. This makes the text difficult to follow.

The reason is that section 2 applies to both E-LSPs and L-LSPs and if we
want to first completely describe E-LSPs then L-LSPs, we need to repeat a
lot of text.

>
>5. The draft is vague on the following cases:
>	a) IP to MPLS label push
>	b) MPLS to IP label pop and route
>	c) MPLS to IP pop, then IP to MPLS push.

These operations are fully explained in section 2.6.3 and 2.6.4 for Uniform
and Pipe model. In our model we have tried to break down the push, pop and
other operations individually without describing all the possible
combinations, this makes the text much shorter and any possible combination
can be figured out by replacing the individual operation in the flow
diagram. If there is anything specific that you think we have not covered
please specify in more details, so that we can add it to the draft. 

>
>6. For the people that are actually using MPLS with Diffserv 
>rather than
>just the CoS bits, how are you using it?
>
>7. Is the terminology in the draft going to get updated to 
>sync up with the
>latest and greatest diffserv terminology ( I have to admit 
>that I tuned out
>that discussion about 3 weeks ago).

The terminology is already updated. If you have any specific doubt please
let us know.

>
>8. THIS IS A GRIPE. Did anyone consider hardware pipelining, 
>etc while this
>spec was being written? This actually is one of my biggest gripes about
>Diffserv. It is so damn flexible which makes almost any HW 
>implementation
>leave out features, maybe we should have started something 
>that was concrete
>and implementable.
>
>One suggestion, it may not be a bad idea at all to move at 
>least one of the
>examples to the front of the text to set some context.
>

Thanks for your suggestions.

Regards,
Shahram

>Thanks
>Bora Akyol

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Bora Akyol <[email-masked]>
Date: Thu, 1 Jun 2000 13:42:03 -0700

See Comments within:

By the way, I have version 04 of this draft from IETF web site, which
version do you have?

Thanks

Bora

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 10:20 AM
> To: 'Bora Akyol'; [email-masked]
> Cc: [email-masked]
> Subject: RE: MPLS Diffserv Extensions related questions/comments
> 
> 
> Hi Bora,
> 

I have read section 3.1 and it does not define what an FEC is. Which leads
me to believe that the FEC definition is the one that is used in LDP which
essentially is a prefix.

> Let me extend your question to the two cases in the draft, 

I am sorry in the version that I have there is no discussion of "pipe" or
"uniform" tunnels. I have -04 version, is there a newer version available.

> for the penultimate hop to know anything about EXP <=>PHB 

Yes, but what happens if the penultimate hop pop exposes an IP packet, then
what do I put in the DSCP field of the IP packet?

> case, and if my co-authors have no objection , we could add 

Yes, thank you.

> new PHB in to the EXP field using procedures explained in 

Copied from draft verbatim:

---------------

3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing
E-LSP

   This section defines the mandatory default method for encoding of
   Diff-Serv related information into the MPLS encapsulation Layer to
   be used when a packet is transmitted onto an E-LSP. This method
   requires that the `Set of PHB-->Encaps mappings' is populated as
   defined above in section 3.4.

   The LSR first determines the `Set of PHB-->Encaps Mapping'
   associated with the outer label of the NHLFE.

3.5.1 `PHB-->EXP mapping'

   For all the labels which are swapped or pushed, the LSR:
     - determines the PHB-->EXP mapping by looking up the
       `Set of PHB-->Encaps mapping' of the Diff-Serv context
       associated with the corresponding label in the NHLFE.
     - determines the value to be written in the EXP field of the
       corresponding level label entry by looking up the "outgoing PHB"
       in this PHB-->EXP mapping table.

3.5.2 `PHB-->802.1 mapping'

 Le Faucheur et. al                                                 13

                      MPLS Support of Diff-Serv               March 00

   If the `Set of PHB-->Encaps mapping' of the outer label contains a
   mapping of the form `PHB-->802.1 mapping', then the LSR:
     - determines the value to be written in the User_Priority field of
     the Tag Control Information of the 802.1 encapsulation header
     [IEEE_802.1], by looking up the "outgoing PHB" in this PHB-->802.1
     mapping table.
--------

Can you please show me where in the text above it is stated how to tie in
the policer input to the EXP-> PHB mapping, or PHB-> EXP mapping?

> want to first completely describe E-LSPs then L-LSPs, we need 

Unfortunately, makes it hard to follow.
> >	c) MPLS to IP pop, then IP to MPLS push.

Oops, my version does not have these sections.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 1 Jun 2000 15:12:01 -0700

Hi Bora,

Sorry my fault. I was answering your question from the Version -05 of the
draft, which will be released very soon. In any case I presented the Pipe
and Uniform model in Adelaide and we are currently finishing the final
details of this version. 

With this in mind, please see my comments:

>Sent: Thursday, June 01, 2000 4:42 PM
>To: 'Shahram Davari'; Bora Akyol; [email-masked]
>Cc: [email-masked]

This document is not the place to define FEC or other previously defined
terms. FEC is defined in Architecture and framework documents. They both
mention that although FEC is commonly associated with an address prefix,
this is not a requirement. In fact using CR-LDP FEC element you could
arbitrarily assign anything you want to an FEC.

>what do I put in the DSCP field of the IP packet?

This is basically the same problem, which limits the use of PHP in Uniform
model. Some possible solutions:

1) Don't use PHP with uniform model
2) Configure the PHP router to know the EXP<=>PHB and/or DSCP<=>PHB mapping

>Copied from draft verbatim:

Section 2.3 explains that Policer (traffic conditioner) or any Local policy
may be used to determine the outgoing PHB from the incoming PHB. This is
shown as block "B" in the first diagram. Then the outgoing PHB is encoded in
the packet using one of the procedures described above in section 3.5 or
4.5.

I hope that helps. We have done some additions and corrections which
probably will better answer your questions. We are trying to release the new
version ASAP.

Regards,

-Shahram