Subject: Re: [pim] pim wg mtg minutes Hiroshima

From: ycai <[email-masked]>
Date: Tue, 09 Feb 2010 10:39:38 -0800

Dimitri,

I think I understand what you are saying now.  If I am not mistaken, what
you described is more relevant to PIM Join/Prune sequence in general and is
not specific to the MT-ID draft.  If so,  do you plan to write a separate ID
and suggest some proposed solution?

We have checked in the -03 version of the MT-ID draft.  It includes some new
text that we hope to address the comment you and Thomas brought up.  Please
take a look.

And look forward to meeting you all at Anaheim.

Thanks.

On 1/23/10 1:37 AM, "PAPADIMITRIOU Dimitri"
<[email-masked]> wrote:

> Hi, 
> 
> Here below a couple of clarifications:
> 
>>> 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.
>>> 
>> 
>> Actually,  if the above happens, packets won't really be
>> looped around.  E
>> would drop those forwarded by C due to RPF.
> 
> In this base case (2-cycle), E if correctly reconfigured (how to ensure
> that the RPF checks are sync'ed) will prevent closing the loop (but
> packet travels back to E). However take now the scenario where there is
> a 3-cycle:
> 
>           --- B ---
>          |    |    |
>    S1 -- A -- C -- E --
>     |    |    |    |   |
>     |     --- D ---    |
>     |                  |
>      ------------------
> 
> Old MDT (xxx): S1->A->C->D->E->B
> 
>           --- B xxxx
>          |    |    x
>    S1xxx A xx C -- E --
>     |    |    x    x   |
>     |     --- D xxxx   |
>     |                  |
>      ------------------
> 
> New MDT (+++): S1->E->C->B->A->D
> 
>          ++++ B xxxx
>          +    +    x
>    S1xxx A xx C ++ E ++
>     +    +    x    x  +
>     +    ++++ D xxxx  +
>     +                 +
>     +++++++++++++++++++
> 
> You see that the new tree closes all the 3-cycles (by adding [E,C] the
> loop C->D->E is formed for instance). What I mean by this Figure is that
> you have a transient situation where this occurs (in part. if Joins are
> sent before Prunes are initiated).
> 
>> However, the potential of loops still exist when topologies are
>> misconfigured and we will provide the text to suggest ways to
>> prevent it.
>> 
>> <snipped>
> 
> It is not a matter of configuration only. It is a matter of Join/Prune
> sequencing:
> 
> - case i) Join then Prune (equivalent to a Make-before-break) is
> prevents losses at the expense of duplicates resulting from loops (the
> case depicted here above)
> 
> - case ii) Prune then Join (equivalent to a Break-before-make) prevents
> loops at the expense of disruption in packet sequences
> 
> There is to my knowledge no serious consideration about this tradeoff.
> All figures seem to show that case i) is actually the preferred
> execution mode but no network-wide "avoidance" technique beside the RPF
> (local-avoidance technique) is proposed.
> 
>>> 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 for the comment.  We will add the clarification in the
>> next rev of the draft and hope to submit soon.
> 
> OK. Let's see also what the revision proposes.
> 
> Thanks,
> -dimitri.

-- 
Yiqun

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 10 Feb 2010 11:31:17 +0100

Correct but case 1.b I initially described (same Source S, same Group G
assigned to different MT-ID values as afaik there is no MT-ID value
setting coordination) combined with the rule specified in the revisited
v03 Section 4.2.1:

"use the topology identified by the selected PIM MT-ID to perform
 RPF lookup for the (*,G)/(S,G) entry unless a different topology
 is specified by a local configuration."

can result in keeping this "transient situation" permanent.

To the question: "do you plan to write a separate ID and suggest some
proposed solution?" that's the plan but we need also to agree on the
"problem description" in order to reach agreement on the scope and type
of solution.
 
Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ycai
> Sent: Tuesday, February 09, 2010 7:40 PM
> To: PAPADIMITRIOU Dimitri; Mike McBride (mmcbride); [email-masked]
> Subject: Re: [pim] pim wg mtg minutes Hiroshima
> 
> Dimitri,
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>