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

---

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

---

From: "dave o'leary" <[email-masked]>
Date: Thu, 01 Jun 2000 19:10:35 -0700

At 03:12 PM 6/1/00 -0700, Shahram Davari wrote:
> >> No. An E-LSP is associated with one FEC. That FEC may include
> >> one or more prefixes (see section 3.1).
>

Any particular reason that you have qualified this by indicating CR-LDP
specifically?  I can't think of any reason that an implementation using
RSVP to signal LSP establishment couldn't also use a variety of
criteria (including but definitely not limited to a destination prefix) for
mapping traffic into a given FEC and in turn onto an LSP.

Thanks,
                                                 dave

---

From: Shahram Davari <[email-masked]>
Date: Fri, 2 Jun 2000 07:21:43 -0700

Dave,

CR-LDP FEC element was just an example. Same capability exist in RSVP too.

Regards,
-Shahram

>From: dave o'leary [mailto:[email-masked]]
>Sent: Thursday, June 01, 2000 10:11 PM
>To: Shahram Davari; [email-masked]

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Mon, 5 Jun 2000 15:39:48 -0700

I agree that it would be actually very helpful. I would like to build
topology-driven LSPs and use EXP-PHBs stuff for differentiating CoS-like
traffic.
I do not understand the "hardware cost friendly" problem. The real issue
here is to have a flexible LSPs management/control plane (I do not
understand where the signalling problem is in all this) that would allow me
to do it in a simple, and semantically congruous manner.
It should not be that hard, at least at the provisioning level, and I guess
I saw it already but I do not recall now which vendor was it :-).

Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:[email-masked] 
> --------------------------------------------------------------------
> 
> 
> From:	Curtis Villamizar [SMTP:[email-masked]]
> Sent:	Monday, June 05, 2000 3:20 PM
> To:	tom worster
> Cc:	'Bora Akyol'; [email-masked]
> Subject:	Re: MPLS Diffserv Extensions related questions/comments 
> 
> 
> In message <[email-masked]>, "tom
> worster"
>  writes:
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Bora
> Akyol
> > > 
> > speaking of hardware... the requirement in diff-ext-04 for 
> > support of exp->phb mappings on a per lsp basis set by 
> > signalling does not really seem to be "hardware cost
> > friendly," so to speak. does anyone really need an arbitrary
> > mapping for each lsp?
> > 
> > c u
> > tom
> 
> 
> IMHO this will be useful.
> 
> It isn't really that hard.  Implementations exist.  (At least one that
> I know of).
> 
> Curtis

---

From: Shahram Davari <[email-masked]>
Date: Tue, 6 Jun 2000 08:53:57 -0700

Hi,

>From: tom worster [mailto:[email-masked]]
>Sent: Tuesday, June 06, 2000 11:05 AM
>To: [email-masked]
>Cc: 'CATANZARITI Sergio FTR&D/TI'; [email-masked]
>From: Curtis Villamizar [mailto:[email-masked]]
>> 
>> In message 
>> <[email-masked]>, "tom wors
>> ter" writes:
>> > 
>> > > I do not understand the "hardware cost friendly"
>> > > problem.
>> > 
>> > the cost i'm referring to is that a system needs to
>> > provide memory to store an exp -> phb mapping for
>> > every lsp. in a fast implementation that may come
>> > at a noticeable marginal hw memory cost.
>> 
>> If the network provider is reasonably sane, then you will probalby
>> need to map a medium to large number of LSPs into a small number of
>> EXP to PHB mappings.
>
>that's what i imagined too. which is why i question the
>design of a protocol that provides unnecessary resolution
>with a non-trivial cost attached to that resolution.
>

In the diff-ext draft, the EXP->PHB signaling is optional. If an operator
does not want to use more than 8 PHBs in his network, and wants to use
E-LSP, then the pre-configured EXP->PHB mapping can be used.

>
>> OTOH .. at least a few people built full mesh IGPs on ATM overlays so
>> assumptions of ISP sanity don't hold up universally.  :-(
>
>if the requirement for a different exp -> phb mapping for 
>each of a medium to large number of lsps is considered
>unreasonable then that should be taken into consideration
>in the diff-ext protocol design.
>
>i thought about a separation of ds semantics from mpls
>signalling using an "exp -> phb mapping index" which would
>be signalled in the new tlv instead of the mapping itself.
>a set of mappings would be configured and referred to in 
>the by the index in the signalling messages.
>
>the technical benefits i see are reduced signalling 
>bandwidth and processing and a reduced per lsp memory
>budget.

Signaling will be reduced a bit (but signaling BW is not an issue in MPLS),
but it creates another problem, which is that you need to configure your
EXP->PHB mappings (which are now more than 8) in each router. Remember, the
purpose of signaling was to eliminate the EXP->PHB configuration.

Regarding the reduction of per-LSP memory; well it all depends on what you
are comparing it to. One solution which will reduce the per-LSP memory and
still uses the signaled EXP->PHB mapping is to build a few general purpose
EXP->PHB mapping tables (in each LSR), from the first few LSP setup
messages, and use them as an index in per-LSP ILM/NHLFE tables.  Using this
method, the amount of per-LSP memory is less than  or equal to your
proposal.

>
>but there are other advantages. the diff-ext draft could
>be radically simplified since the distinction of e-lsp
>and l-lsp disappears -- they are just different classes
>of mappings. conceivable, the mappings could go into
>experimental rfcs and a range of indexes could be reserved
>for standardisation. such a separation of mpls signalling
>and (perhaps more controversial) ds-related semantics could 
>be expeditious.
>

Diff-ext-04 has been in circulation for quite a while. And we are releasing
diff-ext-05 by Thursday. Therefore I not only I don't think such a
seperation could be expeditious, but also that would delay the whole process
by months if not a year.

Regards,
Shahram

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Tue, 6 Jun 2000 11:12:54 -0700

>bandwidth and processing and a reduced per lsp memory

	Signaling will be reduced a bit (but signaling BW is not an issue in
MPLS),
	but it creates another problem, which is that you need to configure
your
	EXP->PHB mappings (which are now more than 8) in each router.
Remember, the
	purpose of signaling was to eliminate the EXP->PHB configuration.

	Yes, I meant that originally. Indeed, I was speaking as
configuration management duties as opposed to classical signalling tasks as
we know from the B-ISDN world. In this perspective, I guess that the power
of configuration flexibility  (optional) does not induce really a control
plane heavy weight.

	Sergio

> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Tuesday, June 06, 2000 8:54 AM
> To:	'tom worster'; [email-masked]

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Tue, 6 Jun 2000 11:30:28 -0700

i certainly see the utility of being able to control
	the exp -> phb mapping. i just don't see (yet) that
	every phb needs a unique mapping.

Well, let me as an operator to decide if I want to or not that unique
mapping. When the ITU-T X/Y will define IP Diff Class Service Classes (ala
ITU-T I.362) with a defined PHB <-> service semantics mapping function, then
we can reduce our universe of configuration choices. But, at that point I
will be either dead or retired in Sicily enjoying beaches and pure Olive Oil
:-). The latter choice appeals me better, indeed.

	yes. say you could establish several exp -> phb
	mappings in your lsrs and each is given an index
	unique within the domain. you could signal the
	index per lsp. would not that give you the
	flexibility you are looking for? how many such
	mappings would you need?

I am not questioning the normalization aspect of the mapping, it is that
really all depends on what we want to achieve and how to implement an
LSP-supported differentiated services offerings environment.

Sergio

> From:	tom worster [SMTP:[email-masked]]
> Sent:	Tuesday, June 06, 2000 5:52 AM
> To:	'CATANZARITI Sergio FTR&D/TI'; [email-masked]
> Cc:	[email-masked]
> From: [email-masked] [mailto:[email-masked]]On Behalf Of CATANZARITI
> Sergio FTR&D/TI
> >
> > I agree that it would be actually very helpful. I
> > would like to build topology-driven LSPs and use
> > EXP-PHBs stuff for differentiating CoS-like traffic.
> 
> i certainly see the utility of being able to control
> the exp -> phb mapping. i just don't see (yet) that
> every phb needs a unique mapping.
> 
> 
> > The real issue here is to have a flexible
> > LSPs management/control plane (I do not understand
> > where the signalling problem is in all this) that
> > would allow me to do it in a simple, and semantically
> > congruous manner.
> 
> yes. say you could establish several exp -> phb
> mappings in your lsrs and each is given an index
> unique within the domain. you could signal the
> index per lsp. would not that give you the
> flexibility you are looking for? how many such
> mappings would you need?
> 
> 
> > It should not be that hard, at least at the
> > provisioning level, and I guess I saw it already but
> > I do not recall now which vendor was it :-).
> 
> it's certainly doable. but it comes at a cost in
> some designs. in designs in which the memory for
> each lsp is reallocated, providing support for
> random signalled mappings comes at a cost.
> 
> c u
> tom

---

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Tue, 6 Jun 2000 15:27:47 -0700

>seperation could be expeditious, but also that would delay the whole
process

Yes, I do not think that E-LSP and L-LSP distinction is an issue of data
structures representation, but it is an enabler of diff serv configuration
flexibility power per LSP that looks valuable to me. So, I ignore the strong
reason why we should eliminate it.

Sergio