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

From: [email-masked]
Date: Thu, 21 Oct 1999 09:34:07 -0700

*> 
  *> 
  *>  >
  *>  >	2. You might be able to increase clarity by introducing a term like
  *>  >	   "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?

Lou,

Yes. This may only be personal, but "summary refresh" did not seem to me
to imply the right semantics.  It sounds like a summary across
different state, i.e., it gets confused in my mind with state compression.

  *> 
  *>  >	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]".)
  *>  >
  *> 
  *> Please let us know if/where you see broken capitalization and we'll fix it.
  *> 

We will have to sit together and go over it.

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

So, rethinking this, I realize the situation is slightly more complicated
than I was thinking before.  So let's drop this.

  *>  >
  *>  >(Kill the hyphenation)
  *> 
  *> why does it matter?

Because RFCs are ragged-right without hypenation.  That's Jon's style,
and we respect it.

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

Let's put this down as an open question for the moment.

  *>  >
  *>  >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.
  *> 
  *> As before, this is pending feedback from my co-authors.
  *> 
  *> Der-Hwa, George, Ping?

(This interacts with my suggested changes in Class number)

  *>  >  *>       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.
  *> 
  *> Appendix A says:
  *> 
  *>        SrcAddress
  *> 
  *>             The IP source address for a sender host.  Must be non-zero.
  *> 
  *> What would you suggest for this document?
  *> 

I guess you have me there, but still, I was confused between H/H source
and sender address when reading this this document 

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

I don't understand why this is "should".  What other option is there?
Did you mean "are sent", or "must be sent" ?

  *>  >
  *>  >  *>    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?
  *>  >
  *> 
  *> Can they differ?

No, and that's the point.  I would state the rule: take the source
address from the RSVP_HOP object, except in the case of message
types that do not include an RSVP_HOP object (e.g., PathErr, ResvConf,
and Bundle), use the IP source address from the IP header.

(This rule is simple and obvious and does not require enumeration
of message types).

  *> 
  *>  >You want a rule here, not an explicit (and necessarily partial) list of
  *>  >message types.
  *>  >
  *> 
  *> Any suggestions on the rule.

Above.

  *> 
  *>  >  *>
  *>  >  *>    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...
  *>  >
  *> 
  *> Options can follow sub-optimal forwarding paths inside a router, so
  *> avoiding options when not required has value.
  *> 

OK

  *> 
  *> 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> ... ]

Maybe:

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

  *> 
  *> <source message_id list> ::= <MESSAGE_ID SRC_LIST>
  *>                               [ <MESSAGE_ID SRC_LIST> ... ]
  *> 
  *>  >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?
  *>  >
  *> 
  *> described in the previous section.  Will reference.

Maybe instead there could be a concise way of restating it?

  *> 
  *>  >  *>    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)
  *>  >
  *> 
  *> Using existing mechanisms is preferable to me.

Not sure what you mean by that.  My proposal WOULD use existing
mechanisms.

  *>  >
  *>  >  *>    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.
  *> 
  *> assuming the previously stated address restrictions are observed, why not?
  *> 

Because of packet loss issues with IP fragmentation.

  *>  >
  *>  >  *>    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?
  *> 
  *> It's carried in MESSAGE_ID SRC_LIST and MCAST_LIST objects.

Ah.  It was never clearly (to me!) stated that SRC_LIST and LIST objects
are associated only with Path messages.  This is another aspect of
re-alignment of class numbers vs. names.

  *> 
  *>  >  *>
  *>  >  *>
  *>  >  *> 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?
  *>  >
  *> 
  *> Yes.

Then I think our sentence need revision, because it talks about LIST
granularity.

  *> 
  *>  >  *>    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??
  *>  >
  *> 
  *> I'm not sure this distinction is meaningful here.  Reliable delivery can
  *> also be used on refreshes.
  *> 

?? Needs more thought.

Bob

---

From: Lou Berger <[email-masked]>
Date: Thu, 21 Oct 1999 13:39:35 -0400

>different state, i.e., it gets confused in my mind with state compression.

I think calling it compressed refreshes would be confusing with Lixia's 
work.   Do you think a name change is required?

>We will have to sit together and go over it.

We can do it in DC.

>Because RFCs are ragged-right without hypenation.  That's Jon's style,

I don't remember seeing this as a requirement.  I'm happy to comply.  (Now 
I just have to get nroff to listen...)

 >     either

Another topic for DC.  (BTW can we be added to agenda?)

>Did you mean "are sent", or "must be sent" ?

okay, will clarify.

>(This rule is simple and obvious and does not require enumeration

I'll use your rule.  I also think explicit lists makes things clearer for 
those of us with simple minds.

>   *>                               [ <MESSAGE_ID SRC_LIST> ... ]

works for me.

>Not sure what you mean by that.  My proposal WOULD use existing

Rather than introduce a new way of setting time values, i.e, via Srefresh, 
I'd prefer to just use the existing per Path/Resv message mechanism.

This is also closer to the intent of Srefresh, i.e., to just refresh and 
change any state.    I by changing the contents of an object, the message 
is by definition a trigger message.

>Because of packet loss issues with IP fragmentation.

Limiting size is now mentioned in the precious section per your earlier 
comment.

>Then I think our sentence need revision, because it talks about LIST

already done.

>   *> also be used on refreshes.

Thanks again,
Lou

---

From: Masanobu Yuhara <[email-masked]>
Date: Mon, 25 Oct 1999 19:11:19 +0900

> I just have to get nroff to listen...)

RFC2223 says:

   Do not fill the text with extra spaces to provide a straight right
   margin.
 
   Do not do hyphenation of words at the right margin.

....

   .hy 0
   .ad l

-- masa

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Oct 1999 07:04:44 -0500

Thank you very much for the nroff.  An updated I-D was submitted on 
Friday.  It didn't contain any hyphenation.

Lou

PS if anyone doesn't want to wait for the draft to come out in the I-D 
area,  let me know and I'll  send it to you.