The MPLS WG Archive

[Zhang Haiyan <zhanghaiyan@huawei.com>]

Mitchell,

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

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

----- Original Message ----- 
From: "Erblichs" <erblichs@earthlink.net>
To: "George Swallow" <swallow@cisco.com>
Cc: <mpls@ietf.org>
Sent: Tuesday, February 07, 2006 9:11 AM
Subject: Re: [mpls] LDP Multicast to WG Document


> 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

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