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

[raymond zhang <zhangr@info.net>]

Hi Bert,

Once again, thanks for forwarding the comments...

Hi Kurtis,

See comments in lines below please....


At 08:17 PM 3/10/2003 +0100, Wijnen, Bert (Bert) wrote:
> 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).
Your right, indeed.  We are in process of making these editorial and format 
changes in the next revision (-03).

> 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.
Good point...  We will make them more generic (such as SP1, SP2, etc) in 
the models.

> 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 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 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.
Right.  I realize we do need to reword here to make it clear.  But I guess 
you got what we are trying to do.

> 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).
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.

> 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.
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.

> 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.
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.

> 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.
Will define them.  Thanks.

> 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.
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.

> 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.

> 4.5
>
> Talks about the possibility of introducing additional routing
> complexities but does not detail them.
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.


> 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.
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.

> 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).
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 ?

> 8.
>
> Editors names and addresses here does not match those in the header.
Right.  I will correct them, thanks.

> ---
>
> 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.
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.

> I think the document, besides pure editorial nitpicks, needs a lot of
> more work.
Thank you very much once again for your comments.

Regards,
Raymond

> - kurtis -