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

Hi Kurtis,

Thanks very much for your input....

<<<snip>>>


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