Subject: Re: clarification on "LSR ingress for FEC"

From: "Jinsuh Shin" <[email-masked]>
Date: Wed, 13 Oct 1999 11:57:07 +0900

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: [email-masked]
Date: Fri, 15 Oct 1999 17:50:46 +0800

Right, the non-merging case is handled.

In case of the modification suggested
by Yoshihiro Ohba LMp.13 becomes a redundant check.

Also regarding, LMp.19:
"LMp.19  Are RAttributes in the received label mapping consistent with
           those previously sent to Peer?
           If so, goto LMp.24.  (See Note 4.)"

Is it necessary to goto LMp.24?

cheers
chetan

-----Original Message-----
Yoshihiro Ohba,

I agree with your interpretation of LMp.12.
In case of non-meging, we have to distinguish proper LSP from others when we received a Labe Mapping message,
and it can be achieved by "Label request Message ID TLV" in Label Mapping message. 
That is good modification for handling non-merging case.

jinsuh/

-----Original Message-----
From: Yoshihiro Ohba <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Thursday, October 14, 1999 3:22 PM
Subject: Re: (Reply)Re: clarification on "LSR ingress for FEC"

>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: "Jinsuh Shin" <[email-masked]>
Date: Fri, 15 Oct 1999 20:12:32 +0900

Chetan,

I don't think that LMp.13 is a redundant check in case of the modification suggested by Yoshihiro Ohba.
Because LMp.13 is used for preventing LSR from establishing multipath label switching for same LSP.
It means that LMp.13 step checks only label received in message. 
Then, if the label received in message is matched with the label previously received from MsgSource,
Update RAttributes at LMp.19 - LMp.23 step when RAttribues are not consistent with those prviously sent to peer. 

jinsuh/

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