The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] New Internet Draft on ERO
My question is as follows: How do you do fast reroute when you have unnumbered interfaces in the ERO as in the unnumbered draft? What out of band information is added to what's in the ERO when we do CSPF? Is everyone doing it the same way? If we use the (newly defined) EERO then fast reroute is the same for both numbered and unnumbered interfaces and it actually becomes quite easy. Bora At 2:00 PM -0800 2/26/01, Jonathan Lang wrote: >Bora, > Please explain how the current ERO and unnumbered interfaces are affected >by fast reroute. > >Thanks, >Jonathan > > >> -----Original Message----- >> From: Bora Akyol [mailto:akyol@pluris.com] >> Sent: Monday, February 26, 2001 10:48 AM >> To: Bora Akyol >> Cc: Kireeti Kompella; mpls@UU.NET >> Subject: Re: New Internet Draft on ERO >> >> >> Also, how do you do fast reroute with unnumbered interfaces when >> there is no router ID associated with an ifindex? >> >> Thanks >> >> Bora >> >> At 8:45 AM -0800 2/26/01, Bora Akyol wrote: >> >Kireeti >> > >> >Thank you for your comments. The fact that you suggested that a draft >> >without defining a new object but explicitly defining >> behaviors on ERO >> >generation and processing leads me to believe that you recognize the >> >problem that we are trying to address. I still think a new object is >> >necessary however. Please see my comments within: >> > >> > >> > On Mon, 26 Feb 2001, Kireeti Kompella wrote: >> > >> >> Hi Bora, >> >> >> >> I have some comments on your draft. >> >> >> >> Section 1: >> >> >> >> Specifically, ERO >> >> definition for unnumbered interfaces is >> context sensitive and >> >> dependent on the order of appearance in the ERO. >> >> >> >> Note that the graph-theoretic definition of a path is an *ordered* >> >> sequence of edges (or nodes). What issue does the fact >> that the ERO >> >> needs to be ordered raise? Do you suppose that the EERO >> format that >> >> you propose does not dependent on the order of appearance? >> >> >> > >> >It does depend on the order of appearance but we clearly >> wanted to make >> >the case you listed below impossible: >> > >> >> For example, if >> >> the same interface identifier is repeated >> twice in the ERO >> >> consecutively, the desired behavior is unclear. >> >> >> >> Actually, the desired behaviour is quite clear; if an ERO >> consists of >> >> <1, 1, 1, 1, 1, 1>, then the path is quite explicit: take >> interface #1 >> >> from the ingress; then take interface #1 from the next >> hop; then take >> >> interface #1 from the next hop, etc. until you reach the >> egress. The >> >> fact that all the interfaces are numbered 1 is wholly >> irrelevant; each >> >> hop is in a different numbering scope. (Note that >> unnumbered interfaces >> >> are always *strict* hops.) >> >> >> > >> >What you are assuming here is that there is one ERO hop for each hop, >> >however, the RSVP-TE draft allows a hop to be specified by >> any combination >> >of interface identifiers and router ID. I recognize the >> point that you are >> >making but I think that it is advantageous to make things as >> clear as they >> >can be. The EERO that we define achieves this clarity. > > > > > > > c. Different styles of specifying the ERO in different > > >> implementations. [RSVP-TE] gives the head-end > > LSR considerable > > >> leeway in specifying the ERO. For example, an >> LSR that is on the >> >> path can be specified by a router ID, an >> ingress (w.r.t. to the >> >> LSP) interface ID (usually an IP address), an >> egress interface ID >> >> or any combination of the above. This >> "flexibility" may cause LSP >> >> establishment and interoperability failures. >> >> >> >> These "issues" are easily solved (and are solved in >> practice). A BCP >> >> that describes one style for ERO specification *without* protocol > > >> changes would be a better solution (IMHO) than an entirely new ERO >> > > format that contains twice redundant information. >> > > >> > >> >I know that these issues are solved in practice, I know that our >> >implementation solves these issues as well. One of my main >> motivations for >> >this draft was to stop other implementors from making different >> >assumptions and achieve maximal interoperability. We are still in the >> >earlier stages of deployment for MPLS and as more and more >> edge devices >> >come on-line, we will see more interoperability problems. >> The EERO object >> >that we defined prevents interoperability problems since it >> is very strict >> >in its definition. >> > >> > >> >> Section 2: Ingress Interface Identifier & Egress >> Interface Identifier > >> >> For a given link, the ingress and egress interface >> indices are assigned >> >> by different routers. This means that the scopes are >> under different >> >> router IDs. The draft contradicts that. Can you clarify? >> > >> >Kireeti, what we meant here is: >> > >> >The ingress and the egress interfaces through the same >> router. Think of >> >threading a needle where the router is the needle. You come >> in through >> >interface A and leave through interface B and both A & B >> belong to the >> >same router. >> > >> > >> >> > By the way, the idea of adding a router ID to >> unnumbered interface >> >> objects was discussed on the MPLS mailing list several >> months ago and >> >> discarded as unnecessary. >> > >> >I know, I was part of the discussion, but I don't recall >> anyone objecting >> >to a new EERO at the time ;-) >> > >> >> >> >> In any case, what is the value of the router ID when the >> ingress/egress >> >> interface identifiers are IPv4 addresses? >> > >> >As stated in the draft, it makes EERO processing very very >> simple. There >> >are no abstract node lookups, you just see if you are the >> router with the >> >router ID and then associate with the UP/DOWN-stream >> interfaces and the >> >LSP setup is on its way. The fact that you don't need to do >> a AN lookup by >> >itself probably saves about 1/3 to 2/3 of LSP PATH >> processing in the node. >> > >> > >> >> > Also, loose hops should probably not have any >> associated interfaces. >> >> I'm not sure what it means to have unnumbered interface >> indices with >> >> loose hops. Unfortunately, I cannot make out the use of >> interface IDs >> >> in the context of loose hops from the description in section 3. >> > >> >Why? You can perfectly specify a loose hop where you want the LSP to >> >specifically enter through interface A and leave the hop >> through interface >> >B. I can see benefits of this in a regular MPLS network as well as an >> >optical network. >> > >> >> >> >> Section 3: ERO processing >> >> >> >> There are actually eight cases: with/without EERO-HOPs, >> with/without >> >> AN-HOPs, with/without LR-HOPs. I fail to see how this >> classification >> >> helps, though. You seem to assume that LR-HOPs cannot be >> interspersed >> >> with EERO-HOPs, and that EERO-HOPs must be present. Is >> that what you >> >> meant? >> >> >> > >> >The cases that were stated were examples, it is perfectly >> legal to have >> >only LR-HOPs or AN-HOPs by themselves and add or delete HOPs >> in the middle >> >of an LSP. >> > >> >We will refine this section in the next version of the draft. >> > >> >> IMO the stated goal of "simplification of abstract node >> and loose route >> >> processing" has not been achieved. It may well be that >> ERO processing >> >> should be reworded; if so, the goal should not be to use >> fewer words, >> >> but rather to achieve greater clarity. Of course, the >> current semantics >> >> should be maintained. >> > >> >Kireeti, >> > >> >I think you have seen the problem that we are trying to >> address but do not >> >believe that a new ERO (EERO) is necessary. On the other >> hand, the fact >> >that we have cut the AN lookup out of most EERO processing, >> that we have >> >made >> >the EERO very specific and detailed have achieved our goal. >> If these were >> >in the ERO in the first place, I am sure that at least our >> implementation >> >would have been shorter. > > > >> >We believe that this draft is useful and adds value to existing MPLS >> >implementations and reduces the chance having un-interoperable MPLS >> >implementations. I know of interoperability problems even between two >> >leading vendors' implementations that have brought networks >> down for days, >> >and we are trying to prevent that when there are (say) six vendors' >> >equipment in the network. >> > >> >We appreciate your comments and will incorporate these into the next >> >version of our draft. >> > >> >Regards >> > >> >Bora >>
|
|