Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt

From: [email-masked]
Date: Mon, 15 Jul 2002 04:38:31 +0300

Hi Robert & Marcus,

Could you summize and condense the below into a reasonable 
proposal?  I think there are some obvious views which
NSIS will not be consider.

thanks,
John

> -----Original Message-----
> From: ext Hancock, Robert [mailto:[email-masked]]
> Sent: 11 July, 2002 20:45
> To: [email-masked]'; Loughney John (NRC/Helsinki);
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt
> 
> 
> hi marcus,
> 
> i've added a few refinements. we get up to 8 questions in all.
> 
> some answers may be obvious to some people, but I don't think 
> any are obvious  to everyone.
> 
> robert h.
> 
> > -----Original Message-----
> > From: Marcus Brunner [mailto:[email-masked]]
> > Sent: 11 July 2002 15:02
> > To: [email-masked]; Hancock, Robert;
> > [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt
> > 
> > 
> > 
> > >> [Note: such a section could also define just what the on-path
> > >> restriction actually was. I've seen at least 4 different
> > >> incompatible views on that.]
> > >
> > > Want to provide a summary of the 4 views?
> > 
> > Ok, I give it a try
> > 
> > 1) exclusive on path
> > The NSIS initiator and NSIS receiver are the data receiver 
> and sender
> > 
> > 2) proxy on path
> > The NSIS initiator is some where on the data path but not at 
> > the sending 
> > nor receiving side (only part of the data path is covered by 
> > signaling)
> > 
> > 3) IP-hop-by-IP-hop
> > The signaling message travels IP-hop-by-IP-hop. Where the 
> > hops are chosen 
> > by  the destination addr
> 3a) The signaling message travels IP-hop-by-IP-hop, but the 
> hop can be chosen on any fields in the IP header (of data 
> packet) or flow definition (in NSIS aware router), e.g. DSCP 
> and so on. Can be used to handle some load sharing/traffic 
> engineering issues, but not across NSIS-unaware clouds.
> 
> > 
> > 4) NSIS-hop-by-NSIS-hop
> > The signaling message follows NSIS hops, where intermediate 
> > IP hops are not 
> > visited. The NSIS hop has to choose the next hop, here the 
> > data path migh 
> > follow a different path for a shsort segment.
> [to clarify?] the ends of the NSIS hop are on the data path, 
> but the middle may not be. the message is explicitly 
> addressed to the next NSIS hop.
> 
> > 
> > 5) in advance reservation in hand-over cases
> > If a new access router has been chosen, where a mobile will 
> > newly connect 
> > to and a reservation should be done in advance, the data 
> > flows still on the 
> > old path. At the point in time data is flowing along the new 
> > path (after 
> > handoff) the reservation has already been setup.
> 
> 6) i've seen some claim that if a node sets up a tunnel 
> (obviously with a known endpoint) and then signals for the 
> tunnel, and also sends data and signalling through the 
> tunnel, this is 'morally equivalent' to off-path, in the 
> sense that you're no longer relying on the routing system to 
> recover from any non-end-system failures.
> 
> 7) even if some messages are sent traditionally on-path as 
> per (3) [like RSVP PATH], are other messages allowed to go 
> off path and not be routed NSIS-hop by NSIS-hop [e.g. 
> acknowledgements, error notifications]? or should everything 
> go on-path?
> 
> > 
> > Marcus
> > --------------------------------------
> > 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.
> 

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

---

From: Bob Braden <[email-masked]>
Date: Mon, 15 Jul 2002 17:46:11 -0700 (PDT)

> > > The NSIS initiator and NSIS receiver are the data receiver 

The implication here is that signaling may follow any path
as long as it ends on the data receiver node?  This could be
used when the signaling is strictly E2E, e.g., setting up
a tunnel, with no intermediate NSIS nodes.  But then it is
simply a degenerate case of (4), isn't it?
 
> > > nor receiving side (only part of the data path is covered by 

I believe this is simply a case of where the signaling End points
(what is being called Initiator and Terminator) are located.
Whether it is an ES or a proxy should make no difference, and
therefore (2) is not a distinct off path/on path case.

> > > The signaling message travels IP-hop-by-IP-hop. Where the 

Well, by the destination address or whatever fields are being
used to route the data.  (I think RFC2205 was explicit about
this, but it is an issue that kept coming up.)  WHATEVER routing
is done on the data, has to also be done on the signaling, in
this case (If I understand your meaning.)

> > addressed to the next NSIS hop.
A non-NSIS hop presumably is not setting up any state in that
node, so I would say that (4) is not really different from (3).
They are both what I called "path-directed" signaling.

> > > handoff) the reservation has already been setup.

This is a special case that probably has to be handled for the
mobile case, but it would not by itself violate the general
principle of on-path signaling.
 
> > acknowledgements, error notifications]? or should everything 

Again, a detail that does not violate the principle of
path-directed signaling.

Bob Braden