Subject: RE: [pim] I-D ACTION:draft-ietf-pim-rpf-vector-02.txt

From: "bharat_joshi" <[email-masked]>
Date: Tue, 7 Mar 2006 21:01:08 +0530

> This document describes a use of the PIM Join Attribute as defined in
> draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which
> enables PIM to build multicast trees through an MPLS-enabled network,
> even if that network's IGP does not have a route to the source of the
> tree.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pim-rpf-vector-02.txt

Hi,

    I have couple of comments and suggestions on this document:

1) In section 2, typo in last line of first paragraph:

"cannot determine where the send the Join" should be "cannot determine
where to send the Join"

2) In section 2.2, Can we explicitly mention that we mean C-RP
advertisement when we mention BSR messages?

3) In section 2.2, typo: "solution has the developed in BSR" should be
"solution has to be developed in BSR".

4) In section 2.3.1, typo: "will forwarding the Join along the Vector"
should be "will forward the join along the vector".

5) In section 2.3.1, last paragraph, typo: "Whether an ttribute" should
be "Whether an attribute".

6) I think it will be good to add an example for finding out if edge
router need to include this attribute.

7) In section 2.3.2, I did not understand the last statement of the
paragraph which is "In the absence of periodic refreshment,..." Could
you please elaborate a little bit more?

8) This document does not contain a section for "Security
Consideration".

9) I had sent some comments on join-attributes some time back. Did I
miss a response for those questions?

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 07 Mar 2006 16:12:42 +0000

bharat_joshi wrote:
[...]
> "solution has to be developed in BSR".

I have problems understanding this section. But first of all, I believe
it should say BSR messages (the messages originated by the BSR). The
C-RP-advs are unicast messages, so I don't see an issue for them.

The section says:

2.2.  Attribute and Bootstrap messages

   The RPF vector does not apply to BSR bootstrap messages.  To allow
   BSR messages to be forwarded across a core where the RP IP address is
   not routable in the core a solution has the developed in BSR.

BSR does not rely on RPs at all. Should it say BSR address and not RP
address? BSR messages are flooded and relies on RPF of BSR address, so
that makes sense.

We should perhaps not solve the BSR case now, but I'm wondering what the
ideal behaviour would be. Should a BSM arriving at one exit point (that
satisfies RPF) be forwarded to all the other exit points, or only a
subset? Is it an issue if BSMs are flooded throughout the core? Since
the core routers should not care about the content of the BSMs, the best
solution is perhaps to encapsulate the BSMs...

Stig

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 8 Mar 2006 17:21:21 +0100

Hi Bharat,

Thx for the comments, see inline.

> router need to include this attribute.

This is really up to the implementer to decide and outside of the scope 
of this draft.

> you please elaborate a little bit more?

The vector information is advertised along with the PIM join. PIM joins 
are send periodically to refresh the state. So if the PIM state 
expires, the vector information needs to expire as well.

> miss a response for those questions?

I think Arjen submitted a new version of the draft Monday, maybe you 
can go through it and see if your comments got addressed.

Thx,

Ice.

> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended 
> solely for the use of the addressee(s). If you are not the intended 
> recipient, please notify the sender by e-mail and delete the original 
> message. Further, you are not to copy, disclose, or distribute this 
> e-mail or its contents to any other person and any such actions are 
> unlawful. This e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not liable for any 
> damage you may sustain as a result of any virus in this e-mail. You 
> should carry out your own virus checks before opening the e-mail or 
> attachment. Infosys reserves the right to monitor and review the 
> content of all messages sent to or from this e-mail address. Messages 
> sent to or from this e-mail address may be stored on the Infosys 
> e-mail system.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 8 Mar 2006 17:28:17 +0100

Hi Stig,

> address? BSR messages are flooded and relies on RPF of BSR address, so

Yes, I think that makes more sense.

> solution is perhaps to encapsulate the BSMs...

Right, I don't really want to solve the BSR case in this draft. 
Encapsulation seems like a good way to go, but I'll leave that to the 
BSR experts to figure out ;-)

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 8 Mar 2006 17:21:21 +0100

Hi Bharat,

Thx,

Ice.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 8 Mar 2006 17:28:17 +0100

Hi Stig,

Thx,

Ice.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 16 Mar 2006 14:21:51 +0100

One question that just popped into my head, is whether it should be 
possible to have multiple rpf vector attributes or not. Maybe it's good 
only allowing one, in which case it should be made clear in the draft I 
think. The only hint at the moment is the sentence: A router which 
discards a Vector Attribute may of course insert a new Vector Attribute.

Theoretically speaking I can think of uses for having multiple where you 
basically have a stack where only the first attribute is used until you 
reach that router, which then pops it off and then you continue using 
the next... One theoretical example, would be having two core networks, 
one within the other. Do you want to allow this? Of course you may then 
run into some interesting issues if you receive joins with different rpf 
stacks from different neighbours etc...

Maybe this has been discussed before. Anyway, I think the draft should 
make it clear.

Stig

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Mar 2006 15:49:14 +0100

Hi Stig,

> possible to have multiple rpf vector attributes or not. Maybe it's 
> good only allowing one, in which case it should be made clear in the 
> draft I think. The only hint at the moment is the sentence: A router 
> which discards a Vector Attribute may of course insert a new Vector 
> Attribute.

It should be possible to include multiple vectors. There is nothing 
that prevents it in the current draft and I like to keep this 
flexibility.

>
> Theoretically speaking I can think of uses for having multiple where 
> you basically have a stack where only the first attribute is used 
> until you reach that router, which then pops it off and then you 
> continue using the next... One theoretical example, would be having 
> two core networks, one within the other. Do you want to allow this? Of 
> course you may then run into some interesting issues if you receive 
> joins with different rpf stacks from different neighbours etc...

That should not be a problem. You don't mix attributes from different 
neighbors. The attributes drafts describes what to do. In case of 
conflicts you use the set of attributes from the lowest PIM neighbor. 
When that neighbor goes away you go and use the attributes from the 
other.

Thx,

Ice.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Mar 2006 15:14:26 +0000

IJsbrand Wijnands wrote:
[...]
> When that neighbor goes away you go and use the attributes from the other.

Oh ok. I think the problem is the definition of conflict. I was thinking
conflict meant something like having different values for one specific
attribute, or attributes that somehow could not co-exist. But you mean
that you have a conflict if the list of attributes and their values are
not identical, right?

Also, is there a conflict if you get attributes from one downstream
neighbour and not from another?

It seems the word conflict should be replaced by some longer text making
this clearer.

I would have liked "conflict" to be less strict than it seems you want.
I have some thoughts on uses of attributes that may require a more
relaxed interpretation. OTOH I'm not sure how exactly that should work.

Stig

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 21 Mar 2006 17:56:31 +0100

Hi Stig,

> that you have a conflict if the list of attributes and their values are

Yes. But we don't really check/compare the attributes per downstream 
PIM neighbor. You'll just use the attributes from one specific 
downstream neighbor, the lowest IP address. Wether they are the same or 
different, we don't really care. I agree with you that the term 
conflict is a bit off. The conflicts section describes how to deal with 
multiple attribute send by downstream PIM neighbors. We took a simple 
approach to only use the attributes from one downstream PIM neighbor 
and not try to compare them. This is the default way to handling 
duplicate attributes. But, an individual attribute may override the 
default way of handling duplicates. For example, downstream statics 
from different PIM neighbors may be add together and send upstream.

Thx,

Ice.