Subject: Re: [PWE3] A doubt regarding draft-martini-l2circuit-trans-mpls-06.txt

From: Luca Martini <[email-masked]>
Date: Tue, 03 Jul 2001 15:33:43 -0600

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:     [email-masked]
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> 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
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager
[email-masked]

---

From: Giles Heron <[email-masked]>
Date: Tue, 03 Jul 2001 17:50:29 +0100

> to the reference model shown below:

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.

> and P-1 has been restored and the tunnel label for PE-2 re-learned?

Yes.

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

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

> 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

-- 
============================================================
Giles Heron      Principal Network Architect      Gone2 Inc.
ph: +44 7880 506185         "if you build it they will yawn"
============================================================

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 05 Jul 2001 10:54:00 -0400

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

--------

---

From: Giles Heron <[email-masked]>
Date: Thu, 05 Jul 2001 17:31:28 +0100

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 05 Jul 2001 12:46:44 -0400

Giles,

>In your example there is still a tunnel available.  It just isn't the

Perhaps, but not necessarily - for example, the primary tunnel could go 
down, triggering the generation of a backup tunnel, but for some small 
amount of time, there is no tunnel in existence.  Or, the primary could go 
down, and MPLS in IP or MPLS in GRE is defined as the backup "tunnel".  In 
either case, we don't want to withdraw the VC label.  And in the latter, 
case, we still want to allow new VC tunnels to be created.

Cheers,
Andy

---

From: Giles Heron <[email-masked]>
Date: Thu, 05 Jul 2001 17:58:58 +0100

> case, we still want to allow new VC tunnels to be created.

MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you
shouldn't withdraw the labels.

But yes, I take your case about backup tunnels.  Really this is the
standard issue of layering and holddown timers isn't it?  IF the backup
tunnel doesn't kick in within x seconds THEN withdraw the advertised
labels?

Giles

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 05 Jul 2001 13:22:02 -0400

Giles,

>tunnel doesn't kick in within x seconds THEN withdraw the advertised

It's not just that.  Another problem the current language is, for example, 
if A is advertising VC labels to B using DU, A needs to somehow figure out 
if B has a tunnel (of any sort) back to A before it can advertise the label 
to B.  I think that's impossible in the general case.

Cheers,
Andy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 05 Jul 2001 13:31:07 -0400

At 10:54 AM 7/5/2001 -0400, Andrew G. Malis wrote:
>out-of-band management channel - some method of IP connectivity for the 
>LDP signaling is all that is required.
>
>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

---

From: Giles Heron <[email-masked]>
Date: Fri, 06 Jul 2001 00:55:42 +0100

> to B.  I think that's impossible in the general case.

I'm ahead of you here (I think!)

Luca and I had just this debate - I was trying to persuade him to take
the text out on this very pretext.  Somehow he persuaded me that you
should still withdraw the label if you don't have a tunnel.  My memory
is rubbish, but I think the argument is that if A OR B doesn't have a
tunnel then it will withdraw its label and the (bidirectional) circuit
will go down.  Also of course in the (non-general) case of RSVP-TE
tunnels A and B should both know the status of tunnels in either
direction?

Giles

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 06 Jul 2001 10:00:13 -0400

Giles,

>tunnels A and B should both know the status of tunnels in either

I think it's impossible to make this check in the general case.  Here are 
some reasons:

1. The IP addresses used in RSVP and LDP signaling may be 
different.  Imagine an LSR using a distributed architecture over a number 
of line cards.  The RSVP tunnels are anchored in the line cards of their 
associated interfaces, and use a unique IP address for each line card in 
the RSVP sender object.  However, the LDP signaling for VC labels is 
anchored in a central processor card, and uses its own IP address.

If you're using OSPF or ISIS within an area, then presumably you can look 
at the RSVP and LDP IP addresses and confirm in the link state database 
that the RSVP and LDP addresses are from the same router ID.  However, that 
is not possible across areas, between ASes, or when using non-link-state 
routing protocols.

2. Even if an incoming TE tunnel's sender address matches that used for the 
LDP signaling, the receiving LSR has no way of knowing whether or not the 
sending LSR will choose to use that particular TE tunnel to carry the VCs; 
it may be restricted to IP traffic engineering.

So the sentence really has to go, since I think it's not implementable.

Cheers,
Andy

---

From: Giles Heron <[email-masked]>
Date: Sat, 07 Jul 2001 19:02:37 +0100

Hi Andy,

I'm not sure you're getting my point?

I agree 100% that there is no way to be sure that your peer has a valid
tunnel to you.

The point is that if you don't have a valid tunnel to your peer then you
should not advertise the VC label.

The intention is that this will keep the bidirectional VC "down" unless
both ends have valid tunnels to each other.

It may be worth rewording the text to make this clearer?

Giles