Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-opopsig-00.txt)

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 5 Jul 2002 08:49:51 +0100

Hi all,

I'd like to try to make one general comment about the on/off path question, namely that it really needs to be carefully distinguished from the question of whether protocol messages are implicitly or explicitly along whatever path. The latter question is really about NSIS addressing: we identified both modes in our latest framework document (section 3.3.4 if you're interested) and called them e2e and peer-session addressing respectively. Both are applicable in the on-path case; the off-path case basically requires the peer-session mode.

With peer-session addressing it's clear that you need to work out the address of the NSIS peer. I guess the emphasis on the on-path case means that we aren't going to put a lot of effort into working out the addresses of off-path peers. But (personally) I'd be worried if we built assumptions about the addressing model into other aspects of the protocol, and so it's unfair to say that an on path protocol is fundamentally unable to cope with traffic engineered networks - it's just that maybe NSIS won't provide all the address discovery mechanisms in this (fundamentally harder) case.

Cheers,

Robert H.

PS As an example, RSVP PATH messages are e2e addressed (in our terminology) whereas RSVP RESV messages are peer-session addressed. I don't think this makes RSVP an off path solution.

> -----Original Message-----
> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 04 July 2002 15:05
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] comments on draft in-path and out of path
> (draft-schel en-nsis-op opsig-00.txt)
> 
> 
> Hi Georgios,
> 
> my comments are in line.
> 
> Regards, Rüdiger
> 
> > Comment_2 on Section 3.2.1: 
> > -------------
> > I do not understand this comment:
> > "In these cases, a signaling unaware cloud is not anymore a 
> > signaling carrier, as nothing assures it will forward the
> > signal at the same place it will forward the dataflow."
> 
> On path signaling only recognizes layer 3 routing. 
> I guess the authors here refer to DiffServ aware 
> traffic engineering. There traffic of different 
> traffic classes may be forwarded along different routes
> - depending on their traffic class. Signaling messages
> are probably Best Effort, so QoS enabled data will in 
> fact travel a different MPLS route.
> The issue is that NSIS signaling is limited to layer 3
> (which I strongly appreciate). An on path solution is 
> layer 2 blind while an off path based solution doesn't
> have to be. That's a clear benefit if off path signaling
> is used.
> 
> > Comment on Section 3.2.3
> > -------------------
> > You mentioned:
> > "One problem of RSVP and intserv is that every router in the 
> > network must implement intserv and RSVP in order to link the
> > sink and the source with a chain of QoS capable routers that
> > all allocate resources for the flow."
> > 
> > [georgios] not all routers in a communication path have to 
> > implement Intserv. Actually, you mighty have domains that
> > are overprovisioned and do not implement Intserv.
> > What I try to say is that this issue applies to both types of 
> > architectures, i.e., on path and out of path. Therefore, it
> > is not fair to presented here as an on path issue!
> 
> Section 4.3.1 of the draft states that an off path QoS controller
> must be topology aware and therfore tap routing. So 
> overprovisioning is an option in domains using off path QoS 
> controllers, while it is a requirement for a domain using on
> path signaling unless all routers passed must evaluate the 
> signaling information.
> This too is a clear benefit of an off path solution.
> 
> >  * There may be a single point of failure
> > 
> >    Failure detection and error recovery are tremendously
> >    important.
> 
> Good point. I support your suggestion to add this issue to 
> the list of issues.
> 
> >  * Sophisticated mechanisms for discovery of the centralized
> >    entities are needed. This is an addition to your 
> >    Section 4.3.1.
> 
> Yes, true. AAA or COPS may be checked to look for existing 
> standard methods.
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 05 Jul 2002 12:15:56 +0200

Robert,

--On Freitag, 5. Juli 2002 08:49 +0100 "Hancock, Robert" 
<[email-masked]> wrote:

> Hi all,
>
> I'd like to try to make one general comment about the on/off path
> question, namely that it really needs to be carefully distinguished from
> the question of whether protocol messages are implicitly or explicitly
> along whatever path. The latter question is really about NSIS addressing:
> we identified both modes in our latest framework document (section 3.3.4
> if you're interested) and called them e2e and peer-session addressing
> respectively. Both are applicable in the on-path case; the off-path case
> basically requires the peer-session mode.
>

What you define as peer-session mode I alrady would call off-path, since it 
does not need to run hop-by-hop (according to your definition).
So to be exact you have to say that peer-session addressing with one 
hop-peers can be used in the on-path case.

> With peer-session addressing it's clear that you need to work out the
> address of the NSIS peer. I guess the emphasis on the on-path case means
> that we aren't going to put a lot of effort into working out the
> addresses of off-path peers. But (personally) I'd be worried if we built
> assumptions about the addressing model into other aspects of the
> protocol, and so it's unfair to say that an on path protocol is
> fundamentally unable to cope with traffic engineered networks - it's just
> that maybe NSIS won't provide all the address discovery mechanisms in
> this (fundamentally harder) case.

I don't get your point. And I don't see how the hell you are able to cope 
with traffic engineered networks in the on-path case using "normal" routing.

> Cheers,
>
> Robert H.
>
> PS As an example, RSVP PATH messages are e2e addressed (in our
> terminology) whereas RSVP RESV messages are peer-session addressed. I
> don't think this makes RSVP an off path solution.

Here I think again we need to differentiate the peer-session hop-by-hop or 
over several hops. And the RSVP RESV message hop objects even has local 
(interface number) information circumventing normal routing.

Marcus

>> Yes, true. AAA or COPS may be checked to look for existing

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus