FW: draft-zhang-mpls-interas-te-req-01.txt

Some comments from a member of the OPS directorate.
Forwarding with permission. Pls note that Kurtis is
not on your mailing list, so if you want him to see
any responses, then you better copy him.

Thanks,
Bert 

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:[email protected]]
Sent: zondag 9 maart 2003 18:31
To: ops directorate
Subject: Re: draft-zhang-mpls-interas-te-req-01.txt

>
> Can you ask them of draft-zhang-mpls-interas-te-req-01.txt
> seems usefull work. The TEWG chairs claim that quite a few
> operators think it is timely to do this (requirements) now.
>
This is pretty late...and I am no expert on MPLS and my  gut feeling is 
to deny anything MPLS related...:) But here are some comments :

First comment is to have them fix the format (page number and header?) 
and get rid of strange characters. Also grouping the chapters in a more 
standardized way makes it more readable.  They are missing the RFC2119 
references (if needed, I forgot).

3.1

GSP and RSP seems to me as a strange differentiation. In the real world 
these classes do not work and have no relationship with the technology. 
This should be made more generic.

3.2

I am not following that " - Establishing a scalable exterior routing 
plane separating from
    data forwarding plane within SP's administrative domain" is one of 
two reasons for deploying BGP in a service provider network. Then again 
I am not sure I even understand the sentence as such (probably my poor 
english).

I generally think that their reasoning for a need for MPLS based 
inter-AS TE is just nonsense and political statements to a already 
converted audience but I guess that is not part of the review :)

Specifically, claiming that you need inter-AS TE to get around the 
problem with non-deterministic traffic flows inter-provider due to 
non-aligned IGP routing policies or other differences in agreeing on 
common policy, doesn't make much sense to me. You will have the same 
risks with inter-AS TE, it's just a different parameter set you need to 
agree on.

This said, I can see what they are trying to achieve, but I think they 
are wording it poorly in the text, so I would suggest have them do some 
more work on the text here. Specifically from a MPLS enabled network 
view, instead of from a BGP enabled network view.

They also claims that inter-AS traffic toady have succeeded only on a 
best-effort basis. I would like to claim that inter-AS TE will also 
only survive on a best-effort basis unless it's backed up by a 
commercial agreement. So this is not TE or MPLS specific.

Claiming that if a certain set of QoS is needed, MPLS TE is need in 
order to avid use of ample bandwidth to me is wrong. Both are two types 
of achieving the same goal (personally I would think that only ample 
bandwidth achieves the goal, but that is another debate).

I think this chapter is close to some sort of "why MPLS TE" 
argumentation, rather than describing a problem statement of two MPLS 
enables networks that needs inter-AS TE. I would personally like to see 
it rewritten.

There is not with a single word described any risks, alternatives or 
problems. I can see a number of complexity problems, as well as 
problems with ISP agreeing on how traffic and priority is split between 
different customers. For example if each provider have two VPN 
customers with sites in each-others networks, if inter-AS links get 
congested, which of the two customers should be throttled? Etc, I think 
this is more a political than a engineering problem.

4.0

CE and PE are not defined or referenced in the document, while other 
definitions show up in the text and not in the terminology chapter.

VRF is not defined in the document.


4.1

In the VPOP scenario, there are a number of assumptions made that are 
most likely harder to meet that then engineering challenges of creating 
a inter-AS MPLS TE specification. Bounding delay and creating a common 
DiffServ codepoint understanding is harder than the engineering parts.

The "Scenario IV - TE across multi-AS within SP's Administrative 
Domain" does not seem to list any requirement on a solution at all. At 
least nothing that is different from a number of other scenarios. It 
also make assumptions on the underlaying transport networks of a ISP 
that is not described (this is true for most cases).

4.5

Talks about the possibility of introducing additional routing 
complexities but does not detail them.


5.6

Uses should, but I assume means SHOULD. In general, no RFC2119 
terminology is used in the requirements section which is odd. This 
chapter also discussed MPLS FRR as a requirement for inter-AS TE. I 
think this is not really a good idea, as that is hard to deploy for 
traffic in both ways. See my example of the two VPN customers above.

5.7

Enabling ISIS-TE and OSPF-TE with automatic ASBR selection worries me a 
bit. This also means that if a ASBR is no longer available this needs 
to be propagated to all IGP speaking routers, and in worst case have 
them reconverge. Even worse is that this needs to be done on a per-peer 
basis. This means that at a IX this opens for a DoS attack (at least 
most likely).

8.

Editors names and addresses here does not match those in the header.

---

Generally this document seems to list and describe a number of 
scenarios in a MPLS enabled service provider network. However it does 
not very clearly state what the requirements from each of the scenarios 
are in a inter MPLS TE environment.

I think the document, besides pure editorial nitpicks, needs a lot of 
more work.

- kurtis -