Re: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Tony Li <[email protected]> Thu, 27 May 2004 12:44:00 -0700
| Newsgroups | gmane.ietf.tewg,gmane.ietf.ccamp |
|---|---|
| Message-ID | <[email protected]> |
>> As an example, I would like to be able to leak detailed topology >> information from >> my IS-IS L2 database down into an L1 area. I would NOT want to leak >> bandwidth >> information. > > I don't see the gain, as regards inter-area TE, > in leaking detailed topology information from L2 into L1 without > leaking any bandwidth information... > The gain is that the bandwidth information is in continual flux, and leaking that just sloshes L1. Plus, by the time signaling gets there, the information will likely be out of date. Combine this with the fact that the primary reason to use this information is to ensure an optimal exit from the L1 area, and there doesn't seem like a real need to worry about instantaneous capacity. Again, what I'm suggesting is just an example of one overhead vs. optimality tradeoff. >> I would want to leak an abstraction of another L1 area >> down into an >> L1 area, but I would definitely want that to be an >> abstraction, NOT the >> full >> database. > > Of course, else you come back to a single area network ! > But IMHO such abstraction, to be useful, i.e. to allow computing an > inter-area TE path, > would require to take into account a large set of constraint > combinations, > and this would likely lead to major impact on IGP scalability. > You're making the assumption that the head end of the LSP is computing the entire path. Again, I'm advocating a somewhat different position (ala Nimrod): the path is computed with more refinement as you get closer to the destination. The head end might be able to provide an explicit path through the originating L1 area, and based on its L2 topology information, it might select the exit point from that area. However, the L2 router would be responsible for computing the remainder of the path, and the L2 router would have current information about L2 and some topology information about the destination L1 area. It might compute a path that transits L2 optimally and also selects the L2 exit router. The L2 exit then computes an optimal transit of the L1 destination. By chaining together 3 locally optimal paths, we will NOT achieve global optimality, but we will get a good first approximation for a fraction of the cost. > Not so sure, there are schemes that allow computing an optimal > inter-area path without adding any byte in LSA/LSP... > Which would take us back down the crankback path. No thank you. >> Tony