The MPLS WG Archive

[Thomas Morin <thomas.morin@rd.francetelecom.com>]

Hi Mitchell, folks,

Erblichs:
> 	2) 2.3.1.1.  Determining one's 'upstream LSR'
> 
>    A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
>    which lies on the best path from Z to the root node X. If there are
>    more than one such LDP peers, only one of them is picked.  U is Z's
>    "Upstream LSR" for <X, Y>.
> 
> 	Multiple parts:
> 
> 	"only one of them is picked"
> 	Am I correct that you are picking U equals?
>
> 	Why isn't some identifier for the LDP peer used to compare
> 	the multiple LDP peers for the "picking"?
> 
> 	Why wouldn't you want to have a known result based on a public
> 	algortihm, like highest router-id?
> 
> 	Why can't more tban one be picked?
> 
> 	And why wouldn't you want to pick 2 or more and load balance or have
> 	done it because of some fast-reroute policy if one of the selected
> 	"U" fails?

Load balancing for one tree can't work: if you have more than one
upstream branch, since all traffic for this P2MP FEC has to flow on each
of them, so you'll end up with duplicates at the point where they meet
again downstream.

I think your points are relevant though:
- its true a router has to chose precisely one upstream (for a said P2MP
tree) - among the set of upstreams that the lowest cost
- in the case where there happens to be a transit LAN, then the
procedure for choosing one upstream would need to be standardized; or
else two downstream may elect a different upstream which would result in
some bandwidth waste (when no transit LAN exists, this doesn't need to
be standardized, local decision is ok)
- it could be a very simple procedure: as you suggested "take the
highest router id"
- but it could be one that would allow for load balancing,
  like hashing each {root,opaque-id,upstream-candidate} with a simple
  standard hash and electing as upstream router the one with the lowest
  hash value.

That would be very nice.

-Thomas


> George Swallow wrote:
> > 
> > It has been requested that
> > 
> > Label Distribution Protocol Extensions for Point-to-Multipoint and
> >              Multipoint-to-Multipoint Label Switched Paths
> >                  draft-minei-wijnands-mpls-ldp-p2mp-00
> > 
> > become a MPLS WG document.
> > 
> > Please indicate your support or objections by the end of this week.
> > 
> > Thanks,
> > 
> > ...George
> > 
> > ========================================================================
> > George Swallow             Cisco Systems                  (978) 936-1398
> >                            1414 Massachusetts Avenue
> >                            Boxborough, MA 01719
> > 
> > _______________________________________________
> > mpls mailing list
> > mpls@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls