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).
---> Let us not talk about putting VRFs on RR or using RD, let us say "there are ways to avoid doing best selection". Why would one want to avoid doing best selection however, is something I do not comprehend. As long as the decision is accurate as far as the topology goes, it is fine. You can also look at things this way:
if you need an intermediate hop, it has to be in the forwarding path, if you do not need an intermediate hop, Route Servers suffice too. As far as RD goes, I think we have been there. Why would you like to create "multiple routes to the same system"? Why can you not play with things like metrics etc or use specific filters and mark on attributes/specific peer route-maps based advertisements or different values of RT? What is the purpose of making it a part of the NLRI?
In almost all implementation as i indicated earlier , RR is not at all in
the forwarding path as their is
no need for this .
----> Then I think we need to consider what was wrong in putting it in the forwarding path versus what can be wrong if it is not in the forwarding path.
And if it not in the forwarding path, for that property of "node decision making" to be satisified we could look at Route-Servers. However, the operator installing this node will have to manually configure all the "next-hops" mappings.
"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".
---> the above seems to be more consitent in most topologys. I seem to understand your point more as "why not use route-servers" and lets not worry at all about RRs. I also believe that this difference comes from the fact that there maybe more than one way of looking at D-V solutions.
"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 .
--> This bit is confusing me, in what way are you saying that the signalling protocol is iBGP? BGP can still not help me "signal" a particular "LSP". The way i see it, BGP is still used to find an "end point" or "attachement identifier discovery" protocol, unless you are fine with a pure DS-TE model.
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 .
--> I believe Route-Mirrors were called Route Servers. Route-Servers do seem fine to me though, except for some reasons that I mentioned above.
Brgds
Brgds
>From: Spice Sylvia
>To: "M. ELK" , 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" 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