I wasn't suggesting that the topology didn't support this setup, I was suggesting that the setup was unwise. With respect to TE, yes, you are correct that inter-area TE isn't available for ISIS or OSPF. However, this has nothing to do with your area-id's, but rather the flooding scope of the type 10 LSA (in the case of OSPF). Furthermore, drafts are in progress to address this limitation, but again, these are ospf area-id agnostic.
various drafts of note wrt to inter-area TE http://search.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt http://search.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-pcsd-discovery-00.txt http://search.ietf.org/internet-drafts/draft-vasseur-mpls-isis-pcsd-discovery-01.txt At 01:43 AM 8/12/2002 +0000, you wrote: >Hi Peter, > >Thanks for the response. Yes, the assumption is that each ABR >terminates >a single sub-area. The topology supports this assumption. > >In a response I was preparing for Chuck's comment, there is one other >item I should add-- future service needs might result in the need >for TE. I believe the current OSPF specs only supports carrying TE >information >within an area. Given how OSPF works today, I'd expect that TE would >also work, across areas, without the need to carry the actual area ID >information. But I'm guessing.... > >Thanks > > > >Peter van Oene wrote: > > > > Having all sub-areas use the same area-id is functionally possible, but > > imposes some key limitations. First off, you can only have ABRs that > > terminate 1 sub-area as they have no mechanism for differentiating more > > than one. If one were to connect multiple, similarly identified yet > > separate areas to the ABR, you would end up with one area thereby defeating > > your original goal. This is about the only key limitation I can think of > > off hand, but is highly restrictive and certainly overcomes any desire to > > optimize config script tools. > > > > pete > > > > At 06:12 PM 8/11/2002 m??, bergenpeak wrote: > > >Ran across some text in Doyle's V1 that confirms JMcL's comment > > >below (page 462, Partioned Areas section). > > > > > >So, the next question for the group is the following: > > > > > >OSPF doesn't track the area information once the routing information > > >gets injected into the backbone. Suppose you have a network with N > > >different physical locations and each will be configured as sub-area. > > >Each sub-area connects to the backbone via it's own ABR. > > > > > >Is there any reason to use different area numbers in this situation? > > > > > > >From an Ops perspective (say where you have tools to go out and touch > > >the configs on the ABR and sub-area routers), using the same area number > > >will simplify the configs and tool logic. > > > > > >So, is there some benefit to actually use different sub-area IDs? > > > > > >Thanks > > > > > > > > > > > > > > > > > > > bergenpeak wrote: > > > > > > > > > > Suppose I have two ABRs that are supporting the same sub-area. > > > > > The ABRs are not directly connected, but can reach each other > > > > > through links inside the sub-area. > > > > > > > > > > Suppose a link fails causing the two ABRs to not have > > > > > connectivity > > > > > through the sub-area. The sub-area is therefore partitioned. > > > > > > > > > > Suppose the ABRs are not doing route summarization. > > > > > > > > > > Will this cause a problem from the backbone perspective? > > > > > > > > > > Will this cause a problem for traffic which needs to flow from > > > > > one side of the sub-area to the other part of the sub-area? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > I don't believe it will cause any problems. I'm not going to look it >up > > > > right now, but I'm sure I've researched this one before. As long as > > there > > > > is no summarisation (or no overlapping summarisation), the two >partitions > > > > are simply treated as two sub-areas. > > > > > > > > JMcL Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51214&t=51214 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
