Subject: [mpls] LDP Multicast to WG Document

From: George Swallow <[email-masked]>
Date: Mon, 06 Feb 2006 07:50:51 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Erblichs <[email-masked]>
Date: Mon, 06 Feb 2006 17:11:41 -0800

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
		-----------------

---

From: Thomas Morin <[email-masked]>
Date: Tue, 07 Feb 2006 08:41:16 +0100

> Please indicate your support or objections by the end of this week.

I support this work becoming a working group item.

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Tue, 07 Feb 2006 18:53:51 +0100

Hi Mitchell, folks,

> 	done it because of some fast-reroute policy if one of the selected

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

---

From: Zhang Haiyan <[email-masked]>
Date: Wed, 08 Feb 2006 11:17:07 +0800

Mitchell,

>    some form of consistent selection should be available.

IMO, when the transit node reveives the downstream Label Map, it allocates label 
and installs forwarding state for both downstream and upstream, i.e. the two directional
LSPs are set up at the same time in the MP2MP Label Map procedures. It ensures 
that both directions follow the same transit nodes (LDP peers).

Regards,
            Zhang

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 08 Feb 2006 02:48:52 -0800

George,

> Please indicate your support or objections by the end of this week.

Support.

Yakov.

---

From: Rahul Aggarwal <[email-masked]>
Date: Sun, 12 Feb 2006 13:34:44 -0800 (PST)

Hi George,

Support.

rahul

---

From: Arthi Ayyangar <[email-masked]>
Date: Mon, 13 Feb 2006 11:05:40 -0800 (PST)

Support.

-arthi