Subject: [pim] One question on RFC 4601

From: Bharat Joshi <[email-masked]>
Date: Mon, 30 Dec 2013 04:43:30 +0000

Hi,

      I was reading up PIM Assert mechanism in RFC 4601 once again. I am not sure if its worth mentioning but I decided to do it because we are working on revising PIM protocol standard and if required it can be handled there.

      In section 3.6, 'Multi-Access Transit LANs', its mentioned that multi-access LANs can cause complication for three reasons in the following statement:

The overview so far has concerned itself with point-to-point transit
links.  However, using multi-access LANs such as Ethernet for transit
is not uncommon. This can cause complications for three reasons:

      And then it defines the three reasons where main issue is MRIB mismatch in two downstream routers. I was wondering that will not we hit upon the same issue with local membership. Let me give an example.

      Let us assume there are three routers where R1 and R2 is upstream and R3 is a downstream router. These routers are connected to a LAN and this LAN also has local hosts. Let us assume R1 is elected as DR. Let us assume that for a (*,G) membership, R3 selects R2 as the upstream router. Now in case a local host is interested in (*,G), R1 being the DR will handle it. With this setup, both R1 and R2 will setup the multicast tree for (*,G) and forward the traffic to the LAN. So we again hit the same condition as defined in the section 3.6.

      Same thing can happen when local host join (S,G) or R3 joins (S,G) and local host join (*,G) etc.

      My question is, is this correct to use 'three reasons' causing this complication when there could be more reasons like I mentioned above?

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
**************** 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***

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Mon, 30 Dec 2013 05:04:43 +0000

Think of the dr function as a separate logical downstream router and you will find that your example is just another instance of multiple downstram routers.

Sent from my Samsung Captivate Glide on AT&T

Bharat Joshi <[email-masked]> wrote:
Hi,

Regards,
Bharat Joshi
_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 30 Dec 2013 05:11:37 +0000

Yes. I agree. It can be seen as just another instance of what is already mentioned in that section.

Do you think it will help if we add some text here to explain this?

Regards,
Bharat Joshi
http://bite-the-bytes.blogspot.com/
________________________________________
From: Toerless Eckert (eckert) [[email-masked]]
Sent: Monday, December 30, 2013 10:34 AM
To: Bharat Joshi; [email-masked]
Subject: RE: [pim] One question on RFC 4601

Regards,
Bharat Joshi

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Mon, 30 Dec 2013 05:40:34 +0000

I am always a fan of a lot of explanations, but ietf protocol specs are usually terse, and a lot of folks will argue about verbosity in standards specs. After all, one wants to review and aprove the whoole doc, so those folks have a point.

In ?1993? There where both a pim-v1 protocol draft and a pim architecture draft. The architecture draft died out unfortunately. I think it would be a great idea to revive it and put all explanatory stuff beyond whats necessary in the protocol spec into such a pom arch rfc.

Regards,
Bharat Joshi

Regards,
Bharat Joshi