Subject: LSP intiator

From: "Anil Gunturu" <[email-masked]>
Date: Sat, 7 Apr 2001 02:32:38 -0700

Hi,
Who initates the LSP setup in case of Ordered Downstream-on-Demand mode of
LDP operation.
RFC3031 indicates that for Ordered control LSP setup may be initiated from
either the ingress or the Egress LER. But, if the distribution mode is
Ordered Downstream-on-Demand can the LSP setup be initated from Egress?
Thanks,
-Anil
Anil Gunturu, Software Engineer
Ericsson, Inc                           phone: (805) 562 6431
Datacom & IP Services                   email: [email-masked]
70 Castilian Dr, Santa Barbara, CA-93117

---

From: "Anil Gunturu" <[email-masked]>
Date: Thu, 12 Apr 2001 20:17:16 -0700

Hi,
In case of LDP, how do you determine if the particular interface is Ingress
or not? Do we statically configure this? For an FEC if the next hop is not
MPLS we can say that it is an egress LER. But, can we infer this for an
Ingress LER?
Thanks,
-Anil

---

From: "Anil Gunturu" <[email-masked]>
Date: Thu, 12 Apr 2001 20:17:50 -0700

Hi,

---

From: David Charlap <[email-masked]>
Date: Fri, 13 Apr 2001 16:27:43 -0400

Anil Gunturu wrote:
> 
> In case of LDP, how do you determine if the particular interface is
> Ingress or not? Do we statically configure this?

Static configuration is certainly one possibility.

In theory, any interface capable of receiving unlabeled traffic,
classifying that traffic, and pushing a label, can be an ingress
interface.

This set may further be narrowed by applying heuristics, depending on
the application.  For instance, if the LSPs are used exclusively for
sending traffic across an OSPF area, and no further, then only the
area-border routers will have ingress interfaces.

Of course, an operator may not be happy with any kind of automatic
decision, so manual configuration must alwas be an option.

> For an FEC if the next hop is not MPLS we can say that it is an
> egress LER. But, can we infer this for an Ingress LER?

Egress LERs that are chosen in this fashion can be said to be at the
edge of the MPLS cloud.  And they make nice candidates for selection as
ingress routers.  But this isn't necessarily all of them.

-- David

---

From: "Anil Gunturu" <[email-masked]>
Date: Tue, 17 Apr 2001 02:36:51 -0700

Is there any other purpose for an explicit null label other than preserving
the Exp field for QoS purposes?
Thanks,
-Anil

---

From: Eric Gray <[email-masked]>
Date: Tue, 17 Apr 2001 08:16:17 -0400

Anil,

    It is not necessary to preserve the value of the EXP bits
using the explicit NULL label if the penultimate hop is able
to map the bits to a corresponding DSCP in the IP header.
But this is just one example of what the penultimate hop
might not be able to do, thus creating a need for explicit
NULL labels...

--
Eric Gray

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 17 Apr 2001 11:28:29 -0400

> might not be able to do, thus creating a need for explicit

That is only if the DSCP that is used outside the MPLS domain
corresponds to the QoS treatment inside the MPLS domain.  Any
correlation between ingress into the MPLS domain and QoS at that point
is lost.  The explicit NULL just loses the LSP while preserving the
EXP and is sufficient for unsignaled E-LSP where label is not
considered.

OTOH - One could make the argument that given the current state of QoS
deployment, any arguments about whether some feature better supports
QoS doesn't carry much weight.

Curtis

---

From: Eric Gray <[email-masked]>
Date: Tue, 17 Apr 2001 11:45:43 -0400

> EXP and is sufficient for unsignaled E-LSP where label is not

If the domain has also the ability to forward packets at the IP
layer, then the domain boundary routers will know how to map
an in-domain DSCP to an out-of-domain value.  In this case,
it is not necessary (however much simpler it may be) to pass
the EXP to the egress (that is also a domain boundary router).

> QoS doesn't carry much weight.

:-)