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

From: raymond zhang <[email-masked]>
Date: Thu, 13 Mar 2003 15:42:05 -0800

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:[email-masked]]
>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 -

---

From: raymond zhang <[email-masked]>
Date: Mon, 17 Mar 2003 14:21:42 -0800

Hi Kurtis,

Thanks very much for your input....

<<<snip>>>

>>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.
>
>You still have the same problem if you have TE paths from both ISPs on the 
>same links. In the case of congestion, which ISPs TE backs down?

Right, I got your point here, now.  Although section 5.12 in -02 addresses 
requirements for some policy control such as "- Bandwidth control to ensure 
LSPs don't ask for BW over their allocation ".  But this pertains to the 
signaling plane only.  Once TE LSPs are established, I am not sure if there 
is any mechanism toady to throttle down the traffic along the TE paths 
(except congestion indications provided by packet drops (Tail, random, 
etc.) or longer delay/jitter (RTCP for certain type of media traffic)) if 
the load offered onto the TE path exceeds what's requested  and causes 
congestion.  Obviously, the differseve PHB installed along the path will 
manage congestions based upon allocation and priorities of each class on 
the data forwarding plane.

We did give some thoughts on the issue of similar category and added 5.10 
in the -02 version of req's draft dealing with the re-optimization inside 
transiting ASes including inter-AS links.  But even if both TE tunnels have 
the same setup/holding priorities, it is still possible that one of the TE 
paths may fail to rebuild due to lack of resources in the event of 
link/srlg/node failures.

But to a large degree, this may have something to do with capacity planning 
and SLA issues, in which case, this may be beyond what this draft can 
address.  For example, upon negotiating SLAs including capacity assurance 
on the interconnect agreements with inter-as TE requirements, one should 
ensure that adequate capacity is provided for the primary and backup (if so 
required) path (altho path information may be hidden for confidentiality 
reasons) based upon SLA requirements.

In one of your comments in the other email, you suggested "to look at is 
what parameters you would want in order for a agreement like this to work. 
In other words, maybe you need other monitoring parameters, other signaling 
etc.".  We will indeed give some more thoughts on this point.

Regards,
Raymond