Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt

From: "Ersue, Mehmet" <[email-masked]>
Date: Tue, 26 Jun 2007 22:42:52 +0200

Hi All,

just got through the QoS NSLP specification. It is readable and
reasonably complete. I can second Roberts statement not to
put everything into one document.

Mehmet 

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Tuesday, June 26, 2007 3:59 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt
> 
> hi all,
> 
> i've read the draft. basically i think it is ready to ship.
> we could all certainly think of things to add, but I think actually
> as a core protocol it has the right balance between completeness
> and conciseness; AFAICT anything i'd like to add can be done as
> an extension (which is probably a good approach anyway).
> 
> cheers,
> 
> robert h. 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: 26 June 2007 14:26
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt
> > 
> > That's OK.  
> > 
> > Anyone else who is still reading the draft?
> > 
> > John 
> > 
> > >-----Original Message-----
> > >From: ext Roland Bless [mailto:[email-masked]]
> > >Sent: 26 June, 2007 05:42
> > >To: Martin Stiemerling
> > >Cc: nsis
> > >Subject: Re: [NSIS] WGLC:draft-ietf-nsis-qos-nslp-14.txt
> > >
> > >Hi,
> > >
> > >Martin Stiemerling wrote:
> > >> [writing chair's hat off]
> > >> I have read the draft and think it is ready to take the 
> next steps.
> > >
> > >I'm still reading the draft completely and will provide 
> > comments ASAP 
> > >(scheduled for tomorrow). Sorry for not being able to make 
> it in the 
> > >WGLC time frame...
> > >
> > >Regards,
> > > Roland
> > >
> > >
> > >_______________________________________________
> > >nsis mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/nsis
> > >
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> _______________________________________________
> 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: Roland Bless <[email-masked]>
Date: Tue, 03 Jul 2007 11:30:29 +0200

Hi all,

Martin Stiemerling wrote:
> Just to remind you about the currently running WGLC for the QoS NSLP.
> A simple mail saying that the draft is ready for publication would be great.

I reread the whole draft (sorry for being late, but several other
activities interrupted me) and have some minor comments only.
So I would say that's it's ready for IESG review after the next
update.

The most important things first:
===================================================================
* Section 4.3: Refreshing receiver-initiated reservations...
  "are set up.  The reservation can subsequently be refreshed with
   RESERVE messages in the same way as for the sender-initiated
   approach."
   Is a little bit to vague for me. Are the refreshing RESERVE messages
   now sent downstream? I guess so because otherwise re-routing
   detection would not work. So it should be made clear that the
   RESERVE messages are only sent in reverse direction for the initial
   state installation, but that the refreshing RESERVE messages are
   sent as usually in flow direction.

* Section 4.5: there seem to be remnants stacking concept
  which was removed:

     RESERVE message to be sent out is constructed mostly as usual but
   with a second QSPEC object added on top, which becomes the 'current'
   one.

as well as

   A message can contain at most two QSPEC objects, i.e., the end-to-end
   QSPEC and a local QSPEC.

   Probably this could replaced by something like:
   The local QoS model (QoSM2) can define its own local QSPEC that
   also contains the original QSPEC from QoSM1.

* Section 5.1.2.1 RESERVE
  Q-Flag:

     REQUEST REDUCED REFRESHES (Q) - when set, indicates the sender of
     the RESERVE proposes to use the reduced refresh for this session.

  I really don't know what this should be good for (or maybe I forgot).
  IMHO this is not necessary, because the QNE can simply try to sent
  a reduced refresh. If this cannot be supported by the peer, it will
  answer with
   * 0x03 - Reduced refreshes not supported, full QSPEC required.
  In this case the QNE should continue to always send full refreshes to
  this peer.
  I also don't see any description in the draft of what should happen
  according to this bit.
  So I don't think that the flag is useful and I am in favor of removing
  it.

* TEARing RESERVE in which direction and REPLACE flag.
  As far as I understood, it should be possible for a node
  to remove reservations at the old branch explicitly. This
  is at least what I read from 5.1.4:

   The default behavior of a QNE that receives a RESERVE with a
   SESSION_ID for which it already has state installed but with a
   different flow ID is to replace the existing reservation (and tear
   down the reservation on the old branch if the RESERVE is received
   with a different SII).

   I'm a little bit confused which node will tear down the
   reservation on the old branch. Sometimes we have a node where
   the routes diverge and sometimes we have a node where route
   converge and sometimes we have both. In the above description:
   if a QNE receives a RESERVE with a different
   SII it's obviously a node where routes converge again.
   Otherwise it would be a QNE sending a RESERVE along a
   new SII (this would be indicated by GIST).

   So a more concrete example:
              +-+
           /--|B|--\
          /   +-+   \
       +-+           +-+
   ----|A|           |D|----
       +-+           +-+
          \   +-+   /
           \--|C|--/
              +-+

Let's assume that the MRI is unchanged.
Flow is A->B->D at first. After re-routing happens
the new route is A->C->D. It would make sense that
node A will try to remove the old branch, so it
may send a RESERVE w/ TEAR along the old path.
D will not forward the tearing RESERVE, because
it knows, that the TEAR came along the old branch.

But would it be also possible for node D to send
a tearing reserve in the reverse direction (upstream)?
This is current not allowed by 5.1.4:
   "RESERVE messages MUST only be sent towards the QNR."
The signaling mobility draft has an example where
node D sends a tearing reserve in reverse direction.
The situation there is different since there is no branching
A; it can be considered as the MN moving between ARs B and C.
In this case only D can send the tearing RESERVE.
So if it is allowed for D to send a tearing RESERVE,
how would it be coordinated with the branching node A?

==============================================
Now the minor stuff:
* Introduction:
  e.g., edge-to-edge, end-to-access, etc.  On the other hand, there is
  no support for IP multicast.

The GIST draft mentions that multicast support may be added later and
I'll like to see something similar in here. Probably adding the word
"currently" is enough: there is currently no support for IP multicast.

* p. 12: All QSPECs must follow the QSPEC template
   [I-D.ietf-nsis-qspec].
  I'm not sure whether a must is too strong here.
  Local QSPECs may be different from the e2e-QSPEC.
  Probably this one is better:
  All QSPECs should follow the design of the
  QSPEC template.

* p. 13: change
  "may cause removal of an earlier reservation."
  into
  "may cause removal of an earlier admitted reservation."
  (or "established" if you like).

* p. 26: 3.3.5

   this difference can set the "B" (BREAK) flag.

What means can here? better use may or should?

* P. 37: Sec. 4.7
  - probably we need to mention that retransmissions
    can only be expected if an RII was set.
  - it's not clear that it's better to use a
    MsgIDWait timeout longer than the retransmission
    timer. We may change that.

* p.39: Sec 4.8.1
  It should be mentioned that the message binding
  can be used to synchronize the messages.

* p. 45: 5.1.2.1
   A "reservation collision" may occur if the sender believes that a
  It is not clear to me how such a collision would occur. What would
  be the reason for such a collision. Could you give an example?

* p. 46: 5.1.2.1
  resulting refresh is a new RESERVE.  This RESERVE includes a new MRI
   and will be propagated end-to-end without requesting a RESPONSE.

  It is meant that "will be propagated end-to-end _even_ without
  requesting a RESPONSE." But additionally it may also include an RII,
  so I would suggest to rephrase it as it may sound that an RII
  must not be included.
* p. 5.1.3.7/5.1.3.8:
  As I got feedback from our implementer: it would be easier to
  parse if we had also a combined list of SID/RSN tuples.

==============================================
Typos:
p.12: missing closing parenthesis:
 flag in the common header).
                          ^
 additional blank line (as in several places in the doc, please check):
  requested will usually contain objects which need to be understood by

  all implementations, and it can also be enhanced with additional

p.13: period missing or incomplete sentence?
      "Authentication may be required."
   The authorization of a resource request often depends on the identity
   of the entity making the request.  Authentication may be required The

p.22: 3.2.12.1
   "D. The signaling path initially ends at C, but this node is not on"
must be change to:
   "D. The signaling path initially ends at B, but this node is not on"
p.23: 3.2.12.2
  "its API to the NSLP with a NetworkNotification.  The QoS NSLP at A
   will then attempt to repair the path by installing the reservation on
   the path'."

There is no path' defined. Probably better use: installing the
reservation on path (2),(3).

p.24: Typo:
   This in the peer from which it was receiving RESERVE messages.
s/in /is /

p.27:
   [I-D.ietf-nsis-qspec].  For example, in a RMD-QOSM
 s/a /an /

p. 29:
   "to GIST to be forwarded back down the path."
back down may be confusing, because the direction is upstream.

p. 29: s/prepated/prepared

P. 36: Sec 4.7
       Wrong reference to Figure 15 (two times)
       should be 14.

p. 43: s/P -QNE/P-QNE
p. 44: s/mesasages/messages
p. 54: insert a CRLF before "o Protocol Error"
p. 57: Object Value Info format is messed up.
p. 79: s/decice/decide

------------------------------------------------------------------
Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 23 Jul 2007 19:46:48 +0300 (EEST)

Hi,

A couple of comments to your most important things from me and Georgios. 
Thanks for the review.

See below.

Jukka

> The most important things first:

No, the text is misleading. The refreshes are also sent in the same 
direction as the initial RESERVE. I'll fix the text to be more specific.

>    also contains the original QSPEC from QoSM1.

Yes, my bad. Will fix.

>   So I don't think that the flag is useful and I am in favor of removing

Yes, again. Good point. THis is not needed anymore. Will remove.

> how would it be coordinated with the branching node A?

This works in the same way as in the mobility case. Node D sends a NOTIFY 
on the old path, saying "Route Change Happened". This will be eventually 
forwarded to A, which obviously knows that the route changed, and can tear 
down explicitly the old branch. Node D will in its turn get the tear, and 
stop the tearing process there.

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 24 Jul 2007 00:13:03 +0300 (EEST)

A follow-up to Roland's first comment, in the case where the route 
changes. See below.

Roland and I had a chat about what happens, if the route changes during a 
receiver-initiated reservation? In the sender-initiated it is quite clear, 
just send a full refresh on the new path.

Using Roland's previous picture:

                   +-+
                /--|B|--\
 QNR           /   +-+   \          QNI
+------+     +-+           +-+    +------+
| Data |-----|A|           |D|----| Data |
|sender|     +-+           +-+    | recv |
++++++++       \   +-+   /        +------+
                \--|C|--/
                   +-+

* Data is flowing through A-B-D. 
* QUERY is sent through A-B-D.
* RESERVE and refresh RESERVE and sent through D-B-A.

After a route change through C with the receiver-initiated case, D is 
sending a refresh to B, while data is coming through C. Now, A is in a key 
position here. It should get from GIST a network notification saying that 
routing has changed. A can then send a QUERY through C, which then sends a 
QUERY to D. Now D will notice that the next hop for the given MRI has 
changed, and can send subsequent refreshes through C.

Is this description correct? If so, then for the R-I reservations, nodes 
should store enough information to enable them to send QUERY messages in 
the middle of a session, after a routing change.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Tue, 24 Jul 2007 22:12:50 +0200

Hi Jukka, and all

> On Tue, 3 Jul 2007, Roland Bless wrote:

This would make the handling of route changes easier, but the problem
is that the RESERVE is flowing into the "wrong" direction. So in order
to retain the differences of receiver-initiated reservations and
sender-initiated reservations we should try to send RESERVE only in the
same direction.

> Using Roland's previous picture:

At latest GIST probing will discover a new next peer for this
data flow. This will initiate the notification about the route change
at A. The problem is that only the GIST peering is renewed, so as long
as there is no NSLP message flowing, signaling stops at C. The correct
way of handling this would indeed be letting A sending an end-to-end
QUERY for receiver-initiated reservation. This will then be routed to
C. C will route the QUERY to D and thereby establish a new GIST peering
between C and D.

> changed, and can send subsequent refreshes through C.

Actually it shouldn't be a refresh, because resources must be reserved
anew. D should directly send a new RESERVE upstream to C (if it would
only try to send a refreshing RESERVE to C, it would get an error back
that a full QSPEC is required). The interesting question is now whether
the forwarding of the QUERY should stop at D.

> Is this description correct? If so, then for the R-I reservations, nodes 

I guess that it boils down to two things:
1) requiring that a node, which has a receiver-initiated reservation,
   sends a QUERY after detecting a downstream route change. This is
   necessary, because the route change must be propagated up to the
   node where the routes converge again and GIST cannot really route
   upstream (except for probably limited cases).
2) letting a node initiating a RESERVE upstream as soon as it
   detects an upstream route change (in this case we hopefully
   have a complete signaling path upstream). This is required
   in order to try to install the resource reservation along the
   new path.

> the middle of a session, after a routing change.

This shouldn't be a problem IMHO unless the node is stateless...
On the other hand a NULL Query is probably sufficient, because
node D must issue a RESERVE with a full QSPEC anyway.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 24 Jul 2007 23:37:09 +0300 (EEST)

Hi,

based on our discussion a minute ago, the proposal below works with a 
small update: the node D must wait for the NSLP QUERY to arrive before 
sending the full RESERVE, in order to make sure the upstream (reverse) 
path is properly set up - so a network notification is not yet enough for 
sending the RESERVE.

Jukka