The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 10:54 AM 7/5/2001 -0400, Andrew G. Malis wrote:
>Luca and Giles,
>
>I would like disagree a bit with your replies to Sasha, especially with an 
>eye to supporting tunnel redundancy for VC carriage.  As we've previously 
>discussed, VC labels are only allocated from the per-platform label space, 
>and also, as we've previously discussed, the VC label distribution 
>signaling via LDP extended discovery is independent of the tunnels used to 
>carry the VCs.  As Luca mentioned, it could even be carried by an 
>out-of-band management channel - some method of IP connectivity for the 
>LDP signaling is all that is required.
>
>Thus, if a VC label is using a particular tunnel for transport, and the 
>tunnel should go down (for example one of the intermediate LSRs is in a 
>rolling blackout :-) but a backup tunnel is available or is opened using 
>the MPLS redundancy/resilience mechanism of your choice, then the VC 
>should be stay open and just use the new tunnel, with the exact same VC 
>labels.  And if QoS isn't important for the application (say, Ethernet 
>over MPLS) then there's no reason why a label stack with the VC label 
>can't be transported to the destination LER via MPLS-in-IP or MPLS-in-GRE.

         Don't forget the case where a tunnel head can re-route itself via
a different path option. In this case, the same tunnel head interface
can be used with a different underlying LSP. This will preserve the
  tunnel's characteristics while not interrupting the VC.

         --Tom




>Cheers,
>Andy
>
>--------
>
>At 7/3/2001 03:33 PM -0600, Luca Martini wrote:
>>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
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>http://www.ietf.org/mailman/listinfo/pwe3