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

From: [email-masked]
Date: Fri, 5 Jul 2002 13:49:15 +0200

Robert,

There is one other traffic engineering issue related to point 1a (outgoing
interface selection). The (traditional) route towards a destination can
change. During this change, it is possible that data flow temporarily does
not go on the reserved path. Traffic engineering techniques such as
load-balancing on inter-domain links by means of dynamically changing the
AS prepending could significantly increase the occurence of such changes.
It is then not the cause of a new issue but of the increased importance of
an existing one.

Sven

"Hancock, Robert" <[email-masked]>@ietf.org on 05/07/2002
12:46:24

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>, "'Geib, Ruediger'"
      <[email-masked]>, [email-masked]
cc:   [email-masked]
Subject:  RE: [NSIS] comments on draft in-path and out of path (draft-schel
          en-nsis-opopsig-00.txt)

Marcus,

The question of one IP hop or many is again a different issue. As an
example (but I think it clarifies everything), RSVP operates over non-RSVP
clouds; this means that RSVP RESV messages are peer-session addressed in
all cases, over one IP hop or several. (And in fact, I can't recall if the
message processing even changes at all between the two cases.)

In terms of NSIS coping with traffic engineered networks, I'd consider a
breakdown of NSIS functionality as follows:
1) There is a means for NSIS entities to work out how to address outgoing
messages. This requires
1a) Outgoing interface selection (and in fact this is all you need for
on-path signalling if all hops are NSIS-aware), or more generally
1b) Next NSIS neighbour addressing (explicit or implicit) (if it might be
more than one hop away)
2) Everything else - state management, error handling, security, you name
it.

In a traditionally routed network, (1b) is easy in all cases (RSVP PATH).

In a non-traditionally routed network, where all the nodes are NSIS aware,
you just need to modify (1a), but the NSIS protocol could already contain
all the information that implementation needs to work on (i.e. the flow
information), so this is just an implementation issue. There's no rule
which says that NSIS has to use the node's routing table to do interface
selection. And (2) should be unchanged.

If not all the nodes are NSIS aware, it's true that you need to do
something new for (1b). But again, (2) should be unchanged (or rather, I
think that should be a design goal for us).

So, I'm not claiming to be able to cope with traffic engineered networks
with normal routing. I'm just claiming that we should be able to design
NSIS so that _most_ of the protocol isn't affected by the issue, and that
in the case of all nodes being NSIS aware it should be an implementation
matter.

Robert

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 05 July 2002 11:16
> To: Hancock, Robert; 'Geib, Ruediger';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] comments on draft in-path and out of path
> (draft-schel en-nsis-opopsig-00.txt)
>
>
> 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
>
> >> -----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
> >>
>
>
>
> --------------------------------------
> 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
>
>
========================================================================================

Permission is hereby granted to pass the contents of this communication to
third parties and any restrictions regarding confidentiality do not apply.
(See attached file: RMRL-Disclaimer.txt)