Subject: RE: [NSIS] question to the wg on make before break

From: [email-masked]
Date: Tue, 20 Apr 2004 08:43:08 +0200

Hi Cheng Hong,

Thanks for your comments. Please find some replies below (inline).

Best regards,
Sven

"Cheng Hong" <[email-masked]> on 19/04/2004 18:14:03

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, <[email-masked]>
cc:    "'McDonald, Andrew'" <[email-masked]>, "'Georgios
       Karagiannis'" <[email-masked]>
Subject:    RE: [NSIS] question to the wg on make before break

Hi Sven,

My understanding is that the two cases differs on whether there is an IP
connectivity on the alternative path before the session transition (so
called break). The case 1) is when there is no such IP connectivity
available, and case 2) is when there is such IP connectivity.

Sven>> I don't think that is what I meant. In the first case, the idea is
to have a reservation on the new path in place when the old path needs to
be torn down and so you can immediately move the traffic to this new path.
The issue here is that you need a way to find out where this future path is
going to be (and how to reserve on it). In the second case, you just keep
the traffic on the old path after the route change while you are making the
reservation on the new path. The issue here is not with the signalling
(which follows the normal L3) but with the data which needs to be kept on
the old path somehow. Also, this is obviously not a good solution when the
old path has a failure.

For the case 1), it would require certain assistance for the signaling,
e.g.
the path "prediction", or proxy assistance, etc., to signal over the new
path. While for case 2), it is more like the multi-homed cases, and the
requirements would be similar to that.

I think both of the cases have typical usages, e.g. case 1) would be common
with the FMIP deployments, and case 2) could be a common multimode terminal
handover process. Therefore, they should all be supported by the NSIS
(NSLP+NTLP)

As for the case 1a), if I did not get it wrong, the "diverse-route-protect"
is the same requirement for the multi-home cases, and the similar what we
have discussed before.

For the case 1b), I am not very sure about the use cases. Do you mean that
the QNE could specify avoiding inclusion of another QNE on the new path to
the GMIP?

Sven>> The assumption is that case 1 also works with failures. 1a allows
you to protect against NE failures, 1b also protects against QNE failures
(compare it to link and node protection with MPLS FRR).

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Friday, April 16, 2004 10:09 PM
> To: [email-masked]
> Cc: McDonald, Andrew; Georgios Karagiannis
> Subject: [NSIS] question to the wg on make before break
>
>
> Hi all,
>
> During the early review session at the last IETF meeting, we
> got a question on the support of make-before-break
> reservation. The concept of make-before-break was introduced
> in RFC3209 (RSVP-TE) as a way to move traffic to a new LSP
> before tearing down the old LSP. This essentially requires
> one of two situations: 1. Pre-setup a reservation on a
> "future path": this requires explicit routing capability (and
> a way to figure out the future path). We would like to
> request the WG view on:
> - whether this should be supported
> - if yes, whether this is a functionality that should be
> supported by the NSLP. One aspect to consider here is what
> make-before-break scenario you would like to support:
>       a. reserve on a diverse path between two peer QNEs:
> this would require GIMPS to support explicit routing and the
> API to support the request for "diverse-route-protect". Do we
> want this?
>       b. reserve on a diverse path bypassing the peer QNE
> (make-before-break in case of QNE failure): this requires a
> way for the QoS NSLP to figure out a future peer QNE and a
> way to ask GIMPS to set up a connection to it (API issue). Do
> we want this?
>
> 2. Keep the data on the old path while the reservation on the
> new path is being set up: this requires route pinning but it
> doesn't seem to put additional requirements on either NTLP or
> NSLP (only on the forwarding function in the data plane):
> NSIS signalling always follows the current L3 route. However,
> it only helps when a better route becomes available, not when
> the current one fails.
>
> Cheers,
> Sven
>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>
>

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 20 Apr 2004 15:36:04 +0800

Hi Sven,

Please see some further comments below

cheers

Cheng Hong

> My understanding is that the two cases differs on whether 
> there is an IP connectivity on the alternative path before 
> the session transition (so called break). The case 1) is when 
> there is no such IP connectivity available, and case 2) is 
> when there is such IP connectivity.
> 
> Sven>> I don't think that is what I meant. In the first case, 
> the idea 
> Sven>> is
> to have a reservation on the new path in place when the old 
> path needs to be torn down and so you can immediately move 
> the traffic to this new path. The issue here is that you need 
> a way to find out where this future path is going to be (and 
> how to reserve on it). 

Agree. This is what the "make before break" needs to achieve. But, does it
mean that after finding out the future path, we could do signaling over it
immediately(having L3 connectivity)? I think in a FMIP case, it may not be
true. And another question I have is regarding the role of NSIS in the
"finding of the future path". Is that going to be part of the NSIS?

>In the second case, you just keep the 
> traffic on the old path after the route change while you are 
> making the reservation on the new path. The issue here is not 
> with the signalling (which follows the normal L3) but with 
> the data which needs to be kept on the old path somehow. 
> Also, this is obviously not a good solution when the old path 
> has a failure.

I would say I got a bit confused here. I don't know how the "route change"
is defined, but sounds like this is to delay the actual data path
transition. Obviously this is not always possible, due to physical
limitations. In a multi-mode/homed mobile terminal, this maybe possible.
But, if we take a closer look at the issue (with the supported case, e.g.
multi-home), is it equivalent to the case when the new path is available
before the "route change" happens? The reservation on the new path could be
made as the data remains on the old path. Maybe this is also covered in the
first case.

> For the case 1), it would require certain assistance for the 
> signaling, e.g. the path "prediction", or proxy assistance, 
> etc., to signal over the new path. While for case 2), it is 
> more like the multi-homed cases, and the requirements would 
> be similar to that.
> 
> I think both of the cases have typical usages, e.g. case 1) 
> would be common with the FMIP deployments, and case 2) could 
> be a common multimode terminal handover process. Therefore, 
> they should all be supported by the NSIS
> (NSLP+NTLP)
> 
> As for the case 1a), if I did not get it wrong, the 
> "diverse-route-protect" is the same requirement for the 
> multi-home cases, and the similar what we have discussed before.
> 
> For the case 1b), I am not very sure about the use cases. Do 
> you mean that the QNE could specify avoiding inclusion of 
> another QNE on the new path to the GMIP?
> 
> you to protect against NE failures, 1b also protects against 
> QNE failures (compare it to link and node protection with MPLS FRR).
> 
> 
> cheers
> 
> Cheng Hong
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > During the early review session at the last IETF meeting, we got a 
> > question on the support of make-before-break reservation. 
> The concept 
> > of make-before-break was introduced in RFC3209 (RSVP-TE) as 
> a way to 
> > move traffic to a new LSP before tearing down the old LSP. This 
> > essentially requires one of two situations: 1. Pre-setup a 
> reservation 
> > on a "future path": this requires explicit routing capability (and
> > 2. Keep the data on the old path while the reservation on 
> the new path 
> > is being set up: this requires route pinning but it doesn't seem to 
> > put additional requirements on either NTLP or NSLP (only on the 
> > forwarding function in the data plane): NSIS signalling 
> always follows 
> > the current L3 route. However, it only helps when a better route 
> > becomes available, not when the current one fails.
> >
> > Cheers,
> > Sven
> >
> >
> >