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

From: [email-masked]
Date: Tue, 20 Apr 2004 09:16:56 +0200

Hi Dave,

Thanks for your comments. I have tried to address them inline.

Best regards,
Sven

"David R. Oran" <[email-masked]> on 19/04/2004 20:37:44

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

--On Friday, April 16, 2004 4:08 PM +0200 [email-masked]
wrote:

> 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
I think the answer should be yes, but I don't understand the comment about
needing explicit routing to make this work (at least as the term is used in
the MPLS world). Could you elaborate?

Sven>> Hm, I may have jumped to conclusions here (I am afraid I have a
history of MPLS traffic engineering work). What I meant is that we cannot
rely on 'normal layer 3 routing' to make the reservation on the 'future
path'. I suppose any policy-based routing mechanism will work.

> - if yes, whether this is a functionality that should be supported by the
> NSLP.
Hmmm, this may be another of those pesky "between the layers" things. Why
should this have to be invented separately for QoS, NAT/Firewall, or other
NSLPs?

Sven>> In my opinion, if we choose to support this kind of functionality,
it should be requested by the NSLP over the API but implemented at the NTLP
(at least for case 1a). For case 1b, I think it becomes a different matter
because you need the NSLP to be detect its future peer (at the risk of
being blasphemous I would say you need a peer discovery mechanism that
allows you to search on future paths). One thing that may alleviate the
problem is that it is likely (in C-mode) that a QNE already has a
connection to the future peer (because it was a peer for other
destinations)

> 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?
Supporting disjoint path constraints, all other things being equal, is a
good idea. In fact, it might be a good idea to think through a way to
express a variety of constraints since disjoint path is only one of a
number of possibilities. I do believe that disjoint path as a constraint
does require at least route recording, and possibly explicit routing (in
the sense of pre-computed and source routed). One thing to consider here is
if this gets into the nether world of backing NSIS into a complete QoS
routing protocol which will make PNNI look like a walk in the park.

Sven>> I don't know if the GIMPS designers want to go there.

>       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?
>
Won't this happen correctly as a side effect of next-hop selection? If not,
then there's something about the architecture I must misunderstand.

Sven>> I think the next-hop selection will automatically find the new next
hop but only after a while. So this mechanism will not allow making the
reservation in advance at the new next hop QNE.

> 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.
>
Right - that's one reason I don't think we can retain the single-path model
of routing that NSIS assumes today.

NSIS needs access to the RIBs as well as the FIBs, it seems, unless the
routing system puts alternate path info in the FIB along with the active
path info. Again, striking a bblance between just managing resources on the
single best path that routing tells NSIS about and diving full depth into
QoS routing is going to be an interesting juggling act.

Sven>> I know of one proposal (I think it was draft-walton-...) where a
suggestion was made to extend BGP reachability with alternate paths (well
reachability information technically I guess). At the time there were also
some individual drafts on BGP extension for QoS routing. Is any of this
still alive?

Not to mention keeping C-mode and D-mode straight and having a good
interface for D-mode that allows NSIS to express forwarding constraints to
the routing layer...

Dave.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 20 Apr 2004 13:25:16 +0100

hi,

Some (non-in-line) comments on this question, mainly from an 
NTLP perspective.

1. The current message routing mechanism is fundamentally 
incapable of sending messages along anything other than the 
current 'active' path. 

in large part, this is a consequence of having to live with
NSIS-unaware nodes *and* not wanting to do explicit routing.
Or, to put it the other way round: with explicit routing you
can do anything (but then you need a route calculator somewhere);
if you don't have explicit routing, and some nodes are not
NSIS aware, then primary path is all you can have (since the
D mode message is only sensitive to the FIB at such nodes).

So, one question would be: do you want these capabilities only
in a fully-NSIS-aware network or in a network which includes
NSIS-unaware nodes? (if the former, there are several options;
if the latter, ER is I think all that can be used.)

2. Is there any structured definition anywhere of what sort
of routing diversity we would be trying to achieve or live with?
Once you go away from a single path, there would seem to be a
lot of ways of having more than one.

I assume there is such a taxonomy e.g. from MPLS or PNNI or
SDH/SONET work, but I'm not sure how applicable it is here:
isn't it all based on setting up route sets with particular protection
properties, rather than setting up state along those route sets?

To put it another way: in the 'single path' case, the basic
NSIS position is
a) routing defines where the flow goes (its path);
b) signalling sets up state along the flow's path

In the multi-path case, is there the same split? Or are people
assuming the signalling is going to do part of (a)? Some of the
discussion below (e.g. distinguishing between whether the backup
path goes to the same QNE or goes to a different one, or imposing
disjointness contraints) seems to me to come into category (a),
which (at least initially) I would regard as out of scope for
NSIS.

3. Some design issues: Firstly, I don't see the C/D split as 
a problem here. For the bulk of the protocol, the operation 
doesn't need to depend on how the next peer was discovered
(although you may need to bind a particular messaging association
to the discovery mechanism in some cases). 

More importantly, what I think the discussion implies is that
we need to hold open the concept of GIMPS allowing multiple
message routing mechanisms (of which 'send along the path of
a real flow and intercept' is just the first). That is something
that is already partly on the table (since one of the NATFW messages
may need a slightly different message routing mechanism from 
ordinary NSIS messages). 

It may be that this modularisation is enough flexibility for
the first versions - provided people can define just what 'sending
a message along the backup path' really means, and we get the
boundary round the message routing method concept right, we can reserve a
place for it without actually designing all the details.

robert h.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2004 08:17
> To: David R. Oran
> Cc: [email-masked]; McDonald, Andrew; Georgios Karagiannis

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Wed, 21 Apr 2004 11:41:14 +0200

Hi All, 

This feature is interesting but I am wondering if we can think of it in the current phase of NSIS. As far as I know WG agreed to cocentrate on on-path signaling.

Best regards, Attila

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Hancock, Robert
> Sent: Tuesday, April 20, 2004 2:25 PM
> To: [email-masked]'; David R. Oran
> Subject: RE: [NSIS] question to the wg on make before break
> 
> 
> hi,
>