Subject: RE: [NSIS] on-path versus off-path discussion

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 18 Oct 2002 11:44:18 +0200

Marcus,

what's the definition of path? I remember 
one of John (I think) saying path 
means AS path and nothing more. Is this 
still valid?

Regards, Rüdiger 

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Friday, October 18, 2002 10:44 AM
> To: [email-masked]; [email-masked]
> Cc: SLS list
> Subject: [NSIS] on-path versus off-path discussion
> 
> 
> The issue about on-path signaling versus off-path signaling 
> raises quite a 
> bit of traffic on the NSIS WG mailing list. You can call it 
> also in-band or 
> out-of-band signaling. There still not a clear definition of 
> what on and 
> what off-path is. E.g. you could call RSVPv1 RSRV message 
> off-path because 
> it does not follow the path base on IP routing.
> 
> There definitely are some pro and cons for both approaches. 
> See "On path 
> and off path signaling for NSIS", 
> draft-schelen-nsis-opopsig-00.txt for a 
> discussion on some of them. Furthermore, there are some 
> implementations 
> (experimentqal and products) available for centralized QoS 
> provisioning.
> 
> We need to clarify what the way forward is concerning 
> off-path signaling. 
> On-path is in the charter of the NSIS WG. Additionally, there 
> are a number 
> of issues for clarifying what on-path includes. In certain cases the 
> boundary is not straight forward.
> 
> Currently, there seam to be 3 positions in the community:
> 1) Forget about off-path, nobody will use it and it is 
> architecturally 
> problematic in IP networks
> 2) Form a new WG taking care of the off-path issue completely 
> independent 
> of NSIS.
> 3) Require NSIS to work for on- and off-path signaling, because data 
> objects to be carried by the protocol should basically be the 
> same in both 
> cases, and a soft-state approach is worth for off-path as well.
> 
> Current draft dealing with some of the issues
> "On path and off path signaling for NSIS", 
> draft-schelen-nsis-opopsig-00.txt
> 
> Discussion list:
> mailing list is called "nsobs", which stands for "Next Steps 
> in Out-of-Band 
> Signaling" is Majordomo list at ccrle.nec.de
> 
> To subscribe send e-mail to [email-masked] with 
> subscribe in 
> the body.
> 
> To send E-Mail to the list use [email-masked]
> 
> 
> --------------------------------------
> Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> Phone: +49 (0) 6221 905 11 29
> personal home page: http://www.brubers.org/marcus
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> Phone: +49 (0) 6221 905 11 29
> personal home page: http://www.brubers.org/marcus
> 
> 
> _______________________________________________
> 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: "Hancock, Robert" <[email-masked]>
Date: Fri, 18 Oct 2002 11:04:41 +0100

hi all,

there are plenty of definitions of "path", and plenty of definitions of what "on/off" one of them might mean.

what the *nsis* w.g. needs to be clear about (as melinda has pointed out) is what definition we agree on, and then (implicitly) what is currently in or out of NSIS scope. (i guess this would also be useful input to discussing the scope of any complementary or additional activity.)

a proposed definition is on the table in 3.2.1 of draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a teaser, this definition would classify both RSVP PATH and RESV messages as path coupled, and therefore legitimately in NSIS scope (even though the latter uses what we call peer-session and not end-to-end addressing).

send comments! 

cheers,

robert h.

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 18 October 2002 10:44
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] on-path versus off-path discussion
> 
> 
> Marcus,
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 18 Oct 2002 14:46:36 +0200

Hello John

Is this feeling part of the requirements doc or the charter 
or wherever it fits well to? Or would it be a bad idea to 
put it down somewhere?

Thanks for clarification,

Rüdiger

> [JL] My feeling is that they don't want us to work on discovery.
> Discovery should come automatically, due to the signaling.

> [SB] signaling from an end system that follows a path through
> the net that is determined by the normal L3 routing and is 
> used to convey per-flow information to the devices the 
> signals pass through - the signaling can install soft state
> (maintained by repetition) in the devices it passes through

---

From: [email-masked]
Date: Fri, 18 Oct 2002 16:13:57 +0300

Hi Marcus,

> architecturally problematic in IP networks

The correct answer is, of course, NSIS was chartered for
on-path signaling.  Off-path may have some validity,
but should be done after the basic protocol work has been
completed or done in a seperate WG.

Thanks,
John

---

From: Bob Braden <[email-masked]>
Date: Sat, 19 Oct 2002 12:16:01 -0700 (PDT)

*> From [email-masked]  Fri Oct 18 03:05:47 2002
  *> X-UIDL: m!L"!Y2E!!jAW"!0d7"!
  *> From: "Hancock, Robert" <[email-masked]>
  *> To: "'Geib, Ruediger'" <[email-masked]>, [email-masked]
  *> Cc: [email-masked]
  *> Subject: RE: [NSIS] on-path versus off-path discussion
  *> Date: Fri, 18 Oct 2002 11:04:41 +0100
  *> MIME-Version: 1.0
  *> X-BeenThere: [email-masked]
  *> X-Mailman-Version: 2.0.12
  *> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
  *> 	<mailto:[email-masked]?subject=unsubscribe>
  *> List-Id: Next Steps in Signaling <nsis.ietf.org>
  *> List-Post: <mailto:[email-masked]>
  *> List-Help: <mailto:[email-masked]?subject=help>
  *> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
  *> 	<mailto:[email-masked]?subject=subscribe>
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> 
  *> hi all,
  *> 
  *> there are plenty of definitions of "path", and plenty of definitions of what "on/off" one of them might mean.
  *> 

Robert,

RSVP established a meaning for "path".  I fail to see why NSIS should
try to (re-)invent terminology.  

  *> what the *nsis* w.g. needs to be clear about (as melinda has pointed out) is what definition we agree on, and then (implicitly) what is currently in or out of NSIS scope. (i guess this would also be useful input to discussing the scope of any complementary or additional activity.)
  *> 
  *> a proposed definition is on the table in 3.2.1 of draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a teaser, this definition would classify both RSVP PATH and RESV messages as path coupled, and therefore legitimately in NSIS scope (even though the latter uses what we call peer-session and not end-to-end addressing).

I believe that your term has the same meaning as the term I already
introduced in my 2-level signaling I-D, "path-directed [signaling]".
Again, why should we have to keep re-inventing terminology?

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Sat, 19 Oct 2002 12:23:00 -0700 (PDT)

*> Marcus,
  *> 
  *> what's the definition of path? I remember 
  *> one of John (I think) saying path 
  *> means AS path and nothing more. Is this 
  *> still valid?
  *> 
  *> Regards, Rüdiger 
  *> 

Friends,

This is not really that hard.  A [network] path is a sequence of
network locations.  To be precise, you have to say what kind of
path you mean.  In the BGP context (only!), an AS path is
a sequence of autonomous systems.  In common usage in the Internet,
an unqualified "path" usually means a data path, ie the sequence of
nodes traversed by some data flow (or aggregate).   That is the
way that RSVP uses the term.

Since there seems to be some confusion in the NSIS membership,
perhaps we had better always qualify "path".

Bob Braden

---

From: [email-masked]
Date: Mon, 21 Oct 2002 11:36:19 +0300

Hi all,

> what the *nsis* w.g. needs to be clear about (as melinda has 
> pointed out) is what definition we agree on, and then 
> (implicitly) what is currently in or out of NSIS scope. (i 
> guess this would also be useful input to discussing the scope 
> of any complementary or additional activity.)

Agreed.
 
> a proposed definition is on the table in 3.2.1 of 
> draft-ietf-nsis-fw-00.txt ("path coupled/decoupled"). as a 
> teaser, this definition would classify both RSVP PATH and 
> RESV messages as path coupled, and therefore legitimately in 
> NSIS scope (even though the latter uses what we call 
> peer-session and not end-to-end addressing).

This I can live with.

John

---

From: Bob Braden <[email-masked]>
Date: Mon, 21 Oct 2002 19:03:27 -0700 (PDT)

*> 
  *> [reh] there is no intended difference, just an attempt to pin down some of the corner cases which some people were unclear about. (the only reason for using 'path-coupled' is that 'path-decoupled' sounds OK as a term for the opposite, which we also needed.) 
  *> > 
  *> > Bob Braden
  *> > 

Robert,

I guess the opposite to "path-oriented" would be "path-disoriented", eh?
;-)

I take you point.

Bob

---

From: [email-masked]
Date: Wed, 30 Oct 2002 13:56:45 +0200

Hi Marcus,

> I think the question boils down to whether an NSIS protocol 
> should "hard code"
> the use of IP routing/forwarding state or whether we allow also other
> routing/forwarding mechnisms to be used for signaling. 

The assumption from our ADs is that NSIS will be using IP routing
/ forwarding state.  It is also the opinion of the ADs that we will
not be working on any other routing/forwarding mechnisms to be used 
for signaling in NSIS.  This does not mean that they think this work
is unimportant, they just see it as not part of the NSIS charter.

Does this answer the question?

John

---

From: Bob Braden <[email-masked]>
Date: Wed, 30 Oct 2002 07:09:35 -0800 (PST)

*> 
  *> Hi Marcus,
  *> 
  *> > I think the question boils down to whether an NSIS protocol 
  *> > should "hard code"
  *> > the use of IP routing/forwarding state or whether we allow also other
  *> > routing/forwarding mechnisms to be used for signaling. 
  *> 
  *> The assumption from our ADs is that NSIS will be using IP routing
  *> / forwarding state.  It is also the opinion of the ADs that we will
  *> not be working on any other routing/forwarding mechnisms to be used 
  *> for signaling in NSIS.  This does not mean that they think this work
  *> is unimportant, they just see it as not part of the NSIS charter.
  *> 
  *> Does this answer the question?
  *> 

John,

With all respect to you and the ADs, I suggest again that the answer
might be different at the signaling transport (ST) and the signaling
application (SA) layers.

Bob

  *> John
  *> _______________________________________________
  *> 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: [email-masked]
Date: Fri, 1 Nov 2002 00:00:42 +0200

Hi Bob,

> might be different at the signaling transport (ST) and the signaling

I agree.  I can easily see the SA being used for different things.  
What I think is important for us, as a WG, would be to start bounding
the problem.  I think we have greatly exploded the possible areas to
investigate in the WG - and we are getting no closer to meeting our
deliverables.  

Additionally, we have to meet certain requirements in order to actually
begin protocol work.  A 'simplified' RSVP needs to be shown to be
infeasible before we can do anything.  

I have yet to see a convincing argument why an off-path signaling protocol
is needed - though a lot of people would like to use such a protocol.
I will suggest that 'off-path' signaling discussion be closed, until someone
can produce a good document explaining why it is imperative that it
be considered by the NSIS WG.

Further more, I think that the requirements document can be somewhat simplified,
and generalized (covering both the ST & SA layers you mention above).
We need some good analysis of existing solutions (Mike Thomas' MIP & RSVP
document is a good start).

So, in summary, I will reserve some time in Atlanta to discuss these bigger
picture issues & how to move forward with this work.  My initial feeling is
that we need to restrict the scope of what we are trying to do - because
at this point we are diverging.

thanks,
John

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:01:01 +0200

Hi Bob,

> My answer is: "yes and no""!  I suggest that the CSTP level 
> of the two-level model should be general enough to support either 
> path coupled or path-decoupled signaling.  However, when NSIS 
> considers developing an ALSP for QoS signaling,
> I have the serious doubts I expressed previously about the 
> architectural wisdom of path-decoupled operation.  I hope the 
> WG will at least require a convincing technical argument (which 
> I have not yet heard) in favor of the path-
> decoupled model before including it in the (first) ALSP.

My current thinking (to be discussed/resolved in Atlanta) would
be to work on two AL (application layer) protocols - one providing
an 'rsvp v2' type of service and another one for NAT traversal.
As both of these consider things-on-the-path of the data, the
path de-coupled case is out of scope.  Now, I do think we may
be clever enough that the transport layer protocol we design
could be used for path decoupled signaling, I don't think that
is something we are work on (yet).

John

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:01:07 +0200

Hi,

> or wherever it fits well to? Or would it be a bad idea to 

I'll tack this on to my things to discuss in Atlanta ;)

John