Subject: (Reply)Re: clarification on "LSR ingress for FEC"

From: [email-masked]
Date: Thu, 14 Oct 1999 13:59:15 +0800

For the case where "Multipath Label switching" is not used

LMp.13 should change from
"If not" to "If so"

chetan

--------------------------------------------------------------
Hi, all

In case of the following example, I have one question..

As you said, in this example, LSR B would be acting as the ingress for unlabeled packets for X and also intermediate node for traffic from A to X.
In this case, output label  for each case must be different if LSR B can't support merge capability.
It means that LSR C might send different two labels to LSR B for same FEC, one is for ingress role of LSR B and the other is for intermediate node.

However, this operation is impossible in the current LDP specification.
This point is described in LDP specification, which is from LMp.12 to LMp.13 [Page 96].

-   LMp.12  Does LSR have a previously received label mapping for FEC from MsgSource?
                    If not, goto LMp.14
-   LMp.13  Does the label previously received from MsgSource match Label (i.e., the label received in the message)?
                    If not, goto LMp.8.  (See Note 2.)

-  Note2.     A mapping with a different label from the same peer would be an attempt to establish multipath label switching, which is not
                    supported in this version of LDP.

Note 2 describe that these steps are required for preventing LSR from establishing multipath label switching, because current LDP version
doesn't support multipath label switching. Is there any special reason that LDP doesn't support multipath label switching??
I think that we have to consider multipath label switching for no merge capability, and this procedure(LMp.12 - LMp.13) should also be modified.

What do you think about this??  Please, correct me if I'm wrong..

Thanks in advance..
jinsuh/

-----Original Message-----
From: Anup Anil Cheruvathoor <[email-masked]>
To: Vasanthi Thirumalai <[email-masked]>
Cc: Mukul Katiyar <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Wednesday, October 06, 1999 1:56 PM
Subject: Re: clarification on "LSR ingress for FEC"

>Hi mukul,
>   A example for vasanthi's point .
>A LSR can act like the ingress as well as the transit for the
>same FEC. There is no restriction on this. For eg:
>
>              A
>                   \__
>                        B---C----D----- ...... X
>
>consider A and B LSRs as the edge nodes of the MPLS domain. For some destination
>say X , the path from A to X includes B in the path.
>
>B also gets unlabeled packets coming to it from non-mpls domain
>destined for X.
>So B would be acting as the Ingress for unlabeled packets for X. and transit for
>traffic
>from A to X.
>
>-Cheru
>
>

=================================================
Jinsuh Shin [[email-masked]]
                  1F Keopyung B-Town, 203,
                  Nonhyun-dong, Kangnam-gu,
                  Seoul, 135-010, Korea

                  TEL)  +82-2-3446-8119 [Ext. 361]
                  FAX)  +82-2-3446-8269
=================================================

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 15 Oct 1999 17:01:43 +0900

Chetan,

LMp.13 should be as it is, since there is a case in which an LSR 
receives multiple Label Mapping messages containing the same label 
from the same peer at least when updating hop count from egress LSR.

I think section A.1.2 is a little bit ambiguous about handling 
non-merging case. For example, my interpretation of LMp.12 is like this:

LMp.12  Does LSR have a previously received label mapping from MsgSource 
        for the LSP associated with FEC and Label ?
           If not, goto LMp.14

Regards,
Yoshihiro Ohba

From: [email-masked]
Subject: (Reply)Re: clarification on "LSR ingress for FEC"
Date: Thu, 14 Oct 1999 13:59:15 +0800