Re: [mpls-tp] Issues with switchover from I-PMSI to S-PMSI (Multicast inMPLS/BGP IP VPNs)

[<[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Yakov Rekhter
> Sent: 16 June 2010 20:09
> To: Bishnoi, Sandeep S (Sandeep)
> Cc: [e-mail]
> 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'
> > 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 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.
> > 
> > 
>