Subject: RE: [NSIS] WG Last call on the Requirements Draft?

From: [email-masked]
Date: Tue, 15 Oct 2002 19:48:33 +0300

Hi Melinda,

> I'm in the process of going through the document and one
> thing pops out at me that I really think has to be addressed
> ASAP.  In section 5.2, several requirements (which are not
> actually stated as requirements, incidentally) suggest that
> we're supporting off-path signaling.  I believe that this is
> currently (and possibly forever) out of scope.  This has
> been discussed quite a bit and it's my recollection that the
> working group never came to a decision.  
> 
> This also needs to be consistent with the framework document.

This sounds like a reasonable request, but more detail
would help - what text looks bad, etc.

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

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Oct 2002 10:05:00 +0200

<Re-sent (need to first subscribe with my e-mail address)>

But as far as I have seen the list the consensus was to not rule-out the 
off-path (what ever it is, see the E-Mail thread on that), but focus on the 
on-path. And I hope that the formulation does reflect this.

Or in other words if we find a protocol which works mainly on-path but also 
for off-path we can still use it in NSIS and are not obliged to throw it 
away.

Marcus

--On Dienstag, 15. Oktober 2002 11:12 -0400 Melinda Shore 
<[email-masked]> wrote:

> Melinda

--------------------------------------
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

---

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

Hi Marcus,

> What I have seen from CASP as well as our proposal for RSVP version 2 does 
> have the off-path signaling option.
> 
> The main difference (and I regard this as implementation issue) is that 
> there need to be two ways of finding the next hop in an NSIS deamon ( I 
> think CASP even provides more cases).

I think that we can leave hooks in for the off-path signaling, but I hope
we don't drive protocol work to accomplish it.  I would prefer to get the
basic on-path signaling work well stablized before developing off-path
signaling.

John

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Oct 2002 10:05:30 +0200

[..]
> If you take a look at other requirements documents that have
> recently been published as RFCs in the Transport Area you'll
> see that the actual requirements material typically starts
> somewhere around page 4 or 5 and sometimes as early as page
> 1.  In the NSIS requirements document the requirements
> material starts on page 10.  I think a great deal of that
> introductory material should be removed from the
> requirements document and integrated into the framework
> document if it's not already in there.

But in some of your later mails you say we need to define what this and 
that means. And I do not see framework stuff in it more terminology.

Marcus

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Oct 2002 10:05:51 +0200

Marcus

--On Donnerstag, 17. Oktober 2002 13:06 -0400 Melinda Shore 
<[email-masked]> wrote:

>> But as far as I have seen the list the consensus was to
>> not rule-out the off-path (what ever it is, see the E-Mail
>> thread on that), but focus on the on-path. And I hope that
>> the formulation does reflect this.  Or in other words if
>> we find a protocol which works mainly on-path but also for
>> off-path we can still use it in NSIS and are not obliged
>> to throw it away.
>
> I think it would be a big mistake and could easily result in
> never producing a working protocol.  It would be helpful if
> someone who thinks that it is in scope could scratch
> together a diagram of how they think it might work.
>
> That's not to say that I think this is not IETF work - I do
> think it is.  I just don't think that it could reasonably
> fit into an end-to-end signaling protocol.  As it happens,
> there is a diagram in the framework document of how it could
> be done by NSIS working in conjunction with another
> protocol, and that's Figure 8.
>
> Melinda

---

From: Melinda Shore <[email-masked]>
Date: Fri, 18 Oct 2002 09:03:57 -0400

At 10:57 AM 10/18/02 +0300, [email-masked] wrote:
>we don't drive protocol work to accomplish it. 

I would agree with that - it seems like the right approach.

Melinda

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 18:25:22 GMT

*> 
  *> > But as far as I have seen the list the consensus was to
  *> > not rule-out the off-path (what ever it is, see the E-Mail
  *> > thread on that), but focus on the on-path. And I hope that
  *> > the formulation does reflect this.  Or in other words if
  *> > we find a protocol which works mainly on-path but also for
  *> > off-path we can still use it in NSIS and are not obliged
  *> > to throw it away.
  *> 
  *> I think it would be a big mistake and could easily result in
  *> never producing a working protocol.  It would be helpful if
  *> someone who thinks that it is in scope could scratch
  *> together a diagram of how they think it might work.
  *> 
  *> That's not to say that I think this is not IETF work - I do
  *> think it is.  I just don't think that it could reasonably
  *> fit into an end-to-end signaling protocol.  As it happens,
  *> there is a diagram in the framework document of how it could
  *> be done by NSIS working in conjunction with another
  *> protocol, and that's Figure 8.
  *> 
  *> Melinda

Melinda,

I assume this discussion is about the extent to which the NSIS WG should
consider path-decoupled signaling, right?

Here is a suggestion.  Hopefully we can define a CSTP protocol layer
that could be essentially [weasel word] the same for either
path-coupled or path-decoupled signaling.  So this moves the issue up
to the ALSP layer.  It is unclear to me exactly how NSIS is going to
wrap itself around the 2-layer model, but I could imagine it defining
the CSTP layer and one ALSP for path-coupled QoS signaling.  Another
WG could then tackle an ALSP (or multiple ALSPs if necessary) for
path-decoupled signaling.

Bob Braden

---

From: [email-masked]
Date: Fri, 25 Oct 2002 12:49:38 +0300

Hi Bob,

> path-decoupled signaling.

I agree with you.  This has been my thought all along.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 28 Oct 2002 17:12:53 +0100

Hi Bob 

I agree with your suggestion on having a 
common CSTP for different signaling purposes.
However, the number of ALSPs, that could be used in combination
with the CSTP, for path coupled QoS signaling might be 
more than one.

Best Regards,
Georgios

-----Original Message-----
From: Bob Braden [mailto:[email-masked]]
Sent: donderdag 24 oktober 2002 20:25
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [NSIS] WG Last call on the Requirements Draft?

  *> 

Melinda,

Bob Braden