Subject: RE: [NSIS] Updated Charter

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 20 Nov 2002 02:54:47 -0000

John,

A couple of comments related to non-routing issues:

1. I'll record my comment in the meeting that defining QoS classes, parameters, service types, pre-emption capability, you name it, should be a non-goal (I don't know if it needs to be explicit).

2. I note that an NSLP for a midcom application is not a charter goal initially (and even in the future might be an activity for another w.g. anyway). However, I'd still like to capture the relevance of a midcom-like application as a user (of the NTLP). In particular, we should be clear that discussion of it (and indeed other applications, like network path monitoring as mentioned at the meeting) is 'in scope' for the overall work, e.g. of the framework and security documents. (Again, I don't know if this needs to be explicit.)

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 19 November 2002 14:43
> To: [email-masked]
> Subject: [NSIS] Updated Charter
> 
> 
> Hi all,
> 
> Here is the updated charter I presented at IETF55 today.  
> Please send comments.
> 
> John
> 
> Next Steps in Signaling (nsis) Charter
> 
> Chair(s):
> J. Loughney <[email-masked]>
> 
> Transport Area Director(s):
> S. Bradner <[email-masked]>
> A. Mankin <[email-masked]>
> 
> Transport Area Advisor:
> A. Mankin <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> In Body: (un)subscribe
> Archive: 
> www.ietf.org/mail-archive/working-groups/nsis/current/maillist.html
> 
> Description of Working Group:
> 
> The Next Steps in Signaling Working Group is responsible for 
> standardizing an IP signaling protocol with QoS signaling as 
> the use case for NSIS.  This working group will concentrate 
> on a two-layer signaling paradigm.  The intention is to 
> re-use, where appropriate, the protocol mechanisms of RSVP, 
> while at the same time simplifying it and applying a more 
> general signaling model.  
> 
> The existing work on the requirements, the framework and 
> analysis of existing protocols will be completed and used as 
> input for the protocol work. 
> 
> NSIS will develop a transport layer signaling protocol for 
> the transport of upper layer signaling. In order to support a 
> tool box or building block approach, the two-layer model will 
> be used to seperate the transport of the signaling from the 
> application signaling.  This allows for a more general 
> signaling protocol to be developed to support signaling for 
> different services or resources, such as NAT & firewall 
> traversal and QoS resources.  The initial NSIs application 
> layer will be an optimzed RSVP signaling.  Potential for a 
> second NSIS application layer, in order to ensure a generic 
> transport signaling protocol, will be considered in 
> consultation with the Transport Area directors.
> 
> Security is a very important concern for NSIS. The working 
> group will study and analyze the threats and security 
> requirements for signaling. Compatibility with authentication 
> and authorization mechanisms such as those of Diameter, 
> COPS-PR, and RSVP-PR auth-session, will be addressed.
> 
> It is a non-goal of the working group to develop new resource 
> allocation protocols. Resource reservation and traffic 
> engineering are out of scope of this working group.  
> Additionally, third party signaling is out of scope of this 
> working group.  Mobility protocols and AAA work are out of 
> scope of the working group. The work produced in this Working 
> Group should work with existing IETF mobility and AAA 
> protocols, including (but not limited to) Mobile IP, SeaMoby 
> Context also welcomes participation and expression of 
> requirements from non-IETF standards organization members, 
> for instance 3GPP, 3GPP2 and ITU-T. 
> 
> Goals and Milestones:
> 
> JAN 03	Submit "Requirements for Signaling Protocols" 
> to IESG for publication as Informational RFC
> MAR 03	Submit "RSVP Security Properties" to IESG as 
> Informational RFC
> APR 03	Submit "NSIS Threats" to IESG as Informational RFC
> JUN 03	Submit "Analysis of Existing Signaling 
> Protocols" to IESG as Informational RFC
> AUG 03	Submit "Next Steps in Signaling: Framework" to 
> IESG for publication as Informational RFC
> MAR 04	Submit "NSIS Transport Protocol" to IESG for 
> publication for Proposed Standard
> MAR 04	Submit "NSIS QoS Application Protocol" to IESG 
> for publication for Proposed Standard
> _______________________________________________
> 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: Wed, 20 Nov 2002 05:04:59 +0200

Hi Robert,

> 1. I'll record my comment in the meeting that defining QoS 
> classes, parameters, service types, pre-emption capability, 
> you name it, should be a non-goal (I don't know if it needs 
> to be explicit).

OK.
 
> 2. I note that an NSLP for a midcom application is not a 
> charter goal initially (and even in the future might be an 
> activity for another w.g. anyway). However, I'd still like to 
> capture the relevance of a midcom-like application as a user 
> (of the NTLP). In particular, we should be clear that 
> discussion of it (and indeed other applications, like network 
> path monitoring as mentioned at the meeting) is 'in scope' 
> for the overall work, e.g. of the framework and security 
> documents. (Again, I don't know if this needs to be explicit.)

Actually, it is not in the charter yet because I did not get 
feedback from the ADs on this point.  I think what we should
do is indicate in the charter that there is a desire to have
an additional user of the NTLP & then we can discuss what
it should be on the list.

John

---

From: [email-masked]
Date: Wed, 20 Nov 2002 05:08:44 +0200

Hi Mike,

> I don't know about others, but the thought of
> having signaling alter forwarding decisions seems
> fairly scary. 

I agree completely.

> Treatment within the same queue
> seems fairly well understood, but having something
> outside of the well established routing protocols
> diddle with FIB's... well, let's say that the
> current crop of routing protocols were ironed
> out with much blood and sweat, and on a network
> long long ago, in a galaxy far far away.

Routing protocols should do routing.  Transport
protocols should transport.  

John

---

From: Bob Braden <[email-masked]>
Date: Thu, 21 Nov 2002 20:38:54 GMT

*> 
  *> John,
  *> 
  *> A couple of comments related to non-routing issues:
  *> 
  *> 1. I'll record my comment in the meeting that defining QoS classes, parameters, service types, pre-emption capability, you name it, should be a non-goal (I don't know if it needs to be explicit).
  *> 
  *> 2. I note that an NSLP for a midcom application is not a charter goal initially (and even in the future might be an activity for another w.g. anyway). However, I'd still like to capture the relevance of a midcom-like application as a user (of the NTLP). In particular, we should be clear that discussion of it (and indeed other applications, like network path monitoring as mentioned at the meeting) is 'in scope' for the overall work, e.g. of the framework and security documents. (Again, I don't know if this needs to be explicit.)
  *> 
  *> cheers,
  *> 
  *> robert h.
  *> 

I agree with both points.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Thu, 21 Nov 2002 20:42:27 GMT

*> 
  *> Routing protocols should do routing.  Transport
  *> protocols should transport.  
  *> 

And "signaling protocols should do signaling"? ;-)

Although I do (continue to) agree that separating routing from
signaling is the better modularity, the issues of QoS routing and
route-pinning are real and hard, and hence the interface between
them is important.

Bob Braden

  *> 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: "Hancock, Robert" <[email-masked]>
Date: Thu, 21 Nov 2002 20:20:19 -0000

Hi Mike,

Summary:
1. the wg isn't going to work on techniques for doing foo, but
2. the wg has a choice between:
 a. considering that foo happens anyway and we need to be able to work around it, or
 b. deciding that foo is not a problem in the environments the signalling will be used in.

Do we need terminology for foo?
But more importantly, what is your opinion between 2a and 2b?

Robert 

PS for those joining the conversation late, "foo" = policy-based forwarding leading to signalling/data path divergence.

> From: Michael Thomas [mailto:[email-masked]]
> Sent: 21 November 2002 13:41
> To: Hancock, Robert
> Cc: Michael Thomas; [email-masked]; [email-masked]
> Subject: RE: [NSIS] Updated Charter
> 
> 
> 
> Robert,
> 
> Can I make a general suggestion that terminology
> which describes things that the wg isn't going to
> address be elided? It's fairly easy to misconstrue
> aims when time has gone into defining something
> that could conceivably be worked on but that isn't
> charter.
> 
> Or alternatively, you can tell me to pay more
> attention.
> 
> 		Mike
> 
> Hancock, Robert writes:
>  > Hi all,
>  > 
>  > I hope that the terminology discussion has not sown more 
> confusion (assuming that's what is being referred to).
>  > 
>  > My understanding/opinion is the following:
>  > 1. there is no proposal anywhere on the table to have NSIS 
> w.g. develop something which alters the routes that packets 
> takes (either by distributing routes, fiddling with FIBs, or 
> anything else).
>  > 2. it is certainly the case that the NTLP could never do 
> this: it is simply responsible for moving signalling packets 
> around, and in many (most?) cases will simply use normal IP 
> routing to do this. (see also 
> http://www.ietf.org/mail-archive/working-groups/nsis/current/m
> sg02178.html.)
>  > 3. we can't rule out someone designing an NSLP some day 
> which carries routing information, although doing this in a 
> general sense seems not meaningful to me in the context of 
> path-coupled signalling - how do you signal to set up a path 
> in a path coupled way? (see also 
> http://www.ietf.org/mail-archive/working-groups/nsis/current/m
> sg01903.html.)
>  > 
>  > The reason for the terminology point being raised is that 
> operation of the NTLP/NSLPs may be severely affected by the 
> existence of 'policy forwarding' especially in NSIS-unaware 
> (oops! invalid terminology) parts of the network. So, we 
> wanted the term 'policy forwarding' as an unambiguous 
> shorthand for the circumstances we are worried about.
>  > 
>  > Hope this helps,
>  > 
>  > Cheers,
>  > 
>  > Robert H.
>  > 
>  > > From: Michael Thomas [mailto:[email-masked]]
>  > > Sent: 19 November 2002 17:31
>  > > To: [email-masked]
>  > > Cc: [email-masked]; [email-masked]
>  > > Subject: RE: [NSIS] Updated Charter
>  > > 
>  > > 
>  > > 
>  > > fairly scary. Treatment within the same queue
>  > > [email-masked] writes:
>  > >  > Hi Michael,
>  > >  > 
>  > >  > > So I'm somewhat confused about the earlier
>  > >  > > exchange today about whether signaling to alter
>  > >  > > the route packets take is in or out of scope, but
>  > >  > > if it's in, it seems really odd to leave such a
>  > >  > > large deliverable out of the charter. As in, I'd
>  > >  > > imagine that a lot of the routing area folks would
>  > >  > > probably be highly interested in such a thing, and
>  > >  > > it wouldn't be very obvious that it was happening
>  > >  > > here.
>  > >  > 
>  > >  > So, <chair hat off> I would prefer not to affect 
> routing - any more
>  > >  > than what RSVP currently does.  I'm not a routing expert, 
>  > > so I worry 
>  > >  > that this would be a big can of worms.  However, what does 
>  > > the WG think 
>  > >  > about this?  Do you have an opinion on what would be the 
>  > > right thing to
>  > >  > do Mike?
>  > >  > 
>  > >  > thanks,
>  > >  > John

---

From: Bob Braden <[email-masked]>
Date: Thu, 21 Nov 2002 22:10:47 GMT

John,

  *> Yes, the transport layer should be aware of some of these issues, 
  *> but we should be careful that we don't create an overlay network
  *> which we are routing the signaling messages on.  If we do, then
  *> we can very easily have divergence of the signaling path from
  *> the data path.

(... among other evils)

Mind you, maybe the Routing area should investigate whether there is
room in the global routing architecture for some form of local fixups
using some form of signaling.  I am not a routing expert so this is
only a wild idea.  But that would surely have to be founded on a firm
base of research in the routing area, and it must be totally out of
scope for NSIS.

Bob

  *> 
  *> best regards,
  *> John
  *>

---

From: [email-masked]
Date: Wed, 27 Nov 2002 15:23:31 +0200

Hi Bob,

> base of research in the routing area, and it must be totally out of

Have friends in the Routing area, or would this be a nice thing to ship
to the IRTF Routing Research Group?

John

---

From: [email-masked]
Date: Wed, 27 Nov 2002 15:14:17 +0100

Hi Bob,

Would it be correct to describe the idea you mention below as 'a signalling
protocol that allows a signalling path to locally diverge from the data
path provided both paths branch and merge in the same domain (or any region
under the same administration)'. This would in fact mend local 'funny'
routing practices.
However, another issue addressed in RFC 2998 is:
'The assumption within both IntServ and DiffServ architectures is that the
best effort routing path is used, where the path is either capable of
sustaining the service load, or not. Assuming that the deployment of
service differentiating infrastructure will be piecemeal, even if only in
the initial stages of a QoS rollout, such an assumption may be
unwarranted.'
I interpret this statement as a need to be able to separate routing
contexts for different service classes, e.g. because the normal L3 AS next
hop only delivers BE service. I am not sure if this can be provided with
only local divergence from the BE routing path.

What do you think?
Sven.

Bob Braden <[email-masked]>@ietf.org on 21/11/2002 23:10:47

Sent by:  [email-masked]

To:   [email-masked], [email-masked]
cc:   [email-masked]
Subject:  RE: [NSIS] Updated Charter

John,

(... among other evils)

Bob

  *>
  *> best regards,
  *> John
  *>

---

From: [email-masked]
Date: Wed, 27 Nov 2002 15:21:43 +0100

The reference below should be to RFC 2990.

Sorry,
Sven.

Sven VAN DEN BOSCH/BE/ALCATEL@[email-masked] on 27/11/2002 15:14:17

To:   Bob Braden <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked]
Subject:  RE: [NSIS] Updated Charter

Hi Bob,

What do you think?
Sven.

John,

(... among other evils)

Bob

  *>
  *> best regards,
  *> John
  *>