The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Feb> msg00014



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] LDP Multicast to WG Document

  • From: Erblichs <erblichs@earthlink.net>
  • Date: Mon, 06 Feb 2006 17:11:41 -0800
  • Cc: mpls@ietf.org

George Swallow,

	I have done little work with P2MP and MP2MP,
	so I do not feel correct in voicing my opinion,
	however, I would like to ask a few questions.

	Just clarifying a few issues in my mind. Any answers
	would be helpful.

	1) 1.2 Terminology

	  With transit and bud LSR types,"directly connected"
	  is used. Can I assume that basic and extended nbr
	  peer discovery and establishment both qualify for
	  "directly connected".

	  Because, I only consider the extended with targeted
	  hello's and have a "grey" understanding of whether
	  those are always really "directly connected".

	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?

	
	3) 4.  Setting up MP2MP LSPs with LDP

	   Am I right that we would want the identical
	   forward and reverse (ack/replies) data flows (directional LSPs)
	   to follow the same LDP peers in both directions? we could verify
	   this with a LSP traceroute.

	   If both the paths don't traverse the same LDP peers, I could
	   assume that one direction could have a significantly faster
	   bandwidth. 

	   Thus both sides (ingress/egress) of the 2 or more directional
	   LSPs should attempt to use the same transit LDP peers. Thus,
	   some form of consistent selection should be available.

	   (Clarify: One path of Ingress A to Egress B, and the replies
	    coming from Ingress B to Egress A,  both directional
	    data flows transitioning either the same set of LDP peers
	    or a different set. I would assume that they should be the
	    same set of transit LDP peers.)

	   My reason why...

	   Thus, If the reply segments take a faster bandwidth LSP and
	   our data flows are also controlled by TCP, won't the acks
	   return with less inter segment / packet spacing. This decreased
	   spacing will force the newer data segments to be bunched even
	   more (congestion avoidance) than just adding 1 segment per
	   round trip.

	   If the first source/Ingress to Egress data path is faster than
	   the return, won't we waste the return bandwidth capacity?

	   Thus a LSP traceroute should be the same as either initiated
	   from the Ingress or from the Egress ends of the path.

	You can offline the email if you don't think anyone is
	intereted in the answers.

	Thanks,
		Mitchell Erblich
		-----------------
	   

	
	

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