Subject: [pim] draft-ietf-pim-sm-v2-new-08.txt comments

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 01 Dec 2003 17:41:58 -0800

All,

Below is the list of the comments I have. The comments are in
chronological order.

Note that I took the liberty to add few entries with comments from
other people that were sent to the mailing list in the past (if
their emails weren't answered). I have tried to give credits to the
authors of those comments.

The list is a bit longer than I was anticipating so I tried to keep
most of the entries relatively short.
Please ask me for clarification if an entry is not clear.

Thanks,
Pavlin

===================================================================
1) Somewhere in the text:
  Explicity specify not to route on link-local multicast groups
  and/or add a pointer to the document that says that.

===================================================================
2) Everywhere in the text:
  Don't use "link-local" terminology, because it has no meaning
  for IPv4. Or, at least, clarify that it is only for IPv6, and
  describe what happens in case of IPv4.

===================================================================
3) Everywhere in the text:
  All AssertWinner related comparison such as
  "AssertWinner(*,G,I) == me"
  or
  "AssertWinner(S,G,I) == me"
  should replace "me" with "my_ip_address(I)".

===================================================================
4) Section 4
  [ And old email from "Anttoni Nurkka  "
  <[email-masked]> from 4 Feb 2002]

  Comment: A description of Section 4.7 is missing

===================================================================
5) Section 4.1.2, 4.1.3, 4.1.4
  [Based on an email from Xavier Brouckaert <[email-masked]>
   to the [email-masked] mailing list on 15 Jul 2003]
  The "Not interface specific" state in each section is missing
  the following item:
  * State: one of {"NotJoined", "Joined"}

===================================================================
6) Section 4.1.5
  Change "NotJoined(*,G)" to "RPTNotJoined(G)" for consistency with
  the naming convention in Section 4.5.9

===================================================================
7) Section 4.1.6
  [An old email from "Ketan Talaulikar" <[email-masked]>
   from 18 Jan 2002]:

The inherited_olist(S,G,rpt) macro is used to determine the OIFs over which
data coming in on the RPF_interface(RP) is to be forwarded while the SPT
switchover is not completed. This macro correctly excludes OIFs over which
(S,G)joins have been received. I presume this is to ensure that data
arriving over the RPT till our router is not forwarded over SPT further
downstream.  This so that the downstream routers do not get the false
impression that the SPT switchover has been completed.

However, I find that the macro also excludes the interfaces over which local
(S,G) memberships are received. I was unable to see the harm in forwarding
data arriving over the RPT over such interfaces provided no (S,G) joins are
also received over them. I agree that when we receive a (S,G) membership we
can trigger the SPT. But is there any reason to delay the forwarding of data
till the SPT is established? Is it intentional?

===================================================================
8) Section 4.2 (the processing of data received from S to G on
  interface iif):

  Modify:
      # Note: a register state transition may happen as a result
      # of restarting KeepaliveTimer, and must be dealt with here.

  to:
      # Note: a register state transition or UpstreamJPState(S,G)
      # transition may happen as a result of restarting KeepaliveTimer,
      # and must be dealt with here.

  The reason for the modification is because start/timeout of the
  KeepaliveTimer(S,G) may affect the output of JoinDesired(S,G),
  and therefore it may affect the UpstreamJPState(S,G).

===================================================================
9) Section 4.2 (the processing of data received from S to G on
  interface iif):

  Modify:

 if( iif == RPF_interface(S) AND UpstreamJPState(S,G) == Joined ) {

 to:

 if( iif == RPF_interface(S)
     AND ((UpstreamJPState(S,G) == Joined )
          OR (DirectlyConnected(S) == TRUE )) {

The modification is needed in to restart the KeepaliveTimer in case
of, say, a DR that is encapsulating in PIM Registers the data
packets from a source on the same LAN, but that DR hasn't received a
(S,G) Join message.

===================================================================
10) Section 4.2 (the processing of data received from S to G on
  interface iif)

  When a packet is received, why in one case the action is
  "set KeepaliveTimer(S,G) to Keepalive_Period"
  but in another it is just:
  "restart KeepaliveTimer(S,G)"
   Aren't both actions suppose to be same?

===================================================================
11) Section 4.2.2
  The text says:
  "Additionally a router sets SPTbit(S,G) to TRUE when it receives
  an Assert(S,G) on RPF_interface(S)."

  However, the Assert-related text in Section 4.6.1 says that the
  SPTbit(S,G) is set to TRUE only in case of A6, which happens when
  we are in "I am assert Loser" state and we receive a preferred
  assert with RPTbit clear AND AssertTrackingDesired(S,G,i) ==
  TRUE)).

  Which text is accurate, because the condition in Section 4.6.1 is
  more specific than the condition in Section 4.2.2 ?

===================================================================
12) Section 4.2.2
  In the Update_SPTbit() macro definition below, what about the corner
  case when both RPF'(S,G) and RPF'(*,G) are NULL? I.e., should the
  macro contain the explicit condition that replaces
  "RPF'(S,G) == RPF'(*,G)"
  with
  "((RPF'(S,G) == RPF'(*,G)) AND (RPF'(S,G) != NULL))"  :

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP(G))
                   OR inherited_olist(S,G,rpt) == NULL
                   OR RPF'(S,G) == RPF'(*,G) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

===================================================================
13) Section 4.3.1
  Add text in the lines of:
  If the Hello holdtime or period is changed, then send immediately
  a Hello message, and schedule the next one at random in the
  interval [0, hello_period).
  If any other Hello option is changed, send immediately a Hello
  message, but don't reschedule when to send the next one.

===================================================================
14) Section 4.3.1, last paragraph.
  If the IP address of an interface has been changed, the spec says
  that a Hello message with Holdtime=0 and the old IP address will
  be sent-out. The spec also says:
  "After an interface has changed its IP address, it MUST send a
  Hello message with its new IP address."

  What about modifying that sentence to say that the Hello message
  with the new IP address must be send _immediately_ (or at least
  after some very short randomized interval).

===================================================================
15) Section 4.3.2
  On startup, am I the DR by default, or do I wait some period of time
  before self-promoting myself as the DR?

===================================================================
16) Section 4.3.4
  The spec says:
  "The primary address of the source
   interface of the router MUST NOT be listed within the Address List Hello
   option."

  Then, later the spec says:

"When processing a received PIM Hello message containing an Address List
Hello option, the list of secondary addresses in the message completely
replaces any previously associated secondary addresses for that
neighbor. If a received PIM Hello message does not contain an Address
List Hello option then all secondary addresses associated with the
neighbor must be deleted. If a received PIM Hello message contains an
Address List Hello option that includes the primary address of the
sending router in the list of secondary addresses then the addresses
listed in the message excluding the primary address are used to update
the associated secondary addresses for that neighbor."
   
   This is contradictory: is it or is it not allowed to include the
   primary address in the Address List Hello option list of
   addresses? Hence, I believe that the last sentence should be
   deleted.

===================================================================
17) Section 4.4.1

  Modify:

  Bool CouldRegister(S,G) {
     return ( I_am_DR( RPF_interface(S) ) AND
              KeepaliveTimer(S,G) is running AND
              DirectlyConnected(S) == TRUE )
  }

 to

  Bool CouldRegister(S,G) {
     return ( I_am_DR( RPF_interface(S) ) AND
              KeepaliveTimer(S,G) is running AND
              DirectlyConnected(S) == TRUE AND
              !I_am_RP(G) AND
              RP(G) != NULL)
  }

===================================================================
18) Section 4.4.1 and Section 4.4.2
  How to set the outer TTL for PIM Register packets?
  (a) Fixed value (similar to Cisco)
  (b) Set it to the inner TTL on encasulation, then copy back to
      inner TTL on decapsulation
  (c) Set to inner TTL on encapsulation. On decapsulation, if outer
      TTL is larger than the inner TTL, then don't copy it (Mark
      Handley's suggestion).

===================================================================
19) Section 4.4.2
  The text there says:

  "Thus, at the RP, KeepaliveTimer(S,G) should be restarted to ( 3 *
  Register_Suppression_Time + Register_Probe_Time )."

  At the RP, do we always restart with the above value, or only
  when we restart because of a PIM Register, or only when a
  Register-Stop is sent (as specified in Section 4.12)?

===================================================================
20) Section 4.5.2
  If we ignore (*,G) Join/Prune entry because of RP mismatch,
  do we ignore all other (S,G) and (S,G,rpt) entries within same
  J/P message that are grouped together with this (*,G) Join/Prune
  entry?

===================================================================
21) Section 4.5.4
  [An old email from "Katta Sambasivarao" <[email-masked]>
   from 29 Jan 2002]:

I have a doubt in "receiving (S,G, rpt) J/P message" case.

In the Notes of section 4.4.4, the draft says "Receiving
a Prune(*,G) does not affect the (S,G,rpt) downstream
state machine."

I dont understand this. We will have (S,G,rpt) state only
when we got (*,G) and (S,G) states. With (*,G) prune if
the interface is removed from RP tree, what is the
meaning in maintaining (S,G,rpt) state on that interface.

Can please someone clarify my doubt.

===================================================================
22) Section 4.5.5, 4.5.6, 4.5.7
  Do we need to override a Prune even if this was
  a Prune from a router that has not sent a Hello message yet?

===================================================================
23) Section 4.5.6
  The text description for "RPF'(*,G) changes not due to an Assert":
  "This may be caused by a change in the MRIB routing database." ->
  "This may be caused by a change in the MRIB routing database or
  the group-to-RP mapping."

===================================================================
24) Section 4.5.6
  When the RP changes, then it could be that
  both events occur for the upstream (*,G) state machine:
  "JoinDesired(*,G) -> False"
  and
  "RPF'(*,G) changes not due to an Assert"
  In that case, does it matter whether we perform first the actions
  for the first event or the second event?

===================================================================
25) Section 4.5.7
  The text description for "RPF'(S,G) changes" should be renamed
  to describe "RPF'(S,G) changes not due to an Assert", and the text
  should be syncronized with the corresponding description
  in Section 4.5.6 in case of (*,G).

===================================================================
26) Section 4.5.9
  Why there are no entries for "RPF'(S,G,rpt) changes due to an
  Assert", and "RPF'(S,G,rpt) changes due not to an Assert"
  for the Upstream (S,G,rpt) state machine?

===================================================================
27) Section 4.6
  Add the following text right before Section 4.6.1:

"We note that some older PIM implementations incorrectly fail to send
Hello messages on point-to-point interfaces, so we also RECOMMEND that a
configuration option be provided to allow interoperation with such older
routers, but that this configuration option SHOULD NOT be enabled by
default."

  In other words, add the same paragraph that appears in Section 4.5
  right before Section 4.5.1

===================================================================
28) Section 4.6.1 and Section 4.6.2
  Do we need "RPF_interface(S) becomes I" entry for the
  (S,G) Assert state machine, and "RPF_interface(RP(G)) becomes I"
  entry for the (*,G) Assert state machine?

===================================================================
29) Section 4.6.1 and Section 4.6.2
  What about adding the following action: (??)
  If we are in "I am Assert Loser" state, and if the current Assert
  winner neighbor's Hello timer expires, then the action is A5, and
  we transiation to NI state (this applies for both the (S,G) and
  (*,G) Assert state machine). 

===================================================================
30) Section 4.6.2
  The bold text in the beginning of this section describes the
  conditions when no transition can occur in the (*,G) state
  machine:
  - The (S,G) state machine is in NoInfo
  - The receiving of an assert message hasn't triggered any change
    of state in the (S,G) state machine.

  Then, later the text contains the following sentences:
  
  "When in NoInfo state, the following events trigger transitions, but
   only if the (S,G) assert state machine is in NoInfo state:"

  and
  
  "When in "I am Assert Winner" state, the following events trigger
   transitions, but only if the (S,G) assert state machine is in NoInfo
   state:"

  and 
  
  "When in "I am Assert Loser" state, the following events trigger
   transitions, but only if the (S,G) assert state machine is in NoInfo
  state:"

  However, the above condition after "but" does not consider the
  case when there was any change of state in the (S,G) state machine
  which doesn't match the text in the beginning of that section.
  Also, if the event to consider is the receiving of a (*,G) assert
  that doesn't have the S address set, then which (S,G) assert state
  machine do we need to check whether it is in NoInfo state?
  Presumably, no (S,G) assert state machine needs to be considered,
  but this should be clarified.

===================================================================
31) Section 4.6.2
  The text there contains:

     An "acceptable assert" is one that has a better metric than
     my_assert_metric(S,G,I).

     An "inferior assert" is one with a worse metric than
     my_assert_metric(S,G,I).

 Shoudn't "my_assert_metric(S,G,I)" be replaced with
 "rpt_assert_metric(G,I)", because this section talks about (*,G)
 Asserts?

===================================================================
32) Section 4.7
  When the Border bit of PIM Registers is set, then RFC 2362 says:

           5 A "Border bit" bit is added to the Register message,
             to  facilitate  interoperability mechanisms. PMBRs set this
             bit when   registering for  external  sources  (see Section
             2.7).  If  the  "Border bit" is set in the Register,
             the   RP does the following:

                1 If there is no matching (S,G) state, but there
                  exists (*,G) or (*,*,RP) entry, the RP creates a (S,G)
                  entry, with a `PMBR' field.  This field holds the
                  source of the Register (i.e. the outer network layer
                  address of the register packet).  The RP triggers a
                  (S,G) join towards the source of the data packet, and
                  clears the SPT bit for the (S,G) entry. If the
                  received Register is not a `null Register' the packet
                  is forwarded according to the created state. Else,

                2 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, and
                  the received Register is not a `null Register', the
                  decapsulated packet is forwarded to the oif list of
                  that entry. Else,

                3 If the `PMBR' field for the corresponding (S,G)
                  entry matches the source of the Register packet, the
                  decapsulated packet is forwarded to the oif list of
                  that entry, else

                4 The packet is dropped, and a Register-stop is
                  triggered towards the source of the Register.

  The new spec appears to lack the above description (or at least it
  is not explicit). Maybe the RFC text should be merged into Section
  4.7?

===================================================================
33) Section 4.7.1
  [An old email from "Shankar  Vasudevan"
  <[email-masked]> from 16 Jan 2002]:

  [>>> If RPF_interface(S) is not an interface in the PIM-SM domain,
  the packet cannot be originated into the PIM domain at this
  router, and the PIM-SM component of the PMBR will not process the
  packet. <<<]

does that mean PIM-SM will not process packets coming on interfaces
not owned by it ?
or is it saying we should check if the RPF_interface(S) is in PIM-SM
domain for such (S,G) creation events ?

the next line starts with "Otherwise" implying
"If RPF_interface(S) is an interface in the PIM-SM domain .."

What was intended by those two lines ?

pls clarify.
 
===================================================================
34) Section 4.7.2
  [Based on an old email from "P.Jhingran"
  <[email-masked]> from 5 Feb 2002, and 
  from "Bakar" <[email-masked]> from 6 Feb 2002]

The text says:
"In the former case, the PMBR will need to issue send a Join(*,*,RP) to
all the RPs in the PIM-SM domain."

Does this mean that the PMBR should send Join messages to the
Cand-RPs as well even though they may obviously be not used at all
(e.g., they have worse priority than other RPs), or such Cand-RPs
aren't RPs by definition?
Alternatively, is this an implementation-specific issue, and the
simplest thing to do is to send (*,*,RP) Join to all RPs in the
Cand-RP set?
The text itself as-is looks fine, but it may be worth adding a note
that says it is OK to send (*,*,RP) Join message to all RPs in the
Cand-RP set.

===================================================================
35) Section 4.10
  Specify the behavior if a PIM control message with unrecognized Type or
  Version field is received. E.g., just say that a message is
  silently ignored or sth. like that. Alternatively, add Mark
  Handley's suggestion regarding the PIM version field check:

"My guess is that the reason for changing the version field is that
the protocol is not backward-compatible.  I would expect that any
version increase would be signalled in Hello packets, and newer
versions requried to fall back to v2, or refuse to communicate with
v2, as they choose.  But I think a v2-only implementation should
drop anything other than a Hello with version greater than 2, and
log a warning."

===================================================================
36) Section 4.10.2
  If our Hello holdtime is 0xffff (e.g., if we are sending Hello
  messages over dial-on-demand links), then do we still send
  periodically the Hello messages according to that value,
  or the blocking of those periodic messages happens outside PIM?

===================================================================
37) Section 4.10.3
  Fix the description of the PIM Null Register messages
  (e.g., what the mandatory fields in the dummy IP header are,
  what about the checksum of that dummy IP header, etc).

===================================================================
38) Section 4.10.5
  "RPF lookup." -> "MRIB lookup." in the text below: (??)

Unicast Upstream Neighbor Address
     The address of the RPF or upstream neighbor.  The format for this
     address is given in the Encoded-Unicast address in Section 4.10.1.
     This address should be the link-local address of the upstream
     neighbor, as obtained from the RPF lookup.

===================================================================
39) Address comments by "Suresh Boddapati" <[email-masked]>
  in an email sent to the PIM ML on May 15, 2003:

(a) In section 4.10.5.1 (Group Set Source List Rules). In the subsection for
Wildcard Group Set, the definition states:

"The wildcard group set is represented by the entire multicast range - the
beginning of the multicast address range in the group address field and the
prefix length of the multicast address range in the mask length field of the
Multicast Group Address, e.g. 224.0.0.0/4 for IPV4......"

Is this always 224.0.0.0/4 and no other value? If so, should it not say
"i.e. 224.0.0.0/4" and not "e.g. 224.0.0.0/4"? The latter suggests other
possible values for the same family.

(b) In the same section, the table that specifies the rules for valid
combinations of Joins and Prunes says that when the combination is invalid,
the combination MUST not be generated by the router. It does not say
anything about what a receiver should do upon receiving such a combination.
Are we to assume that this should follow the "be liberal in what you accept"
behavior i.e. if you receive a (*,G) Join and a (*, G) prune in the same
message, you just go about processing them as usual (obviously, it would not
cause any harm to do so).

(c) Also, the draft says that "in a Join/Prune message, all the Multicast
Group Addresses, Joined Source Addresses and Pruned Source addresses MUST be
of the same address family. It is NOT PERMITTED to mix IPV4 and IPV6
addresses within the same message."

If a router receives such a message, should the whole message be discarded?
It is probably good to specify this behavior to ensure consistent operation.

===================================================================

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