The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt
Sasha Vainshtein wrote:
>
> 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?
You mean the LDP session between PE-1 and P-1 has been closed I guess?
In any case my understanding is that the VC labels advertised by PE-1 to
PE-2 are now released by PE-1. The logic behind this is that PE-1 can't
reach PE-2 and so the bidirectional VC should be brought down.
> 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?
Yes.
> 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.
Well, you could say these are dependent. But it is a fairly loose
one-way coupling. In fact it applies regardless of the label
distribution used for the tunnel labels. It may just as well be RSVP as
LDP, or may not even be MPLS as you mention below.
> 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>)
Luca and I specifically discussed this case. His view was that in the
MPLS in IP or MPLS in GRE case you do have a "tunnel label", but that
tunnel label is implicit null. In any case you could really say that
having a route matching the destination IP address of the tunnel is
synonymous with having a tunnel label?
> I would highly appreciated any information regarding your
> reasons behind the new limitation.
AFAIK the reasoning behind the limitation was to ensure correct
knowledge of VC state, and to ensure that a VC is either
bi-directionally up or bi-directionally down. If PE-1 advertises a
label to PE-2 when it has no means of reaching PE-2 then PE-2 will
believe that the VC is "up" and send traffic over it.
HTH.
Giles
>
> With best regards,
> Sasha Vainshtein
> email: sasha@axerra.com
> tel: +972-3-7659993 (office)
> +972-8-9254948 (res.)
> +972-58-674833 (cell.)
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> http://www.ietf.org/mailman/listinfo/pwe3
--
============================================================
Giles Heron Principal Network Architect Gone2 Inc.
ph: +44 7880 506185 "if you build it they will yawn"
============================================================
|
|