The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [PWE3] A doubt regardingdraft-martini-l2circuit-trans-mpls-06.txt
I'm not sure that this disagrees with our position at all?
In your example there is still a tunnel available. It just isn't the
primary tunnel?
Giles
"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.
>
> 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
--
============================================================
Giles Heron Principal Network Architect Gone2 Inc.
ph: +44 7880 506185 "if you build it they will yawn"
============================================================
|
|