Re: make-before-break in Gmpls

[Curtis Villamizar <curtis@fictitious.org>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <3DED5C9E.A4679846@alcatel.be>, Dimitri.Papadimitriou@alcatel.be wri
tes:
> hi,
> 
> i think this issue concerning "se style" has been discussed
> some time ago but let's try here to give a bit more details,
> lsp's in gmpls are control plane entities mapping data plane
> ones, merging here does get sense if and only if the data
> plane would deliver the same capability, since the soft-
> provisioning that we can expect in shared meshed restoration
> is purely a control plane driven mechanism the corresponding
> entity doesn't occur at the data plane level and in particular
> for tdm, lsc and fsc lsp's, once committed you find out the 
> ff style as used today, as such there is no today something
> like you seem to assume as setup of an lsp "split" it when 
> a recovery lsp is needed and then "merge" it back when the
> recovery lsp find back the working lsp path, then next even
> if the methods that are under definition may be thought as
> similar to the frr ones, the following for instance wouldn't
> strictly apply (see fast-reroute):
> 
> "When using the sender-template-specific approach, the protected
> LSPs and the backup paths SHOULD use the Shared Explicit (SE)
> style. This allows bandwidth sharing between multiple backup
> paths. The backup paths and the protected LSP MAY be merged by the
> Detour Merge Points, when the ERO from the MP to the egress is the
> same on each LSP to be merged, as specified in [RSVP-TE]."
> 
> this because for non-packet networks do soft-provisioning 
> means let the capability to share the bandwidth on a control
> plane view of the resource basis otherwise just provision 
> it (commit it) since having a dedicated soft-provisioning 
> on a per lsp basis just means be dedicated at the data plane 
> level (if we assume a consistent usage of the mechanisms), 
> and on the other side have merging (not multiplexing) of 
> lsc or tdm at the data plane level is impossible (afaik) 
> thus the fact that one knows that the requested lsp is for 
> recovery purposes (link protection tlv s bit set) and its 
> resources have to allocated within a pool but not committed 
> (ie reserved) something which is needed in any case, do
> the job here.  
> 
> hope this clarifies a bit,
> - dimitri.


This doesn't seem to me to clear it up.

In make-before-break, sharing bandwidth means that you will use one or
the other LSP, but never both.  Same with FRR - the primary or detour
is used, but not both at the same time.  Such a merge is at least in
principle possible for TDM, LSC, and FSC (although LSC required either
same wavelength or wavelength shifting or OEO).  I said "in
principle".  Therefore in principle, SE could be used for TDM, LSC,
and FSC.  In practice, this may not (ever) be true.

The ingress would need to know if bandwidth was shareable when doing a
reroute.  Otherwise, it may pick a path for which the RSVP signaling
always fails for no apparent reason.  That the RSVP signaling would
fail would not be apparent from the TE-LSDB before the signaling.
Reroute by trial and error is not a good option.

Is there a way for the ingress to know on which "links" bandwidth is
shareable?  Should it simply be assumed that bandwidth is not
shareable on any TDM, LSC, and FSC links?

Curtis


> Manoj Agiwal wrote:
> > 
> > Hi ,
> >          The gmpls architecture documents says
> > "GMPLS does not add anything new. Elegant re-routing is possible with the
> > concept of "make-before-break" whereby an old path is still used while a ne
> w
> > path is set up by avoiding double reservation of resources. Then, the node
> > performing the re-routing can swap on the new path and close the old path.
> > This feature is supported with RSVP-TE (using shared explicit filters) and
> > CR-LDP (using the action indicator flag).
> >           Will this feature will hold good for optical networks as well ,
> > where we have TDM , LSC  LSPs. This would require use of
> >      SE style in optical networks . Does signaling has to take care of not
> > reserving extra resources ( bandwidth / time slot )
> >     across the common path of the two LSPs , what will happen at the nodes
> > where the two routes diverge and converge .
> >     Is it expected that the signal will get multicast to both the routes ,
> > and at the node where the route converge the signal
> >     is selected from the better of the two paths till the rerouted LSP is
> > torn down .
> > Regards,
> > Manoj
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : dimitri.papadimitriou@alcatel.be 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
>