Subject: Receive Label Receive !!

From: Manoj Dutta <[email-masked]>
Date: Sun, 13 May 2001 23:11:15 -0700

Hi,

According to RFC3036 Section A.1.4, a label should be removed from
forwarding/switching use when an upstream peer releases a label
(subsection LRl.10). Now, consider a case where a downstream LSR Rd
propagates label Ld to upstream peer Ru for a set of fec elements {f1,
f2....}. It seems like Rd will remove label Ld from forwarding/switching
for traffic from Ru even when Ru releases the label Ld for only one
fec,say f1.  Consequently, bindings of label Ld to the remaining fec
elements {f2,f3....} is also lost and all the packets bearing the label
Ld from Ru will have to be either discarded or forwarded using ip
forwarding. I think that Rd should retain label Ld till Ru releases
label Ld for all the fecs {f1, f2...}. Let me know if this is correct.

Thanks in advance
Manoj

---

From: Abhijit M Gadgil <[email-masked]>
Date: Mon, 14 May 2001 12:27:15 +0530 (IST)

manoj,

If u have a look at rfc3031, pg 15, Scope and Uniqueness of the Label, It
gives a clear picture as to when Rd can use same label for different FECs
for Upstream LSR(s). Let us suppose the Label Ld resides in some label
space LS. This will not let u distribute Ld for different FECs as it will
not be possible to distinguish the FEC from the label value. If on the
other hand the Label Ld was there in two label spaces (say per interface),
then upon receiving the label release for that Label from Upstream, u will
delete the label from the corrosponding label space and Ld can still be
used by packets for other FECs..

Hope that helps.

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Mon, 14 May 2001 11:25:42 -0400

Manoj,

    I believe that this is a hole in the Label Release procedures as well.
Bob may have a better idea of what it should say, but one way to fix the
problem is to change LRl.10 and LRl.11 as follows:

      LRl.10  If Label is not associated with any other FEC for MsgSource,
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              remove Label from forwarding/switching use for traffic from
MsgSource.
              ^

      LRl.11  Do any peers still hold Label for any FEC?
                                                ^^^^
              If so, goto LRl.13.

This modified wording should cover the scenario that you point out...

--
Eric Gray

---

From: Eric Gray <[email-masked]>
Date: Mon, 14 May 2001 11:45:07 -0400

Abhijit,

    Part of the trouble (perhaps inconsistency is a better word) between
RFC3031 and RFC3036 is the meaning of the word FEC.  From a purely
architectural point of view, it never makes sense to issue the same label
for multiple FECs.  If you define a FEC as a group of packets which will
be forwarded the same way, and you consider the consequences of using
the same label, you will see that issuing the same label for multiple FECs
essentially groups these 'FECs' into a single FEC (since they will be
forwarded in the same way by the LSR that issued the common label).

    However, from the pragmatic perspective you need to adopt to develop
a signaling protocol, it is necessary to consider the case where a group
of FECs from Ru's perspective maps to a single FEC from Rd's point of
view.  By giving the same label for all of these FECs to Ru, Rd is able to
avoid having to merge multiple incoming LSPs from Ru onto a single LSP
downstream from Rd.

    As I implied in my earlier reply to Manoj, however, the fact that this is

allowed does not mean that this behavior is universally loved.  :-)

--
Eric Gray

---

From: Chris Kuszmaul <[email-masked]>
Date: Mon, 14 May 2001 10:41:33 -0700

Indeed, consider: (the following was sent as private email to a couple folks on
the list, but I think it merits a broader audience)

 In thinking about this, I ended up wondering what would happen when the
next hop changes, in the following scenario:

Suppose we have A connected to B, connected to C and D, with C and D each
connected to E and F

            ----C----E
A---B<          X
           -----D----F

Suppose that we do unsolicited ordered advertisement, to create LSPs leading
to E and F.

C and D both aggregate their FECs, and B receives the following
advertisements

MsgSource   Label   FEC
C                    C1       E
C                    C1       F
D                    D1       E
D                    D1       F

Lets assume (on B)

next_hop(E) = C
next_hop(F) = C

B will advertise to A, such that A receives the following (the same
advertisements are made to C and D)

MsgSource     Label    FEC
B                      B1        E
B                      B1        F

 Then, we will have label switching as follows

A:  dest E => push B1 (forward to B)
A:  dest F => push B1 (forward to B)
B: B1 => pop, push C1 (forward to C)***
C: C1 => pop.              (forward to E or F as appropriate)
D: D1 => pop               (forward to E or F as appropriate) (but D1 never
gets pushed by B)

 Now, suppose, on B, the next hop to get to E changes from C to D.

NH1:  yes
NH2:  Remove label  C1 (mapped to the FEC {E}) from forwarding/switching
use. (line *** above is deleted)
NH3   yes
NH6   no
NH10 yes
NH11 yes
NH12 generated Received Label Mapping from D, label = D1, FEC = {E}

   Now, in the received label mapping procedure:
   (MsgSource = D, FEC = E, label = D1)

    LMp1: No
    LMp3: No loop
    LMp9: Yes
    LMp10 Yes
    LMp11 next_hop(E) = D == MsgSource
    LMp12 Yes
    LMp14 No
    LMp16 record that the mapping <D1, E> has been received from D.
    LMp17 For each of A, C and D:
      LMp18 Yes
      LMp22 for the label mapping <B1, E>
      LMp23 Yes?! (because the previous mapping was aggregated, it might be
different, but does it matter?)
      LMp27
      LMp28 no
      LMp30 for the label mapping <B1, E> install D1 and B1 for forwarding
switching - where line ***
                  was deleted, we place:

                B: B1 => pop, push D1 forward to D

    LMp31  Because the label advertisements to A, C and D were the same,
nothing else is done.
    LMp33 DONE

NH20 DONE

Now the label switching looks like:

A:  dest E => push B1 (forward to B)
A:  dest F => push B1 (forward to B)
B: B1 => pop, push D1 (forward to D) <<< The change
C: C1 => pop.              (forward to E or F as appropriate)
D: D1 => pop               (forward to E or F as appropriate) (but D1 never
gets pushed by B)

 A packet with a destination of F, starting at A does:

A: push B1, forward to B
B pop, push D1, forward to D %%%%%%
 but at B, next_hop(F) == C

 It seems to me that somewhere in here that B should have done a label
mapping of <B2, E> to A, and a withdrawal to A, of <B1, E> , so that at the
end, things look like:

A: dest E => push B2
A: dest F => push B1
B: B1 => pop, push C1 (forward to C)
B: B2 => pop, push D1 (forward to D)
C: C1 => pop  (forward to E or F as appropriate)
D: D1 => pop  (forward to E or F as appropriate)

  But there is a problem with this too: If we first do the label mapping
<B2, E> to A, then that is a second label mapped to the same FEC, which is
disallowed by LMp.10.

  If we first withdraw <B1, E>, then we have broken the LSP, with no LSP for
a packet with a destination of E.

  Have I missed something in the spec?

 Thanks

CLK

---

From: Abhijit M Gadgil <[email-masked]>
Date: Wed, 16 May 2001 09:37:35 +0530 (IST)

Hi,
 after going thr' the topology and the scenario u described, I think,
the basic problem starts when C and D merge the FECs and send one label
upstream. The topoplogy u mentioned works because C/D is doing Pop and
then IP header is exposed. If there was some label given by E and/or F,
then its impossible for packets with label C1 to determine the
right FEC, and to attach correct label. Unless one does IP lookup after
the pop and then Push label depending upon the look up result. (which
defeats the purpose of using MPLS)

Any thoughts?

-abhijit

Abhijit Gadgil

On Mon, 14 May 2001, Chris Kuszmaul wrote:

>   Indeed, consider: (the following was sent as private email to a
> couple folks on the list, but I think it merits a broader audience)
>

---

From: Chris Kuszmaul <[email-masked]>
Date: Wed, 16 May 2001 09:43:53 -0700

Certainly, if one never did FEC aggregation, then the problem goes away.
However,  the ability to support FEC aggregation is not only called for in the
spec, it is a documented feature of at least one vendor.

  Meanwhile, if E and F give labels, it is still entirely possible for B to
aggregate the FECs represented by those labels. It is still possible for the next
hop at B for one of those FECs to change, and to break all the LSPs aggregated
into the label advertised by B.

  1: Is my interpretation of the spec correct?
  2: If correct, what is the fix?
       a. Disallow any FEC aggregation.
       b. Add a label-replace-mapping message.
       c. Allow multiple labels per FEC.
       d. When any FEC element's mapping must be withdrawn, withdraw all elements
of the aggregated FEC.
       e. other...

  Thumbnail arguments for each choice:

a: Easiest to implement, straightforward inter operability.
b: Cleanest fix that preserves multiple FEC elements per FEC.
c: Least effect on the spec, and a likely change for future versions of LDP
anyway.
d: Easiest to implement while preserving multiple FEC elements.
e. I did not think of it.

 Thumbnail arguments against:

a: Poor conservation of labels.
b: Significant change in the spec.
c: Obliterates the notion of one-to-one mapping between FEC and label.
d: Destroys innocent LSPs.
e: I did not think of it.

CLK