Subject: Issues with switchover from I-PMSI to S-PMSI (Multicast in MPLS/BGP IP VPNs)

From: "Bishnoi, Sandeep S (Sandeep)" <[email-masked]>
Date: Wed, 16 Jun 2010 12:55:16 -0500

Authors,

Draft suggests using a 'switch-over' delay while switching from I-PMSI to S-PMSI. This is with an assumption that 'switch-over' interval would be sufficient to setup P-Tunnels.

Would this not create issue for RSVP-TE PMSI as path setup cannot be guaranteed for all leaf nodes for TE LSP? It is more 'likely' that RSVP-TE P-tunnel may not be even setup as there is no path that can qualify all TE parameters.

IMO - switch-over decision should also consider status of P-tunnel for source initiated P-tunnels and not just depend on a timer. If the P-tunnel is not up after 'switch-over' interval then it must withdraw previously announced binding so that leaf nodes do not switch to S-PMSI.

-Sandeep

>From draft (section 7.1.1):

     - PE1 must issue the required control plane information to signal
       that the specified C-flow is now bound to P-tunnel P2 (see
       section 7.4).

     - If P-tunnel P2 needs to be constructed from the root downwards,
       PE1 must initiate the signaling to construct P2.  This is only
       required if P2 is an RSVP-TE P2MP LSP.

     - If the specified C-flow is currently bound to a different
       P-tunnel, say P1, then:

         * PE1 MUST wait for a "switch-over" delay before sending
           traffic of the C-flow on P-tunnel P2.  It is RECOMMENDED to
           allow this delay to be configurable.

         * Once the "switch-over" delay has elapsed, PE1 MUST send
           traffic for the C-flow on P2, and MUST NOT send it on P1.  In
           no case is any C-flow packet sent on both P-tunnels.

   When a C-flow is switched from one P-tunnel to another, the purpose
   of running a switch-over timer is to minimize packet loss without
   introducing packet duplication.  However, jitter may be introduced
   due to the difference in transit delays between the old and new
   P-tunnels.

   For best effect, the switch-over timer should be configured to a
   value that is "just long enough" (a) to allow all the PEs to learn
   about the new binding of C-flow to P-tunnel, and (b) to allow the PEs
   to construct the P-tunnel, if it doesn't already exist.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 16 Jun 2010 12:08:43 -0700

Sandeep,

> Authors,
> 
> Draft suggests using a 'switch-over' delay while switching from
> I-PMSI to S-PMSI. This is with an assumption that 'switch-over'
> interval would be sufficient to setup P-Tunnels.
> 
> Would this not create issue for RSVP-TE PMSI as path setup cannot
> be guaranteed for all leaf nodes for TE LSP? It is more 'likely'
> that RSVP-TE P-tunnel may not be even setup as there is no path
> that can qualify all TE parameters.
> 
> IMO - switch-over decision should also consider status of P-tunnel
> for source initiated P-tunnels and not just depend on a timer. If
> the P-tunnel is not up after 'switch-over' interval then it must
> withdraw previously announced binding so that leaf nodes do not
> switch to S-PMSI.

Actually with RSVP-TE p2mp LSP the root may first build the p2mp
LSP, and only after the root determines that the LSP has been
successfully built, the root should issue the required control plane
information to signal that the specified C-flow is now bound to
that p2mp LSP.

This way if (for whatever reason) the root determines that it can
not build the p2mp LSP, the root would not even issue the required
control plane information to signal that the specified C-flow is
now bound to that p2mp LSP.

Note however, that with mLDP p2mp LSP the root can not rely on the
mLDP procedures to determine whether the LSP has been successfully
built. 

Yakov.

---

From: Richard Li <[email-masked]>
Date: Wed, 16 Jun 2010 14:14:28 -0700

It makes sense, but I would appreciate it if you are more clear about the
following case:

Suppose that RSVP-TE P2MP LSP is already set up, and a new receiver PE wants
to join it by sending a Type 4 (Leaf A-D) route to the sender PE (root) in
response to a previously received "Leaf Info Required". At this time the
sender PE will originate a S2L-Sub_LSP which carries the receiver PE
address. Now the question is: Should the root (sender PE) wait until the sub
LSP is set up before it issues the required control plane information to
signal that the specified C-flow is now bound to that p2mp LSP? Or the root
just immediately issues the required control plane information?

/RL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yakov Rekhter
Sent: Wednesday, June 16, 2010 12:09 PM
To: Bishnoi, Sandeep S (Sandeep)
Cc: [email-masked]
Subject: Re: Issues with switchover from I-PMSI to S-PMSI (Multicast
inMPLS/BGP IP VPNs)

Sandeep,

> Authors,
> 
> Draft suggests using a 'switch-over' delay while switching from I-PMSI 
> to S-PMSI. This is with an assumption that 'switch-over'
> Would this not create issue for RSVP-TE PMSI as path setup cannot be 
> guaranteed for all leaf nodes for TE LSP? It is more 'likely'
> that RSVP-TE P-tunnel may not be even setup as there is no path that 
> can qualify all TE parameters.
> 
> IMO - switch-over decision should also consider status of P-tunnel for 
> source initiated P-tunnels and not just depend on a timer. If the 
> P-tunnel is not up after 'switch-over' interval then it must withdraw 
> previously announced binding so that leaf nodes do not switch to 
> S-PMSI.

Actually with RSVP-TE p2mp LSP the root may first build the p2mp LSP, and
only after the root determines that the LSP has been successfully built, the
root should issue the required control plane information to signal that the
specified C-flow is now bound to that p2mp LSP.

This way if (for whatever reason) the root determines that it can not build
the p2mp LSP, the root would not even issue the required control plane
information to signal that the specified C-flow is now bound to that p2mp
LSP.

Note however, that with mLDP p2mp LSP the root can not rely on the mLDP
procedures to determine whether the LSP has been successfully built. 

Yakov.

---

From: <[email-masked]>
Date: Thu, 17 Jun 2010 08:23:05 +0100

Yakov,

You raise a quite general and important point here.....I could re-phrase
your observation, which applies to any co-cs (using GMPLS CP say) or
co-ps mode server layer network, as:

"Client (child) traffic units must only be allowed to be sent inside
their (parent) connection (== LSP IFF this has a single source) once the
CP (or MP) has established that the (parent) connection has been
correctly established and under the assumption that the (parent)
connection is misconnectivity defect-free." 

Note:

-	this observation applies to both p2p and p2mp connections;

-	the clause '....and under the assumption that the (parent)
connection is misconnectivity defect-free' is quite general/normal for
any co-cs/ps network for the 'set-up' phase of a connection.  The key
architectural point here is that a (server) layer connection is a
constraining construct for (child) traffic/OAM units when it is
misconnectivity defect-free, and this point (ie assumed to be
misconnectivity defect-free) allows several short-cuts to be taken on
the labelling used in traffic units, eg omit SA label altogether, DA
label can be proxied by link-significant-only label for forwarding, PID
label can be omitted providing the server layer connection only carries
a single client over its lifetime.  During the (usually much longer)
'information transfer' phase we need to run a CV OAM flow in the DP of
the connection (the CV flow should contain the
network-significant/unique SA of the connection) to check that correct
connectivity is maintained over the connection lifetime.

-	note also that the activation/deactivation of the CV OAM flow
must be synchronised with whatever CP (or MP) protocol/process
sets-up/tears-down (respectively) the connection. 

The above observations should also be taken into account within the work
on MPLS-TP.....hence why I am copying this to that list for their
information.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Yakov Rekhter
> Sent: 16 June 2010 20:09
> Subject: Re: Issues with switchover from I-PMSI to S-PMSI 
> (Multicast inMPLS/BGP IP VPNs) 
> 
> Sandeep,
> 
> > Authors,
> > 
> Actually with RSVP-TE p2mp LSP the root may first build the 
> p2mp LSP, and only after the root determines that the LSP has 
> been successfully built, the root should issue the required 
> control plane information to signal that the specified C-flow 
> is now bound to that p2mp LSP.
> 
> This way if (for whatever reason) the root determines that it 
> can not build the p2mp LSP, the root would not even issue the 
> required control plane information to signal that the 
> Note however, that with mLDP p2mp LSP the root can not rely 
> on the mLDP procedures to determine whether the LSP has been 
> successfully built. 
> 
> Yakov.
>

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Jun 2010 10:43:34 -0400

> Suppose that RSVP-TE P2MP LSP is already set up, and a new receiver PE
> wants to join it by sending a Type 4 (Leaf A-D) route to the sender PE
> (root) in response to a previously received "Leaf Info Required".

If the P2MP is already set up, then it is likely that data is already being
sent on it.  If a new receiver cannot be added to the LSP, then that new
receiver is not going to be able to get the data at all.

> Now the question is: Should the root (sender PE) wait until the sub
> signal that the specified C-flow is now bound to that p2mp LSP?

For this question to apply, the new receiver would have to join during the
interval between (a) the LSP gets successfully set up to the previous set of
receivers, and (b) the S-PMSI A-D route is sent.  I don't think this case is
worth worrying about.

---

From: Richard Li <[email-masked]>
Date: Thu, 17 Jun 2010 09:11:13 -0700

I meant that the S-PMSI LSP is already set up, but the switchover from
I-PMSI to S-PMSI has not happened.  The data is being sent out on I-PMSI.
According to the original spec, a switchover timer is fired. But before the
expires, a new Leaf A-D is received. Now the root wants to add the new leaf
to S-PMSI. Now the root is faced with two choices: (1) when the timer
expires, it switches over to S-PMSI and (2) It waits until the new
S2L-Sub-LSP is completed and starts a new timer. 

It looks the spec is not clear about the above situation.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Thursday, June 17, 2010 7:44 AM
To: [email-masked]
Cc: 'Yakov Rekhter'; [email-masked]
Subject: Re: Issues with switchover from I-PMSI to S-PMSI (Multicast
inMPLS/BGP IP VPNs)

> LSP is set up before it issues the required control plane information 
> to signal that the specified C-flow is now bound to that p2mp LSP?