Subject: Comments on draft-ietf-rsvp-refresh-reduct-00.txt, section 4

From: [email-masked]
Date: Sun, 17 Oct 1999 13:29:29 -0700

*> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 16]
  *> 

Lou et al,

Here are detailed comments on section 4.  First, here are some overall
issues I see:

	1. It would help clarity and be more consistent to revamp the
	   class numbers and ctypes as I suggested in a separate message.

	2. You might be able to increase clarity by introducing a term like
	   "refresh-by-identifier", abbreviated to "RBI" (very topical!).

	3. In general, I think your draft over-uses capitalized MUST/MAY/
	  SHOULD, etc.  I suggest that you un-capitalize all MAY/MUST/SHOULD
	  words in the document, and then go through and look carefully
	  for those (probably few) places where a Applicability word is
	  really appropriate.

	("When you send me email, you MUST begin with "braden", which
	MUST be followed by and "@" sign, and then "isi.edu" MUST
	follow", vs. "My email address is [email-masked]".)

	4. I wonder whether you have thought about using Path & Resv
	 messages instead of SRefresh messages?  This might simplify
	 and clarify processing, and resolve at least one issue I saw
	 where you wanted to know that an instance of RBI was associated
	 with Path state.

Bob

  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *> 4. Summary Refresh Extension
  *> 
  *>    The Summary Refresh extension enables the refreshing of RSVP state
  *>    without the transmission of standard Path or Resv messages.  The ben-

(Kill the hyphenation)

  *>    efits of the described extension are that it reduces the amount of
  *>    information that must be transmitted and processed in order to main-
  *>    tain RSVP state synchronization.  Importantly, the described exten-
  *>    sion preserves RSVP's ability to handle non-RSVP next hops and to
  *>    adjust to changes in routing.  This extension cannot be used with
  *>    Path or Resv messages that contain any change from previously trans-
  *>    mitted messages, i.e, are not refresh messages.
                              are trigger messages.

  *> 
  *>    The summary refresh extension uses the previously defined MESSAGE_ID
  *>    object class, the ACK message, and a new Srefresh message.  The new
  *>    message carries a list of Message_ID fields corresponding to the Path
  *>    and Resv states that are to be refreshed.  The Message_ID fields are
                 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
                 trigger messages that established the state.

  *>    carried in one of three Srefresh related MESSAGE_ID class objects.

Somewhere it should say that the Message_ID value becomes part of the
stored state and uniquely identifies that state.

Move the following details to 4.1; confusing here.  Then maybe use bullets.

  *>    The three Srefresh related MESSAGE_ID class objects are the MES-
  *>    SAGE_ID LIST object, the MESSAGE_ID SRC_LIST object, and the MES-
  *>    SAGE_ID MCAST_LIST object.  The MESSAGE_ID LIST object is made up of
  *>    a list of Message_ID fields that were originally advertised in MES-
  *>    SAGE_ID objects that shared a common Epoch value.  The MESSAGE_ID
  *>    SRC_LIST object is used for multicast sessions over multi-access net-
  *>    works and adds the sender's IP address.  The MESSAGE_ID MCAST_LIST
  *>    object is used for multicast sessions over point-to-point links and
  *>    adds the sender's IP address and the Session IP address.

Lost me...  SRC_LIST objects are to use for multicast sessions, as
opposed to MCAST_LIST objects which are used for (different) multicast
sessions... ? Confusion alarm!

  *> 
  *>    An RSVP node receiving an Srefresh message, matches each received
  *>    listed Message_ID field with installed Path or Resv state.  All
  *>    matching state is updated as if a normal RSVP refresh message has
  *>    been received.  If matching state cannot be found, then the Srefresh
  *>    message sender is notified via a refresh NACK.
  *> 
  *>    A refresh NACK is indicated by setting the Refresh_NACK flag in the
  *>    MESSAGE_ID ACK object.  The rules for sending a MESSAGE_ID ACK object
  *>    with the Refresh_NACK flag set are the same as was described in the
  *>    previous section.  This includes sending MESSAGE_ID ACK object both
                                                                       either

  *>    piggy-backed in unrelated RSVP messages or in RSVP ACK messages.
  *> 
  *>    Nodes supporting the described extension can advertise their support
  *>    and detect if an RSVP neighbor also supports the extension.  This is
  *>    accomplished via a flag in the MESSAGE_ID and MESSAGE_ID ACK objects.

Again, I think it would be cleaner to put this bit in the Common Header.
If you are going to put it in these objects, you have to give the
explicit rules for resolving inconsistencies.

  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 17]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *> 4.1. MESSAGE_ID LIST, SRC_LIST and MCAST_LIST Objects
  *> 
  *> 
  *>    The MESSAGE_ID LIST, MESSAGE_ID SRC_LIST and MESSAGE_ID MCAST_LIST
  *>    objects are part of the MESSAGE_ID class.  See Section 3.1 for class
  *>    value.

All CTypes of the same object should certainly be defined in the same
place!  That means either moving all these specific definitions to
an appendix, like 2205 does, or following my suggestion of using a
distinct class for these objects.

  *> 
  *>    MESSAGE_ID LIST object
  *> 
  *>       Class = MESSAGE_ID Class, C_Type = 3
  *> 
  *>        0                   1                   2                   3
  *>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |     Flags     |                      Epoch                    |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID                         |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                                 :                             |
  *>       //                                :                            //
  *>       |                                 :                             |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID                         |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *>       Flags: 8 bits
  *> 
  *>          No flags are currently defined.  This field MUST be zero on
  *>          transmission and ignored on receipt.
  *> 
  *>       Epoch: 24 bits
  *> 
  *>          The Epoch field from the MESSAGE_ID object corresponding to the
  *>          state being refreshed.
  *> 
  *>       Message_ID: 32 bits
  *> 
  *>          The Message_ID field from the MESSAGE_ID object corresponding
  *>          to the state being refreshed.  A variable number of Message_IDs

This is picky, but a message id corresponds to a message, ie, the
represenation of an atom of state.  Since we have never really carefully
defined the latter, RSVP "state" is really just a collective abstraction.
So I think you want to phrase it in terms of (trigger) messages.

  *>          may be included.  The number may range from one up to as many
  *>          as can be carried without the Srefresh Message exceeding the
  *>          MTU.
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 18]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    MESSAGE_ID SRC_LIST object
  *> 
  *>       Class = MESSAGE_ID Class, C_Type = 4
  *> 
  *>        0                   1                   2                   3
  *>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |     Flags     |                      Epoch                    |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                              Source_                          |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                          Message_ID_Tuple                     |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Confusing picture; I did not understand at first that the two labels
in the lines above were meant to be concatenated!

  *>       |                                 :                             |
  *>       //                                :                            //
  *>       |                                 :                             |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                              Source_                          |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                          Message_ID_Tuple                     |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *>    Where a Source_Message_ID_Tuple consists of:
  *> 
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID                         |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                         Source_IP_Address                     |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *>       Flags: 8 bits
  *> 
  *>          No flags are currently defined.  This field MUST be zero on
  *>          transmission and ignored on receipt.
  *> 
  *>       Epoch: 24 bits
  *> 
  *>          The Epoch field from the MESSAGE_ID object corresponding to the
  *>          state being refreshed.
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 19]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>       Message_ID: 32 bits
  *> 
  *>          The Message_ID field from the MESSAGE_ID object corresponding
  *>          to the Path state being refreshed.  A variable number of Mes-
  *>          sage_IDs may be included.  The number may range from one up to
  *>          as many as can be carried without the Srefresh Message exceed-
  *>          ing the MTU.  Each Message_ID MUST be followed by the source IP
  *>          address corresponding to the sender of the Path state being
  *>          refreshed.
  *> 
  *>       Source_IP_Address: 32 bits
  *> 
  *>          The source IP address corresponding to the sender of the Path
  *>          state being refreshed.

Source IP address?  Do you mean sender IP address, or the source of
the trigger message and hence the source associated with the Message id?
May need some careful word smithing earlier in the document.  Also, it
seems important to be carefully consistent with the terminology of 2205
Appendix A here.

  *> 
  *>    MESSAGE_ID MCAST_LIST object
  *> 
  *>       Class = MESSAGE_ID Class, C_Type = 5
  *> 
  *>        0                   1                   2                   3
  *>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |     Flags     |                      Epoch                    |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                             Multicast_                        |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID_                        |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                               Tuple                           |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                                 :                             |
  *>       //                                :                            //
  *>       |                                 :                             |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                             Multicast_                        |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID_                        |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                               Tuple                           |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 
  *> 
  *> 

Same confusion as above.

  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 20]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    Where a Multicast_Message_ID_Tuple consists of:
  *> 
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                            Message_ID                         |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                         Source_IP_Address                     |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *>       |                      Destination_IP_Address                   |
  *>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  *> 

(Note that here you DON'T want the labels concatenated...)

  *>       Flags: 8 bits
  *> 
  *>          No flags are currently defined.  This field MUST be zero on
  *>          transmission and ignored on receipt.
  *> 
  *>       Epoch: 24 bits
  *> 
  *>          The Epoch field from the MESSAGE_ID object corresponding to the
  *>          state being refreshed.
  *> 
  *>       Message_ID: 32 bits
  *> 
  *>          The Message_ID field from the MESSAGE_ID object corresponding
  *>          to the Path state being refreshed.  A variable number of Mes-
  *>          sage_IDs may be included.  The number may range from one up to
  *>          as many as can be carried without the Srefresh Message exceed-
  *>          ing the MTU.  Each Message_ID MUST be followed by the source IP
  *>          address corresponding to the sender of the Path state being
  *>          refreshed, and the destination IP address of the session.
  *> 
  *>       Source_IP_Address: 32 bits
  *> 
  *>          The source IP address corresponding to the sender of the Path
  *>          state being refreshed.

Again, if you mean the sender IP address, you should simply say so.

  *> 
  *>       Destination_IP_Address: 32 bits
  *> 
  *>          The destination IP address corresponding to the session of the
  *>          Path state being refreshed.
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 21]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *> 4.2. Srefresh Message Format
                           ??????

  *> 
  *>    Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
  *>    SRC_LIST, and MESSAGE_ID MCAST_LIST objects.  MESSAGE_ID LIST and
  *>    MESSAGE_ID MCAST_LIST objects MAY be carried in the same Srefresh
  *>    message.  MESSAGE_ID SRC_LIST can not be combined in Srefresh mes-
  *>    sages with the other objects.  A single Srefresh message MAY refresh
  *>    both Path or Resv state.
                  and

Are SRC_LIST and MCAST_LIST objects are used only for Path message refresh?

  *> 
  *>    Srefresh messages carrying Message_ID fields corresponding to Path
  *>    state SHOULD be sent with a destination IP address equal to the
              ?????? should??

  *>    address carried in the corresponding SESSION objects.  The destina-
  *>    tion IP address MAY be set to the RSVP next hop when the next hop is
  *>    known to be RSVP capable and either (a) the session is unicast or (b)
  *>    the outgoing interface is a point-to-point link.  Srefresh messages
  *>    carrying Message_ID fields corresponding to Resv state MUST be sent
  *>    with an destination IP address set to the Resv state's previous hop.
  *> 
  *>    Srefresh messages sent to a multicast destination, MUST contain MES-
  *>    SAGE_ID SRC_LIST objects and MUST NOT include any MESSAGE_ID LIST or
  *>    MESSAGE_ID MCAST_LIST objects.  Srefresh messages sent to the RSVP
  *>    next hop MAY contain either or both MESSAGE_ID LIST and MESSAGE_ID
  *>    MCAST_LIST objects, but MUST NOT include any MESSAGE_ID SRC_LIST
  *>    objects.

!!??

  *> 
  *>    The source IP address of an Srefresh message is an address of the
  *>    node that generates the message.  The source IP address MUST match
  *>    the addressed associate with the MESSAGE_ID objects when they were
  *>    included in a standard RSVP message.  As previously mentioned, the
  *>    address associate with a MESSAGE_ID object is represented in a per
       \ source

  *>    RSVP message type specific fashion.  For Path and PathTear messages
  *>    the associated IP address is contained in the RSVP_HOP.  For Resv,
  *>    ResvTear, PathErr, ResvErr, ResvConf and Bundle messages the associ-
  *>    ated IP address is the source address in the IP header.

For Resv and ResvTear, why not the RSVP_HOP?

You want a rule here, not an explicit (and necessarily partial) list of
message types.

  *> 
  *>    Srefresh messages that are sent destined to a session's destination
  *>    IP address MUST be sent the Router Alert IP option in their IP head-
  *>    ers.  Srefresh messages addressed directly to RSVP neighbors SHOULD
  *>    NOT be sent with the Router Alert IP option in their IP headers.

I don't know the last should matter...

  *> 
  *>    Each Srefresh message MUST occupy exactly one IP datagram.  If it
  *>    exceeds the MTU, the datagram is fragmented by IP and reassembled at
  *>    the recipient node.  A single RSVP Srefresh message MUST NOT exceed
  *>    the maximum IP datagram size, which is approximately 64K bytes.  Sre-
  *>    fresh messages MAY be sent within an RSVP aggregate messages.
                                                  xxxxxxxxxxxxxxxxxx
                                                  Bundle message.

  *>    Although this is not expected since Srefresh messages can carry a
  *>    list of Message_ID fields within a single object.

Recommended size?

  *> 
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 22]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    The Srefresh message format is as follows:
  *> 
  *>    <Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
  *>                     <unicast message_id list> <multicast message_id list> |
  *>                     <source message_id list>
  *> 
  *>    <unicast message_id list>   ::= [ <MESSAGE_ID LIST> ... ]
  *> 
  *>    <multicast message_id list> ::= [ <MESSAGE_ID MCAST_LIST> ... ]
  *> 
  *>    <source message_id list>    ::= <MESSAGE_ID SRC_LIST>
  *>                                    [ <MESSAGE_ID SRC_LIST> ... ]
  *> 
  *>    For Srefresh messages, the Msg Type field of the Common Header MUST
  *>    be set to 14 (Value to be assigned by IANA).
  *> 

Why have lists of lists, instead of just lists?  I may be missing
something, but it seems you could have max one of each the ...LIST
objects.

Should say something about ordering.  In particular, I see no harm
in arbitrary interleaving of the 3 CTYpes (which would result in
simpler BNF)

  *> 
  *> 4.3. Srefresh Message Usage
  *> 
  *>    An Srefresh message MAY be generated to refresh Resv or Path state.

Gratuitous MAY.  Did you mean AND, BTW?

  *>    If an Srefresh message is used to refresh some particular state, then
  *>    the generation of a standard refresh message SHOULD be suppressed.  A
  *>    state's refresh interval is not affected by the use of Srefresh mes-
  *>    sage based refreshes.  An Srefresh message MUST NOT be used in place
  *>    of a trigger Path or Resv message, i.e., one that would advertise a
  *>    state change.
  *> 
  *>    When generating an Srefresh message, a node SHOULD refresh as much

Questionable SHOULD, though maybe that depends upon what is "possible".

  *>    Path and Resv state as is possible by including the information from
  *>    as many MESSAGE_ID objects in the same Srefresh message.  Only the
  *>    information from MESSAGE_ID objects that meet the previously
  *>    described source and destination IP address restrictions may be

?Which destination IP address restriction was that?

  *>    included in the same Srefresh message.  Identifying Resv state that
  *>    can refreshed using the same Srefresh message is fairly straightfor-
                                                         xxxxxx

  *>    ward.  Identifying which Path state may be included is a little more
  *>    complex.
  *> 
  *>    Independent of the state being refreshed, only state that was previ-
  *>    ously advertised in Path and Resv messages containing MESSAGE_ID
  *>    objects can be refreshed via an Srefresh message.

This sentence should come much earlier

  *>    Srefresh message
  *>    based refreshes must preserve the state synchronization properties of
  *>    Path or Resv message based refreshes.  Specifically, the use of Sre-
  *>    fresh messages MUST NOT result in state being timed-out at the RSVP
  *>    next hop.  The period at which state is refreshed when using Srefresh
  *>    messages MAY be shorter than the period that would be used when using
  *>    Path or Resv message based refreshes, but it MUST NOT be longer.  The

This has not quite captured what you want to say.  A trigger message
carries some refresh period R (in a TimeValues object), and subsequent
refreshes for that message must be sent periodically with an
interval of R or smaller.  This is true whether refreshing is performed
by an explicit refresh message or by a Message_ID in an Srefresh message.

But this brings up a technical issue.  Maybe an SRefresh message should
be able to carry a new TIME_VALUES object, to update the R values of
all refreshed state? (Con: the originator wants to change R,
it can of course send new trigger messages)

  *>    particular approach used to trigger Srefresh message based refreshes
  *>    is implementation specific.  Some possibilities are triggering
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 23]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    Srefresh message generation based on each state's refresh period or,
  *>    on a per interface basis, periodically generating Srefresh messages
  *>    to refresh all state that has not been refreshed within the state's
  *>    refresh interval.  Other approaches are also possible.

I would omit these implementation details; they do not add to the
clarity of the protocol, and they are likely to be simplistic for many
implementations.

  *> 
  *>    When generating an Srefresh message, there are two methods for iden-
  *>    tifying which Path state may be refreshed in a specific message.  In
  *>    both cases, the previously mentioned refresh interval and source IP
  *>    address restrictions must be followed.  The primary method is to
  *>    include only those sessions that share the same destination IP
  *>    address in the same Srefresh message.  When using this method, the
  *>    destination address of each session MUST be the same as the destina-
  *>    tion address in the IP header of the Srefresh message.

? I don't follow the difference between the last two sentences.

  *> 
  *>    The secondary method for identifying which Path state may be
  *>    refreshed within a single Srefresh message is an optimization.  This
  *>    method MAY be used when the next hop is known to support RSVP and
  *>    when either (a) the session is unicast or (b) the outgoing interface
  *>    is a point-to-point link.  This method MUST NOT be used when the next
  *>    hop is not known to support RSVP or when the outgoing interface is to
  *>    a multi-access network and the session is to a multicast address.

Last sentence is logical complement of previous sentence; I suggest you omit it.

  *>    When using this method, the destination address in the IP header of
  *>    the Srefresh message is always the next hop's address.  When the out-
  *>    going interface is a point-to-point link, all Path state associated
  *>    with sessions advertised out the interface SHOULD be included in the
  *>    same Srefresh message.  When the outgoing interface is not a point-
  *>    to-point link, all unicast session Path state SHOULD be included in
  *>    the same Srefresh message.

I am not sure that I agree with that SHOULD.

  *> 
  *>    Identifying which Resv state may be refreshed within a single Sre-
  *>    fresh message is based simply on the source and destination IP
  *>    addresses.  Any state that was previously advertised in Resv messages
  *>    with the same IP addresses as an Srefresh message MAY be included.
  *> 
  *>    After identifying the Path and Resv state that can be included in a
  *>    particular Srefresh message, the message generator adds to the mes-
  *>    sage MESSAGE_ID information matching each identified state's previ-
  *>    ously used object.  For all Resv state and for Path state of unicast
  *>    sessions, the information is added to the message in an MESSAGE_ID
  *>    LIST object that has a matching Epoch value.  If no matching object
  *>    exists, then a new MESSAGE_ID LIST object is created.  Path state of
  *>    multicast sessions may be added to the same message when the destina-
  *>    tion address of the Srefresh message is the RSVP next hop.  In this
  *>    case the information is added to the message in an MESSAGE_ID
  *>    MCAST_LIST object that has a matching Epoch value.  If no matching
  *>    object exists, then a new MESSAGE_ID MCAST_LIST object is created.
  *>    When the destination address of the message is a multicast address,
  *>    then identified information is added to the message in an MESSAGE_ID
  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 24]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    SRC_LIST object that has a matching Epoch value.  If no matching
  *>    object exists, then a new MESSAGE_ID SRC_LIST object is created.
  *>    Once the Srefresh message is composed, the message generator trans-
  *>    mits the message out the proper interface.
  *> 
  *>    Upon receiving an Srefresh message, a receiver MUST attempt to iden-
  *>    tify matching Path or Resv state.  Matching is done based on the
  *>    source address in the IP header of the Srefresh message and each MES-
  *>    SAGE_ID class object contained in the message.  For each received
  *>    Message_ID field, the receiver performs an installed state lookup
  *>    based on the received value and the received object type.  If match-
  *>    ing state can be found, then the receiver MUST update the matching
                                                       refresh

  *>    state information as if a standard refresh had been received.
                                                  \message

  *>    If the
  *>    receiver cannot identify any installed state matching a Message_ID
  *>    field associated with Resv state or Path state of unicast session,
  *>    i.e. carried in a MESSAGE_ID LIST Object, then an Srefresh NACK MUST
  *>    be generated corresponding to each unmatched Message_ID field in a
  *>    MESSAGE_ID LIST object.  For unmatched Message_ID fields associated
  *>    with Path state of multicast sessions, an RPF check must be performed

Whoa.  How does it know the unmatched MessageID is associated with Path state?

  *>    in order to determine if a NACK should be generated.  The RPF check
  *>    is performed based on the source and group information carried in the
  *>    MESSAGE_ID SRC_LIST and MCAST_LIST objects.  The receiver only gener-

SRC_LIST does not contain group information.

This use of "receiver" conflicts with 2205, I think.

  *>    ates an Srefresh NACK when the receiver would forward packets to the
  *>    identified group from the listed sender.  If the receiver would for-
  *>    ward multicast data packets from a listed sender and there is a cor-
  *>    responding unmatched Message_ID field, then an appropriate Srefresh
  *>    NACK MUST be generated.  If the receiver is not forwarding packets to
  *>    the identified group from a listed sender, a corresponding unmatched
  *>    Message_ID field is silently ignored.

I don't understand the reason behind this rule.

  *> 
  *> 
  *> 4.4. Srefresh NACK
  *> 
  *>    Srefresh NACKs are used to indicated that a received MESSAGE_ID LIST,
  *>    SRC_LIST, or MCAST_LIST object does not match any installed state.

"This might occur as the result of a route change, for example"

Isn't this done on the granularity of a single MessageID, rather than
the entire list?

  *>    An Srefresh NACK is encoded in a MESSAGE_ID ACK object with the
  *>    Refresh_NACK flag set.  When generating an Srefresh NACK, The epoch
  *>    and Message_ID fields of a MESSAGE_ID ACK object MUST have the same
  *>    value as was received.  Objects with the Refresh_NACK flag set are
  *>    transmitted as previously described, see Section 3.4.
  *> 
  *>    MESSAGE_ID ACK objects received with the Refresh_NACK flag set indi-
  *>    cate that the object generator does not have any installed state
  *>    matching the object.  Upon receiving a MESSAGE_ID ACK object with the
  *>    Refresh_NACK flag set, the receiver performs an installed Path or
  *>    Resv state lookup based on the values contained in the object.  If

Based on the Message Id and Epoch...

  *>    matching state is found, then the receiver MUST transmit the matching
  *>    state via a standard Path or Resv message.  If the receiver cannot

Hmmm.  Shouldn't it rather send a (new) trigger message, and re-enter
the reliable delivery mechanism??

  *> 
  *> 
  *> 
  *> Berger, et al.                                                 [Page 25]
  *> 
  *> 
  *> Internet Draft    draft-ietf-rsvp-refresh-reduct-00.txt   September 1999
  *> 
  *> 
  *>    identify any installed state, then no action is required.
  *> 
  *> 
  *> 4.5. Compatibility
  *> 
  *>    Nodes supporting the Summary Refresh extension advertise their sup-
  *>    port via the Summary_Capable flag in all MESSAGE_ID and MESSAGE_ID
  *>    ACK objects transmitted by the node.  Support is also implied when a
  *>    node transmits an Srefresh Message.  This enables supporting nodes to
  *>    detect each other.  When it is not known if a next hop supports the
  *>    extension, standard Path and Resv message based refreshes MUST be

OK, that's one MUST that belongs...

  *>    used.  Note that when the routing next hop does not support RSVP, it
  *>    will not always be possible to detect if the RSVP next hop supports
  *>    the Summary Refresh extension.  Therefore, when the routing next hop

I don't understand this.  The RSVP neighbor will tell you, won't it??

  *>    is not RSVP capable the Srefresh message based refresh SHOULD NOT be
  *>    used.  A node MAY be administratively configured to use Srefresh mes-
  *>    sages in all cases when all RSVP nodes in a network are known to sup-
  *>    port the Summary Refresh extension.

You earlier stated that this extension works with non-RSVP clouds, but
now you are telling us that it doesn't ??

  *> 
  *>    Nodes supporting the Summary Refresh extension must also take care to
  *>    recognize when a next hop stops sending MESSAGE_ID and MESSAGE_ID ACK
  *>    objects with the Summary_Capable flag set.  To cover this case, nodes
  *>    supporting the Summary Refresh extension MUST examine each received
  *>    Summary_Capable flag.  If the flag changes from indicating support to
  *>    indicating non-support then Srefresh messages MUST NOT be used for
  *>    subsequent state refreshes to that neighbor.
  *>

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Oct 1999 09:18:52 -0400

Bob,
	Thanks for the further review.  Responses are in-line below.

Lou

 >	   class numbers and ctypes as I suggested in a separate message.

This is pending feedback from my co-authors.  (code can parse class
numbers as easily as ctypes.)

 >	   "refresh-by-identifier", abbreviated to "RBI" (very topical!).

That's what "summary refresh" is all about.  Are you saying you don't
like this term?

 >	follow", vs. "My email address is [email-masked]".)

Please let us know if/where you see broken capitalization and we'll fix it.

 >	where you wanted to know that an instance of RBI was associated

I can't speak for the others, but I didn't seriously think about this
since I wanted the ability to aggregate as many Message_IDs fields as
possible and didn't think this came close to the purpose/formats of the
original messages.  Also remember Srefresh is based on the earlier work
by Masanobu Yuhara and Mayumi Tomikawa, see
draft-yuhara-rsvp-refresh-00.txt.

 >  *>    without the transmission of standard Path or Resv messages.  The ben-

why does it matter?

 >  *>    mitted messages, i.e, are not refresh messages.

sure.

 >                 trigger messages that established the state.

okay.

 >stored state and uniquely identifies that state.

good point.

 >h

Will try to clarify...

 >explicit rules for resolving inconsistencies.

Srefresh can only be used after a MESSAGE_ID has been sent and a
MESSAGE_ID ACK has been received.  Given this, it seems to me that it
makes more sense to use a bit in these objects rather than burn a bit in
the common header.  If you think I'm wrong, (and there are no
objections) we'll move this bit to the common header.

 >distinct class for these objects.

As before, this is pending feedback from my co-authors.

Der-Hwa, George, Ping?

 >  *>       Class = MESSAGE_ID Class, C_Type = 3

Will revise.

 >  *>       Class = MESSAGE_ID Class, C_Type = 4
okay.

Appendix A says:

       SrcAddress

            The IP source address for a sender host.  Must be non-zero.

What would you suggest for this document?

 >  *>       Class = MESSAGE_ID Class, C_Type = 5

got it.

 >  *>    Where a Multicast_Message_ID_Tuple consists of:

same response as above.

 >Are SRC_LIST and MCAST_LIST objects are used only for Path message refresh?

yes.  I've added some more words on this in the section intro.

 >  *>    state SHOULD be sent with a destination IP address equal to the

Is this a question?

 >For Resv and ResvTear, why not the RSVP_HOP?

Can they differ?

 >You want a rule here, not an explicit (and necessarily partial) list of

Any suggestions on the rule.

 >I don't know the last should matter...

Options can follow sub-optimal forwarding paths inside a router, so
avoiding options when not required has value.

 >  *>    list of Message_ID fields within a single object.

Okay.

 >in arbitrary interleaving of the 3 CTYpes (which would result in

The above is broken.  The objective for the lists was to show that a
a message could contain either unicast and multicast objects or source
lists.  The revised form is:

<Srefresh Message> ::= <Common Header> [ <INTEGRITY> ]
                        <message_id list> | <source message_id list>

<message_id list> ::= <MESSAGE_ID LIST> | <MESSAGE_ID MCAST_LIST>
                       [ <MESSAGE_ID LIST> ... ]
                       [ <MESSAGE_ID MCAST_LIST> ... ]

<source message_id list> ::= <MESSAGE_ID SRC_LIST>
                              [ <MESSAGE_ID SRC_LIST> ... ]

 >Gratuitous MAY.  Did you mean AND, BTW?

fine and yes.

 >?Which destination IP address restriction was that?

described in the previous section.  Will reference.

 >This sentence should come much earlier

okay, added similar words to the section intro.

 >it can of course send new trigger messages)

Using existing mechanisms is preferable to me.

 >clarity of the protocol, and they are likely to be simplistic for many

I seem to remember this being added in response to an e-mail question...

 >? I don't follow the difference between the last two sentences.

fine, it's redundant with the previous section in any case.

 >I am not sure that I agree with that SHOULD.

assuming the previously stated address restrictions are observed, why not?

 >Whoa.  How does it know the unmatched MessageID is associated with Path 
state?

It's carried in MESSAGE_ID SRC_LIST and MCAST_LIST objects.

 >SRC_LIST does not contain group information.

It's in the destination address of the IP header.

 >This use of "receiver" conflicts with 2205, I think.

okay.

 >I don't understand the reason behind this rule.

Such Path messages would normally be filtered by IP forwarding and not
reach RSVP. Since we're bypassing IP forwarding, we need to perform the
check.

 >Isn't this done on the granularity of a single MessageID, rather than

Yes.

 >the reliable delivery mechanism??

I'm not sure this distinction is meaningful here.  Reliable delivery can
also be used on refreshes.

 >now you are telling us that it doesn't ??

It works when all possible RSVP next hops support the extension.

When they don't, there's a timing issue after a change from a MESSAGE_ID
supporting next hop to a non MESSAGE_ID supporting next hop.  It will
take reliable message timeout to identify that the next hop is no longer
MESSAGE_ID and Srefresh capable.  The more serious problem is when
there's a multicast session and some of the non directly connected next
hops support the extension and others do not.  This case will not be
detected.  Moving the Srefresh support bit to the common header will
permit detection of the case IF the next hop sends a message.  If it
never sends a message, the bit in the common header won't help.

 >  *>    subsequent state refreshes to that neighbor.

Thanks again for the detailed comments.  I'll have an updated draft in
by tomorrow.  The class change will be in there if I can get my
co-authors agreement.  If not, we can talk about it in DC.

Lou