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

From: ycai <[email-masked]>
Date: Fri, 22 Jan 2010 23:23:42 -0800

Dimitri,

Thanks for the comment.  Some qustion/comment inline.

On 11/29/09 9:16 AM, "PAPADIMITRIOU Dimitri"
<[email-masked]> wrote:

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

Actually,  if the above happens, packets won't really be looped around.  E
would drop those forwarded by C due to RPF.

However, the potential of loops still exist when topologies are
misconfigured and we will provide the text to suggest ways to prevent it.

<snipped>

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

Thanks again.

> 
> 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:
>> 
>> 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
>> _______________________________________________
>> pim mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pim
>> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
Yiqun

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sat, 23 Jan 2010 10:37:06 +0100

Hi, 

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

> misconfigured and we will provide the text to suggest ways to 

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.

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