The MPLS WG Archive

[Luca Martini <luca@level3.net>]

Sasha,

comments below:


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

( or somebody uses an out of band management network for ldp sessions )

> 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?
pe-1 and pe-1 ? you mean PE-1 and PE-2 ?
if an LDP session is closed all assiciated labels are removed from the
local LDP binding database.



> 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. in a similar way as BGP recalculates the IGp recursion once an IGP
next hop changes interface.


> 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>)

yes, to add to Giles comment , please consider a LER that does not do
PHP.
In the IP in MPLS tunnel you have 3 possibilities:
1) PHP label 3 ( implicit null ) advertised  -> no label on in the IP
packet.
2) Label 0 ( explicit null ) advertised -> label 0 is put in the ip
packet.
3) no PHP label x advertised -> label x is put in the ip packet.

Hence you can say that as far as the MPLS forwarding table is concerned
all the 3 above modes have a IGP tunnel label.
( look in the cisco at the "untagged" vs "pop tag" mode in "sh mpls
forward")


> 
> 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.)
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> http://www.ietf.org/mailman/listinfo/pwe3

Luca

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Architect, Level 3 Communications -
Broomfield, CO
luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager
page-luca@level3.net