The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

Hi Louis,

For your information, 
-
http://www.ietf.org/internet-drafts/draft-venkatachalam-ospf-traffic-02.txt
-
http://www.ietf.org/internet-drafts/draft-dharanikota-interarea-te-ext-02.txt

were submitted for the last IETF meeting (SLC). 

Regards,
- dimitri.

Louis Yun wrote:
> 
> Cheng-hong,
> 
> You can think of the Opaque LSA used for traffic engineering as a natural
> extension of the regular OSPF router-LSA.  Just like router-LSAs, then,
> OSPF-TE LSAs have area-only scope for scalability reasons.  In fact,
> scalability is an even more critical issue for traffic engineering
> applications, since any change in link bandwidth or other attributes -- not
> only the link going up or down -- will cause the LSA to be reflooded.
> 
> One may attempt breaking down the problem of inter-area path calculation
> into per area computations, but it's not so simple.  Suppose the Ingress of
> a TE tunnel is in a different area then the Egress, and you are trying to
> compute a CSPF route.  There may be multiple exit ABRs within the Ingress
> area.  There's no way to know beforehand whether a particular exit ABR leads
> to the best path, or will even satisfy the path constraints in the
> subsequent areas.  The result -- you may have to check all exit ABRs,
> raising questions as to how well these computations would scale.
> draft-kompella-mpls-multiarea-te-01.txt gives a good discussion about this.
> In essence, there's a tradeoff between protocol scalability and optimality
> of the computed TE path for a tunnel.
> 
> What is needed is an extension of the OSPF summary LSA for inter-area TE
> advertisements.  Something like this has in fact been proposed; see
> draft-venkatachalam-ospf-traffic-00.txt,
> draft-dharanikota-interarea-te-ext-00.txt.
> 
> This does not completely solve the problem either.  For intra-area tunnels,
> LSP constraints are user-configured and thus only known to the Ingress LSR.
> For inter-area LSPs, the LSP constraints have to be signaled to the transit
> ABRs along the path, requiring extensions to RSVP-TE or CR-LDP.
> 
> regards,
> Louis
begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard