Subject: comments on "MPLS Support of Differentiated Services" draft

From: "Chiu, Angela L, ALSVC" <[email-masked]>
Date: Wed, 24 Nov 1999 15:59:44 -0500

Francois,

Here are some comments on your draft "MPLS Support of Differentiated
Services". I am copying them to the list in case other authors and folks
want to comment on them.

It's really nice to see that in the last revision, per-OA TE/restoration has
been added as one of the applications of E-LSP, with some new text and the
example illustrated in scenario 5. With this addition, I see more
consistency changes may be needed in the main text body. Here are some
examples.

1) I like the way you used in defining E-LSP at your last IETF MPLS working
group presentation using <FEC, set of OAs>, where the set can be one OA (for
per-OA TE/restoration), a subset of OAs ( for per-OA-group TE/restoration),
or the whole set (for aggregate TE/restoration). Is it possible to
incorporate this in the draft?

2) Since E-LSP can perform per-OA TE/restoration, I don't think the
requirement of per-OA TE is the main reason for having L-LSP (which is how
it is stated in 3.1. The main reason of having L-LSP is that for the PPP
case, 3-bit EXP field may not be enough, and for ATM&FR cases, there are no
EXP fields, all we have is L-LSP.

3) In scenario 5 where the example shows that E-LSP can be used to perform
per-OA TE/restoration, I saw that a filtering functionality has been added
as a last step to map traffic belongs  to <FEC, corresponding OA> on the
E-LSP. Since this filtering functionality is not unique to E-LSP, i.e., it
is needed for all the scenarios where L-LSP is used (e.g., scenarios 2, 4,
6), and for the E-LSP case whenever the set of OAs is not the whole set
(e.g., scenarios 2, 6), maybe it's necessary to put it as an explicit step
in those scenarios, which may have been implicitly implied.

One scalability advantage of E-LSP is that it is capable of performing
per-OA-group TE/restoration (if no per-OA admission control is needed),
which is not possible with L-LSP. This advantage is not clearly stated in
the draft. Maybe an example in the Appendix will be a good way to illustrate
it. For example, some ISPs may want to take advantage the fast restoration
capability in MPLS to enhance the availability of certain classes of
service, e.g., those designed for real time applications, for protecting
those links that often fail more than the others (e.g., those unprotected
OC48/OC-192 POS links). For example, one ISP may offer two classes for
supporting VoIP, one is the pipe-based VLL service using EF, and the other
is the hose-based premium real time service using AF1. Although IGPs have
their own rerouting to restore from failures, it may take a few seconds
before IGP routing calculation converges after a failure. During the a few
seconds delay, many packets may get dropped. Since MPLS fast protection such
as link/node protection can cut down the restoration time down to SONET
level, near 50ms range, one can enable link protection for those high-risk
links, and configure LSPs for all VLL and premium real time class traffic
that traverse those links with link protection turned on, i.e., one E-LSP
for each <FEC, EF+AF1> pair with link protection enabled. One can choose to
use path protection on top of link protection.

Please let me know your thoughts on these, and if you need any
clarifications. (I should have sent these to you a lot sooner. It's your
earlier email today which triggered me to finally put them done and hope
they are not too late for your next round of revision.)

Best regards,

Angela

AT&T Worldnet
Room C4-3A22
200 Laurel Ave.
Middletown, NJ 07748
Tel. (732) 420-2290
Fax (732) 368-1746
Email: [email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 25 Nov 1999 18:21:36 +0100

Angela,

>incorporate this in the draft?

Yes.
There was also a question earlier on the alias which suggested
clarification is required on what can go onto an E-LSP. 

>EXP fields, all we have is L-LSP.

Agreed. the bullet item on "requirement for fine grain TE" will be removed.

>in those scenarios, which may have been implicitly implied.

I think the question of describing LSP-head behavior (including
"filtering") is broader than the context of the scenarios. We have
described the forwarding behavior of an intermediate hop in the main body
of the document, but we haven't really covered the tunnel-head behavior
yet. We need to do more thinking on this (I do anyway). Perhaps we could
start from the "Diff-Serv Router Conceptual Model" and just point out the
difference when this router happens to be an MPLS edge router...
Suggestions welcome.

>the draft.

We should be able to cover this as part of the clarification mentioned
above on what can be transported over an E-LSP.
 
I'd rather avoid adding another scenario; I feel covering the most common
cases as with existing scenarios is probably sufficient.

Thanks for these suggestions

Francois

> Maybe an example in the Appendix will be a good way to illustrate
NOTE : New Mobile Number        +33 6 89 10 81 59
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Phone Office:   +33 4 92 96 75 64
Phone Home Office:      +33 4 92 94 00 78
Mobile :                +33 6 89 10 81 59
Vmail:                  +33 1 69 18 62 66
Fax:                    +33 4 92 96 79 08
Email:          [email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________