[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: draft-zhang-mpls-interas-te-req-01.txt
Once again, thanks for forwarding the comments...
See comments in lines below please....
At 08:17 PM 3/10/2003 +0100, Wijnen, Bert (Bert) wrote:
Your right, indeed. We are in process of making these editorial and format
changes in the next revision (-03).
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.
From: Kurt Erik Lindqvist [mailto:firstname.lastname@example.org]
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).
Good point... We will make them more generic (such as SP1, SP2, etc) in
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.
I thought it was quite clear. It just means that with BGP one can scale up
to a large routing plane by carrying customer routes into BGP, instead of
IGP. IGP maintains the topology and forwarding plane (NH of the customer
prefixes) of the network.
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
Right. I realize we do need to reword here to make it clear. But I guess
you got what we are trying to do.
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
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.
Maybe our texts were not quite clear on that. What' we wanted to convey is
simply that in some cases for areas where we don't have ample bandwidth in
both networks (not just inter-AS links), we could then employ some other TE
methods such as MPLS TE to provide bw guarantees which also brings another
benefit - fast local repair.
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).
Ok... It is not our intention to favor any given technology at all. Just
initially we would like to work with something that has already good
deployment base and operations experiences. Others may certainly be
considered at a later stage as we learn more of those requirements.
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
Good point. we will structure something to address that. For the example
above tho, I don't think SPs would establish traffic engineered trunks (TE
tunnels) for one specific customer. Instead, the TE path is established
for aggregated traffic from customers that can be grouped into a particular
class of traffic (diffserv class). So the traffic can the be managed by
class at each PHB based upon its priority and allocation. Preemption may
also be configured to resolve TE setup or holding conflicts.
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.
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.
Will define them. Thanks.
Indeed, determination of DSCP equivalency for PHB policy translation or
matching is one of the interconnect issues we have dealt with over the past
year. But in this draft, we only deal with Inter-AS TE issues.
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).
Good point. we will explicitly describe in this and other scenarios. Thanks.
Surely. We can certainly summarize some of key issues here. But since
this draft is about inter-AS TE, we may not go into too much details of this.
Talks about the possibility of introducing additional routing
complexities but does not detail them.
I thought I did: "In the event of inter-AS link failure, rapid local
protection SHOULD ..." Also ourselves and other SPs we've talked to all
require FRR which is one of the key component of this requirements draft.
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.
Generally, IGP plane is relatively small and its convergence is relatively
fast since it is confined within an AS boundary. That's at least the case
for folks we've been talking to. As for issue of DoS attack, I wonder how
it is different from what we have currently deployed now ?
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
Editors names and addresses here does not match those in the header.
Right. I will correct them, thanks.
The original intent is to describe the underlying requirements in section 5
so as not to crowd the presentations of the applicable scenarios since they
share almost comment set of requirements. But we could indeed word
something into these sections to make it flow a bit better. Thanks for
pointing this out.
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
Thank you very much once again for your comments.
- kurtis -