Subject: [pim] WGLC pim-rpf-vector

From: Mike McBride <[email-masked]>
Date: Fri, 21 Sep 2007 10:39:21 -0700 (PDT)

Today begins a two week wglc for draft-ietf-pim-rpf-vector-04. Please 
review this draft and respond.

http://ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-04.txt

thanks,
mike

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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Sep 2007 06:41:00 -0700

Mike,

> http://ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-04.txt

What is the setting of the F bit for the RPF Vector TLV ?

Yakov.

---

From: "Greg Shepherd" <[email-masked]>
Date: Mon, 24 Sep 2007 13:47:01 -0700

Just a couple editing notes:

Introduction, 3rd graph, line 9: I believe "routes" should be "routers".

Section 3. The entire section is repeated.

Greg

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 25 Sep 2007 10:46:05 +0200

Yakov,

> What is the setting of the F bit for the RPF Vector TLV ?

As it is now its up to the implementor to decide.

Thx,

Ice.

---

From: Su Haiyang <[email-masked]>
Date: Tue, 25 Sep 2007 17:26:01 +0800

Dear All,
  I don't know why the draft(draft-ietf-pim-join-attributes-) that introduce
a new PIM Hello option to guarantee the compatibility and define how to
extend PIM join message precisely to include RPF vector is still working in
progress, the RPF vector draft is put into last call first instead?
Hope to combine them together.
Suhaiyang
-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 9:41 PM
To: Mike McBride
Cc: [email-masked]
Subject: Re: [pim] WGLC pim-rpf-vector

Mike,

Yakov.

---

From: Mike McBride <[email-masked]>
Date: Tue, 25 Sep 2007 07:13:05 -0700 (PDT)

> Hope to combine them together.

pim-join-attributes has already passed wglc and has been forwarded to the 
AD's for IESG processing. They just haven't updated the draft status.

mike

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 25 Sep 2007 17:54:23 +0200

>> http://ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-04.txt
Hi,

I have  a question concerning the use of this vector attribute in the
case of several egress and ingress points for a channel/group.
Assume an AS with two egress routers E1 and E2 toward a source S
Assume also two distinct ingress routers I1 and I2 receiving PIM joins
toward S
It is possible that the BGP next hop towards S is E1 for I1 and E2 for I2.
In practice, this will lead to 2  (S,G) subtrees inside the AS, one
rooted at E1, the other at E2

Now assume that these 2 subtrees are not disjoint, for example a route
from I1 to E1 has a common
node R with a route from I2 to E2 (I say A route and not the route since
there may be several equal cost internal routes).
This seems possible per the BGP  bestpath selection algorithm if routes
I1,E1  I1,E2  I2,E1 and I2,E2
have the same length.

What should be the behavior of this common node R? the first join (say
toward E1 is ) forwarded
and the second one toward E2 is stopped at R ? (grafting the E2 subtree
on the E1 subtree).
Should R keep both these vector attributes (in case E1 becomes 
unreachable  for example)

Jean-Jacques

---

From: Su Haiyang <[email-masked]>
Date: Wed, 26 Sep 2007 10:01:36 +0800

It's possible that disjoined subtrees will be established if only leaf node
knows the entire topology. I think the author of the draft should address
this issue.
Regarding the behavior of the common node R, join attribute draft give the
solution, i.e. R prefer to accept RPF vector coming from the PIM neighbor
with the smallest IP address, but R will also maintain the copy of RPF
vector coming from all other PIM neighbor in case the smallest PIM neighbor
is going down.
     ( Edge A1 )                   ( Edge B1 )---- [R1]
      /           \          /
     /             \        /
   [S]              ( R )
     \             /        \
      \           /          \
       ( Edge A2 )            ( Edge B2 )---- [R2]

SuHaiyang

-----Original Message-----
From: Jean-Jacques Pansiot [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2007 11:54 PM
To: [email-masked]
Subject: Re: [pim] WGLC pim-rpf-vector

Hi,

Jean-Jacques

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 26 Sep 2007 15:24:13 +0200

Hi Jean-Jacques,

This is covered in draft-ietf-pim-join-attributes-03 section 3.4.

There is a generic way to deal with conflicting attributes, which  
basically applies to all future attributes. This problem is not  
specific to the vector attribute.

Thx,

Ice.

On 25 Sep 2007, at 17:54, Jean-Jacques Pansiot wrote:

>
>>> Today begins a two week wglc for draft-ietf-pim-rpf-vector-04.  
>>> Please review this draft and respond.
>>>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 26 Sep 2007 15:27:54 +0200

Hi Su,

> knows the entire topology. I think the author of the draft should  

In the case only one of the leafs provides the RPF vector attribute,  
then there is no conflict. Router R will use the only vector it  
received. If that leaf goes away, then bad luck, the tree is broken.  
There is nothing we can do about that.

Thx,

Ice.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 26 Sep 2007 10:36:09 -0700

Ice,

> As it is now its up to the implementor to decide.

Which means that the routers just ignore the F bit. Correct ?

It would be useful to spell out that if a router supports a particular
TLV, (e.g., the RPF Vector TLV) then the router MUST ignore the value
of the F bit carried by the TLV.

Yakov.

---

From: Su Haiyang <[email-masked]>
Date: Thu, 27 Sep 2007 10:14:06 +0800

Dear All,
 There is no any involvement in the draft with the following scenarios.
1. Which kind of prune, with rpf vector or without rpf vector should be
triggered to the old RPF Vector upstream when route changes happen?
2. If an upstream router first received a PIM join with RPF Vector and then
received a prune without RPF vector, what should the upstream router do?
Choose the RPF vector coming from next smallest PIM neighbor or ignore that
prune?
3. In a multi-access network, a route should do join suppression based on
(S, G, RPT-bit, Wildcard-bit, RPF vector) (It seems like maintaining such
information at the downstream router is a tough work) or all routers give up
the join suppression mechanism automatically if PIM join with RPF vector is
received?
4. In a multi-access network, if a new router which doesn't support PIM
join-attribute hello option, what should all other routers do, which may
already establishes multicast tree by PIM joins with RPF vector?
5. What should the route do if it receives a join with RPF vector and then
receive a join without RPF vector, maybe coming from the same downstream
neighbor or a different neighbor?
6. What should the router do, if it receives a join with RPF vector and then
it learns the route to the source, unfortunely the upstream router chosed by
RPF vector is differently with it's own nexthop to S? 

Su Haiyang

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Thursday, September 27, 2007 1:36 AM
To: IJsbrand Wijnands
Cc: Mike McBride; [email-masked]
Subject: Re: [pim] WGLC pim-rpf-vector

Ice,

Yakov.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 27 Sep 2007 16:26:28 +0200

Su,

> triggered to the old RPF Vector upstream when route changes happen?

This is not specific to a vector attribute and this draft, this is  
generic and applies to any attribute type. For that reason it is in  
draft-ietf-pim-join-attributes-03 section 3.5.

> Choose the RPF vector coming from next smallest PIM neighbor or  

This is also not specific to vectors. The behavior is also documented  
in draft-ietf-pim-join-attributes-03 section 3.5.

> the join suppression mechanism automatically if PIM join with RPF  

Join suppression is done based on the normal procedures as described  
in the PIM draft, attributes are not part of it.

> already establishes multicast tree by PIM joins with RPF vector?

This is not specific to RPF vector and is described in draft-ietf-pim- 
join-attributes-03 section 3.3. If one of the PIM neighbors on a LAN  
does not support attributes, everybody must stop sending them. This  
means the attributes will time out after 3 minutes.

> neighbor or a different neighbor?

This is not specific to the RPF vector attribute.  See draft-ietf-pim- 
join-attributes-03 section 3.4. A PIM join without any attributes is  
an implicit prune of the attributes. I would say that is obvious.

> RPF vector is differently with it's own nexthop to S?

It is clearly stated in the vector draft (section 2.3.2) that it must  
use the vector address when it is present.

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 27 Sep 2007 16:33:22 +0200

Yakov,

> of the F bit carried by the TLV.

This is how it is documented in the attributes draft:

F bit, Forward Unknown TLV.  If this bit is set the TLV is forwarded
    regardless if the router understands the Type.

Meaning, if the TLV is unknown, you forward if this bit is set.

I think it is obvious that if the TLV is known, this bit has no  
relevance.

Thx,

Ice.

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Tue, 25 Sep 2007 10:03:53 +0200

Hi,

I have  a question concerning the use of this vector attribute in the 
case of several egress and ingress points for a channel/group.
Assume an AS with two egress routers E1 and E2 toward a source S
Assume also two distinct ingress routers I1 and I2 receiving PIM joins 
toward S
It is possible that the BGP next hop towards S is E1 for I1 and E2 for I2.
In practice, this will lead to 2  (S,G) subtrees inside the AS one 
rooted at E1 the other at E2

Now assume that these 2 subtrees are not disjoint, for example a route 
from I1 to E1 has a common
node R with a route from I2 to E2 (I say A route and not THE route since 
there may be several
equal cost internal routes).
This seems possible per the BGP  bestpath selection algorithm if routes 
I1,E1  I1,E2  I2,E1 and I2,E2
have the same length.

What should be the behavior of this common node R? the first join (say 
toward E1 is ) forwarded
and the second one toward E2 is stopped at R ? (grafting the E2 subtree 
on the E1 subtree).
Should R keep these vector attributes (in case E1 becomes unreachable 
for example)

Jean-Jacques