The MPLS WG Archive

[Sasha Vainshtein <Sasha@AXERRA.com>]

Andrew, Luca and Giles,
Thank you for your responses, they clarified the situation for me.
I would say that Luka's suggestion that PE-1 and pE-2 may use an out-of-band
"backdoor" management channel for their LDP session creates a lot of
difference:
otherwise, following Andrew's reasoning, one could safely assume that,
as long as IP connectivity between PE-1 and PE-2 exists, PE-1 has a valid
"tunnel label"
(at worst, using MPLS-in-IP) to reach PE-2 and vice versa.
Of course, if a backdoor channel between PE-1 and PE-2 exists, this
reasoning
fails (because you do not want to flood the backdoor channel with traffic).
The LDP Hello Adjacency timeout between PE-1 and P-1 over their
in-band link would close the LDP session between them even if they can
communicate 
at IP level via a backdoor channel (which presumably is not covered by the
LDP
auto-discovery mechanisms).
On the other hand, I would like to understand how one should treat the same
problem in the
PWE3 over IP situation (which is a definitely  issue for the PWE3 WG). 
Maybe a valid solution would be a generic requirement for some form of
access control which
would block PWE3 signaling over backdoor interfaces?
For PWE3 over MPLS this would mean blocking LDP on all out-of-band ports.

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


-----Original Message-----
From: Andrew G. Malis [mailto:Andy.Malis@vivacenetworks.com]
Sent: Thursday, July 05, 2001 4:54 PM
To: Luca Martini; Giles Heron
Cc: Sasha Vainshtein; 'pwe3@ietf.org'; 'mpls@uu.net'; Alik Shimelmits; Gonen
Zilber; Israel Sasson
Subject: Re: [PWE3] A doubt regarding
draft-martini-l2circuit-trans-mpls-06.txt


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.

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


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
http://www.ietf.org/mailman/listinfo/pwe3