Subject: [pim] pim wg mtg minutes Hiroshima

From: "Mike McBride (mmcbride)" <[email-masked]>
Date: Wed, 18 Nov 2009 13:14:11 -0800

Have been posted:

http://www.ietf.org/proceedings/09nov/minutes/pim.txt

Thanks to David McWalter for taking the minutes. Please review and let
us know if we missed something.

mike

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 19 Nov 2009 09:10:22 +0800

Hi Yiqun and all,

My response to Yiqun's comment is inline (sorry for missing your comment
during the WG session). 

BTW, according to the co-chairs' suggestions, we (the co-authors of this
draft) would like to solicit more comments on this draft.

 >Yiqun: A comment about changing back and forth on the RP
 >    priority.  You have to go back, otherwise if
 >    failures keep happening, everyone ends up at
 >    priority zero.  So we need to accept the disruption
 >    to the traffic when the link comes back up.  This
 >    should be addressed.

Your comment is very good. In fact, we had even thought about this case.
Allowing preemption is the easiest way. However, we still want to give the
operator another option in which traffic disruption can be avoided when the
failed upstream link on R1 (old DR) recovers (from down to up). The basic
idea is actually described in the draft (the following text is quoted from
the draft). I believe the PIM routers will not run into a corner of priority
zero. Correct?

**************************************************************************
   Once the failed upstream link on R1 recovers (from down to up), its
   DR priority can be either recovered or not according to the pre-
   configured preemption policy. For example, if preemption is not
   allowed, its DR priority will remain unchanged so as to avoid DR
   switchover. As a result, the transient multicast forwarding
   interruption due to multicast forwarding tree rebuilding will not
   occur. Once the current DR fails or its DR priority changes, the
   non-DR should start using its actual DR value to compete for a new
   round of DR election provided it has got route to the uplinks.
**************************************************************************

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Mike
> McBride (mmcbride)
> 发送时间: 2009年11月19日 5:14
> 收件人: [email-masked]
> 主题: [pim] pim wg mtg minutes Hiroshima
> 
> Have been posted:
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 29 Nov 2009 18:16:42 +0100

Hi, 

Related to the discussion on loop occurrence in the PIM MT-ID context,
let's first look at loops resulting from a "single" and "common"
topological changes due to metric update or a link up/down.

Example to fix ideas:

        --- B ---
       |         |
 S1 -- A -- C -- E--
  |    |         |  |
  |     --- D ---   |
  |                 |
   -----------------

Initial MDT: S1->A->[B,C->E,D]  

Conditions: topological change (e.g. metric [E,S1] becomes << [A,S1])
all nodes send PIM Prune towards their upstream neighbor e.g. node E to
C, node C to A, etc. and all nodes send PIM Join towards their
"alternate" neighbor e.g. node A to C, node C to E, etc.

New MDT: S1->E->[B,C->A,D]

However, if node E has already received and treated the PIM Join sent by
node C but node C has not sent the PIM Prune to A, as soon as node E
will receive the traffic on the new MDT tree (from S1), it will forward
the traffic to C on the new branch E-C but C will forward traffic both
to A and on the branch C-E of the "old" MDT tree which has not been
removed yet. Such loop will stay in place until the PIM Prune are
treated.

Generally speaking the conditions for (transient) loop occurrence are:

- A node sends a PIM Join before sending a PIM Prune for the same group
G in different directions (e.g. node C sends Join to E before sending a
Prune to A)

- MDT child node (i.e. node E) on the old topology becomes a parent node
for the same MDT on the new topology 

- The distance from node (e.g. node C) to node E to the source/RP is
lower in the new topology than the same distance in the old topology

To discuss (transient) loop conditions in PIM MT-ID context, the
following cases shall be considered

i) same Source S, same Group G

i.a) same Source S, same Group G assigned to unique MT-ID value -> no
additional cases of routing or forwarding inconsistency possible than
without MT-ID. 

i.b) same Source S, same Group G assigned to different MT-ID values ->
no additional cases of routing inconsistency possible than above.
However, loop occurrence conditions may be now repeated per MT-ID (so
probability increases). May lead to packet duplicates that are not
detectable (as forwarding is MT-ID unaware).

ii) different Sources S, same Group G

ii.a) different Sources S, same Group G assigned to unique MT-ID value
-> no additional cases of routing or forwarding inconsistency possible
than without MT-ID.  

ii.b) different Sources S, same Group G assigned to different MT-ID
value -> no additional cases of routing inconsistency possible than
above. However, loop occurrence conditions may be now repeated per MT-ID
(so probability increases). May lead to packet duplicates iff path from
node X share the same upstream neighbor towards the source/RP. Packet
duplicates are not detectable (as forwarding is MT-ID unaware). 

iii) same Source S, different Groups G 
 
iii.a) same Source S, different Groups G assigned to unique MT-ID value
-> no additional cases of routing or forwarding inconsistency possible
than without MT-ID.   

iii.b) same Source S, different Groups G assigned to different MT-ID
values -> no additional cases of routing inconsistency possible than
without MT-ID.  

iv) Different Sources S, different Groups G 
 
iv.a) Different Sources S, different Groups G assigned to unique MT-ID
value -> no additional cases of routing or forwarding inconsistency
possible than without MT-ID.

iv.b) Different Sources S, different Groups G assigned to different
MT-ID values -> no additional cases of routing inconsistency possible
than without MT-ID.

In case iii) (and iv)) the "switching" node should behave as an "RP".  

Clarifications are also requested because the MT-ID also induces
transients from ID value changes.

- Section 3.2: Uniqueness of ID's ? per "PIM -contiguous- Domain" or
"per underlying IGP" or "per set of Multicast Address" ? 

- Section 3.2: First sub-bullet assume that OSPF MT [RFC4915] or ISIS MT
[RFC5120] MUST be used but it appears to be a non-necessary condition
and I do not see why this I-D shall be restrictive in this matter. It
appears to me to be a sufficient condition.

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mike McBride (mmcbride)
> Sent: Wednesday, November 18, 2009 10:14 PM
> To: [email-masked]
> Subject: [pim] pim wg mtg minutes Hiroshima
> 
> Have been posted:
>