The MPLS WG Archive

[Sasha Vainshtein <Sasha@AXERRA.com>]

Luka,
After comaring <draft-martini-l2circuit-trans-mpls-06.txt> 
with the -05 version I have found the following addition which
troubles me.
In the 1st para of Section 5 you state that
<quote>
Note that if the tunnel label is not available, the 
VC label MUST NOT be advertized.
<end quote>
This statement suggests several questions which all refer
to the reference model shown below:

----------          ----------          ----------          ----------
|        |          |        |          |        |          |        |
|  PE-1  |<-------->|  P-1   |{...PSN..}|  P-2   |<-------->|  PE-2  |
----------          ----------          ----------          ----------
   ^   ^               ^                      ^               ^     ^
   |   |               |                      |               |     |
   |   -- LDP Session --                      -- LDP Session --     |
   |      for tunnel                             for tunnel         |
   |   label distribution                     label distribution    |
   |                                                                | 
   ------ LDP Session for VC Label distribution ---------------------

Let us assume that:
1. Vanilla LDP in DU mode is used in the core PSN for distribution of 
labels creating hop-by-hop routed LSPs between PE devices. FT LDP
is NOT deployed
2. PE-1 and PE-2 each advertise some (may be Implicit NULL) labels
for IPv4 Host Address FECs (each - for its own Router ID address).
PE-1 does it via its LDP session with P-1, and PE-2 - via its
LDP session with P-2. DU mode of LDP guarantees that PE-1 eventually
learns IPv4 Host Address FEC for PE-2 and its label binding via its
LDP session with P-1, and vice versa for PE-2.
3. PE-1 and PE-2 establish (using LDP extended discovery mechanism)
an LDP session between them which is used for distribution of
VC labels
4. Now let us consider the following situation: for some reason
the LDP session between PE-1 and P-1 has been CLOSED but IP connectivity
between PE-1 and PE-2 remains intact. The simplest example is a situation
when protocol processing and forwarding functions in P-1 are distributed
(say, to different boards) and the protocol processor board has been
reset. As a consequence, PE-1 loses (for some time) the tunnel label
for PE-2. Nevertheless, the LDP session between PE-1 and PE-2 remains
unaffected buy such a disruption. The following questions now arise:
a) What happens to VC labels which have been advertized by PE-1 to PE-2
before the LDP session between PE-1 and PE-1 has been closed? 
b) If a new VC FEC is created in PE-1 while there is no tunnel label
in it for the PE-2 IPv4 Host Address FEC, it is not advertised to PE-2.
Do you suggest that it is advertised once the LDP session between PE-1
and P-1 has been restored and the tunnel label for PE-2 re-learned?

I think that this example described above demonstrates 
that the new limitation introduced in the -06 release requires
a certain dependence between LDP sessions maintained by PE-1 
(and PE-2).AFAIK LDP definitions in, RFC 3036 allow for only 
one type of interaction between different LDP sessions,
namely the ordered label distribution control mode. 
IMHO, this type of interaction is irrelevant for distribution 
of VC labels because LSRs which distribute them serve as egress LERs
for the associated FEC and hence may distribute them at any time regardless
of the label distribution control mode.

Another example is provided by the situation when there is no
MPLS connectivity in the core PSN. Of course, in this case 
there are no LDP sessions between PE-1 and P-1, PE-2 and P-2;
nevertheless, the LDP session between PE-1 and PE-2 may exist.
Section 5.1.1 of  <draft-malis-sonet-ces-mpls-04.txt> 
suggests using MPLS-in-IP to create CEM over the IP PSN; 
by implication, this mechanism is equally applicable
to all types of VCs. The limitation in the -06 draft makes it, however,
impossible to use LDP for distribution of VC labels in such a scenario
because there are no tunnel labels at all.
(BTW, the idea of using MPLS-in-IP has recently been adopted for 
L3 VPNs as shown in <draft-rosen-ppvpn-ipsec-2547-00.txt>)

I would highly appreciated any information regarding your
reasons behind the new limitation.


With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)