[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:kurtis@kurtis.pp.se]
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 -