Subject: Questions about draft-ietf-rsvp-refresh-reduct-05

From: Bob Braden <[email-masked]>
Date: Mon, 11 Sep 2000 21:52:46 GMT

Lou,

I have been struggling with understanding section 5 of the Refresh
Reduction Proposed Standard (which is still in the RFC Editor's queue,
unfortunately).  Pardon me if I am dense.  I have been going over your
words line by line and trying to write down what I think they mean, but
I find one apparent contradiction and some confusion.  Hopefully you can
straighten me out.  I apologize for bringing this up so late; I just
happened to want to REALLY understand section 5.

In the following, I have extracted just the sentences that concern the
use of the various MESSAGE_ID objects, which is where I have confusion.
Everything else seems pretty much OK, and I don't think I have omitted
anything bearing on my confusion.

Bob
________________________________________________________________

  *> 
  *> 5. Summary Refresh Extension
  *> 
  *> ...
  *> 
  *>    The three
  *>    objects are the MESSAGE_ID LIST object, the MESSAGE_ID SRC_LIST
  *>    object, and the MESSAGE_ID MCAST_LIST object.
  *> 
  *> ...
  *> 
  *>    The MESSAGE_ID LIST object is used to refresh all Resv state, and
  *>    Path state of unicast sessions.
  *> 
  *>    The other two objects are used to refresh Path
  *>    state of multicast sessions.  ... Both carry
  *>    Message_Identifier fields and corresponding source IP addresses.  The
  *>    MESSAGE_ID SRC_LIST is sent in messages addressed to the session's
  *>    multicast IP address.  The MESSAGE_ID MCAST_LIST object adds the
  *>    group address and is sent in messages addressed to the RSVP next hop.
  *>    The MESSAGE_ID MCAST_LIST is normally used on point-to-point links.
  *> 

I write these rules as follows.  I use "G" for the session destination
address, whether ucast or mcast).  Otherwise, I hope the symbology is
obvious.

	A1): (id) 		for Resv and ucast Path state

	A2): (id,S) -> G  	for mcast Path state

	A3): (id,S,G) -> hop	for mcast Path state, NORMALLY(?) in pt-pt links

What does "normally" mean here??

For consistency with later statements, A1) should probably be:
A1'): (id)->hop		for Resv and ucast Path msgs
 
  *> ...
  *> 
  *> 5.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
  *>    messages with the other objects.  A single Srefresh message MAY
  *>    refresh both Path and Resv state.
  *> 
  *>    Srefresh messages carrying Message_Identifier fields corresponding to
  *>    Path state are normally sent with a destination IP address equal to
  *>    the address carried in the corresponding SESSION objects.  The
  *>    destination 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_Identifier fields corresponding to Resv
  *>    state MUST be sent with a destination IP address set to the Resv
  *>    state's previous hop.

	B1) Path state "normally" -> G

	B2) Path state -> nhop IF direct neighbor and (ucast or pt-pt)

	B3) Resv state -> phop

Now, B1) seems to directly contradict A1.  A1 says ucast Path state is
sent to nhop, B1) says it is normally sent to G, whatever "normally"
means.

B2 is OK, noting the new condition of direct neighbor to be applied
to A1) and A3),  But it calls into question the "normally" in A3).

B3) is consistent with A1')

  *> 
  *>    Srefresh messages sent to a multicast session's destination IP
  *>    address, MUST contain MESSAGE_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 paragraph above appears to be completly redundant with the two
preceding paragraphs, hence can be ignored.  Did I miss something?
  *> 
  *>  ...
  *> 
  *> 5.3. Srefresh Message Usage
  *> 
  *> ...
  *> 
  *>    When generating an Srefresh message, there are two methods for
  *>    identifying which Path state may be refreshed in a specific message.
  *> ...
  *>    The primary method is to
  *>    include only those sessions that share the same destination IP
  *>    address in the same Srefresh message.
  *> 

NOte that this does not fit the ucast Path msgs in A1), since the
Session dest G will not match the nhop address of the Srefresh message.
Hence MESSAGE_ID LIST objects will not be used except for the following
"optimization".

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

But if A1 does not apply, neither do A2 or A3 for a unicast Path message.
So this section has left me confused.

  *>    (Redundant sentence omitted)

  *>    The use of this method MAY be administratively configured.  When
  *>    using this method, the destination address in the IP header of the
  *>    Srefresh message is usually the next hop's address.  When the use of
  *>    this method is administratively configured, the destination address
  *>    should be the well known group address 224.0.0.14.  When the outgoing
  *>    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.

That appearance of the WK group address was something of a surprise here...
Otherwise, I could not figure out what the last two sentences actually mean.

  *> 
  *>    Identifying which Resv state may be refreshed within a single
  *>    Srefresh 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.
  *> 
  *> 

This is consistent with A1'), so that's OK.

Bob

---

From: Lou Berger <[email-masked]>
Date: Mon, 11 Sep 2000 18:50:20 -0400

Bob,
         See comments in-line.  Should I ask what's motivating the "REALLY" 
level of interest?

Lou

>anything bearing on my confusion.

A3 is usually used on PTP links instead of A2.  BTW the inclusion of this 
was a compromise.  I can't remember the details of the compromise, just 
that it was one.

>A1'): (id)->hop         for Resv and ucast Path msgs

If memory serves, the omission of "->hop" was intentional and not meant to 
be implied.  Specifically, the intro section is just identifying the new 
objects and defining how they differ.  There may have been too much info on 
the MCAST and SRC list object in this section as I wasn't trying to 
generate any implementation rules/requirements at this point.  Note there 
are no MAY/MUST/SHOULD directives in this section.

>sent to nhop,

I believe this is an inference.  I don't see A1 saying anything about where 
the object is sent.

>B1) says it is normally sent to G, whatever "normally"
>means.

meaning is sent to G except when the subsequent sentence applies.  I guess 
I could have said something like "MUST except when ..." but that seems to 
me more confusing.

>B3) is consistent with A1')

I'm missing something.  A1 doesn't say anything about destination and A1') 
says hop. Where's the inconsistency?

>preceding paragraphs, hence can be ignored.  Did I miss something?

No.  I can't tell/remember if I was being overly specific or if the text 
was added after a related question.

>Session dest G will not match the nhop address of the Srefresh message.

This matches B1.

>Hence MESSAGE_ID LIST objects will not be used except for the following

If you meant MESSAGE_ID MCAST_LIST, I agree.

>So this section has left me confused.

this matches B2.

>That appearance of the WK group address was something of a surprise here...

If I remember correctly this is something George brought in to reduce total 
messages sent (at the expense of having to ignore some message IDs.)

George, can you add anything here?

>This is consistent with A1'), so that's OK.

Lou