The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] RE: RSVP Labels , RReflector
Spice "However, I do rememeber reading on another mailing list that someone once said that "the only way a node can make a decision on behalf of another node is if it was to make the same decisions locally". So as long as that condition is met, it really is not an issue where the RR is , but ofcourse, practically the RR is better placed in the forwarding path. [unless my imagination is letting me down :)" Vey valid point but the RR principle do not follow this idea , in VPN this could be mitigated by assigning distinct RD for each VRF (ie: avoiding the RR to do any best-selection for the same routes). In almost all implementation as i indicated earlier , RR is not at all in the forwarding path as their is no need for this . "However, RR or no RR, do you not think that if one could simply view the topology/graphs as a set of vertices, and one was to take the Bellman-Ford analogy, then in that case, the next-hop would be the RR? A simple analogy is a intermediate router in RIP." If one node reflecting reachability info (advertised by some other node) so nothing to mandate that it should be in the forward path . The case is differenet for intermediate router in RIP , in RIP : The node adverise "You Could reach AAA through me" . For RR : "You could reach AAA through BBB " where BBB is another node . their is no "next-hop" field in RIP so it is always/implicit "me". "again, if one was too look at what the RR actually helps "achieve", is it not simply a device which is telling us how to reach a particular VRF (be it RD or RT which is used to distribute the route). Since we still prefer a seperate "signalling protocol" and are still welcome to use the LSP to carry the actual NLRIs connected to at each edge-node, the RR would suffice if it was in the forwarding path and carried only sufficient information to setup the LSP." The signalling protocol is the i-BGP ,the RR help to scale the implem of this signalling protocol . so RR is simply a device which facilitate/scale the process of telling us (the nodes) how to reach a particular VRF . Possibly the RR could act as Route mirroring ie: no best-path selection just mirroring what it recieve , i guess that their was a draft (can not recall the name) which will allow the RR to send several path for the same route . have no idea what is the current status for this draft . If such draft is implemented one day so the point U raised as : "the only way a node can make a decision on behalf of another node is if it was to make the same decisions locally" The above will be staisfied as the RR will not intervene in the decision (the best-path decision) leaving such decision to the nodes . Brgds Brgds >From: Spice Sylvia <falsesylvia@yahoo.co.uk> >To: "M. ELK" <elkou141061@hotmail.com>, mpls-ops@mplsrc.com >Subject: RE: [MPLS-OPS]: RSVP Labels , RReflector >Date: Wed, 17 Mar 2004 07:34:42 +0000 (GMT) > >I am not sure I am following you here, so I will put down my understanding >of the matter. > >I do agree that RR does not change the next-hop as per draft > >However, I do rememeber reading on another mailing list that someone once >said that "the only way a node can make a decision on behalf of another >node is if it was to make the same decisions locally". So as long as that >condition is met, it really is not an issue where the RR is , but ofcourse, >practically the RR is better placed in the forwarding path. [unless my >imagination is letting me down :)] > >However, RR or no RR, do you not think that if one could simply view the >topology/graphs as a set of vertices, and one was to take the Bellman-Ford >analogy, then in that case, the next-hop would be the RR? A simple analogy >is a intermediate router in RIP. > >again, if one was too look at what the RR actually helps "achieve", is it >not simply a device which is telling us how to reach a particular VRF (be >it RD or RT which is used to distribute the route). Since we still prefer a >seperate "signalling protocol" and are still welcome to use the LSP to >carry the actual NLRIs connected to at each edge-node, the RR would >suffice if it was in the forwarding path and carried only sufficient >information to setup the LSP. > >Ofcourse, this makes me think of another question as to why would one need >a "Label-stack", as one label could suffice. > > > >"M. ELK" <elkou141061@hotmail.com> wrote: > >Hi Spice > >reg : > >"RRs do not simply "avoid the full mesh but they also form a component in >the forwarding plane (Route servers would suffice if one was to avoid the >full mesh)." > >As fast as i understand : >The RR do not change the next-hop (i-BGP) so it is not a component in the >forwarding plane >(unless the topology itself and the selction of the node where RR is >running >dicdate/mandate that the RR will be in the forwarding path ) . > >The normal case deployement : RR is running on sperate dedicated box and >not at all in the forwarding path. > >For Inter-as option "C" where it exist e-BGP between the RR of each AS . >The >RR will be >in the forward path (the net-hop is for the RR as it is e-BGP ) still it >exist an option in CSCO to not alter the next-hop ( BGP Next Hop >Ptopagation >, neighbor next-hop-unchanged ) so the RR will not be in the forwarding >path even in this case . > >Brgds > >From: Spice Sylvia > >To: shailendra gupta , > >Devendra.Vyas@relianceinfo.com, mpls-ops@mplsrc.com > >Subject: RE: [MPLS-OPS]: RSVP Labels , RReflector > >Date: Mon, 15 Mar 2004 18:26:22 +0000 (GMT) > > > >RR C will carry the best routes out of those obtained from A&B in the > >forwarding table. > > > >RRs do not simply "avoid the full mesh but they also form a component in > >the forwarding plane (Route servers would suffice if one was to avoid the > >full mesh). > > > >As far as MPLS goes, it seems logical that only "flow mappings" (or Label > >mappings) for flows/LSPs for it's clients need be present in the RR. > > > >I also assume that you are not looking at "TE" as a very active >requirement > >for your network. > > > >shailendra gupta wrote: > > > >Dear Devendra > > > >Reg yr query on Route-Reflector, the RS will have all routes advertised >by > >RCs.. The Route-Reflector solves the iBGP Full Mesh requirement, however >it > >also carries all the routes advertised by Route Reflector Clients >(assuming > >there is no Route Advertisement Restriction/Filtering, imposed through > >Policy Map, pointing to RS). > > > >Hope this help. > > > >Shail > > > > > > > > > > > > > > > > > > > > > > > > > > >From: Devendra.Vyas@relianceinfo.com > > >To: mpls-ops@mplsrc.com > > >Subject: [MPLS-OPS]: RSVP Labels , RReflector > > >Date: Sun, 14 Mar 2004 19:40:00 +0530 > > > > > > > > > > > > > > > > > > > > >im referring to Juniper . > > > > > >suppose i want to trace a RSVP LSP..which commands can help me to see >the > > >labels associated with the LSP. > > > > > > > > >secondly, > > > > > >i have a doubt about rreflector....does the RR carry all the routes or >it > > >simply acts as a common peering point. > > > > > >eg.if A is an RRserver ...and C & B are it's clients is it necessary >that > > >all routes that are there in all the tables of C& B will be there in A. > > > > > >Thanks & Regards, > > > > > >Devendra Vyas > > > > > >------- > > >The MPLS-OPS Mailing List > > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > > > >--------------------------------- > >Contact brides & grooms FREE! Only on www.shaadi.com. Register now! >------- > >The MPLS-OPS Mailing List Subscribe/Unsubscribe: > >http://www.mplsrc.com/mplsops.shtml Archive: > >http://www.mplsrc.com/mpls-ops_archive.shtml > > > >--------------------------------- > >Too much spam in your inbox? Yahoo! Mail gives you the best spam >protection > >for FREE! Get Yahoo!Mail > >_________________________________________________________________ >Tired of spam? Get advanced junk mail protection with MSN 8. >http://join.msn.com/?page=features/junkmail > > >--------------------------------- >Too much spam in your inbox? Yahoo! Mail gives you the best spam protection >for FREE! Get Yahoo!Mail _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|