headers
Dr G Fairhurst | 2 Dec 2002 21:16
Picon
Picon

Re: UDLR: Comments on draft-ietf-udlr-experiments-00


Achmad Husni Thamrin wrote:
> 
> > ---
> > Section  4.5.1. DR Election
> >
> > The use of the word "listener", should perhaps be "source" ???
> 
> "listener" is the intended word.
> 
> The DR has two tasks:
>  - send register messages to the RP
>  - originate Join/Prune messages to the upstream router toward the
>    RP/source if a listener exists on the network segment.

Ah... OK. (I think if you fix the scenarios this is clear!)

> 
> In my understanding of Scenario D, there should be no multicast listener
> on the UDL segment, correct?
> 
> The paragraph about DR election states that "if a multicast listener
> exists ...", which is not the case for the Scenario D.
> The last sentence of the paragraph is:
>    In the Scenario 5, DR election result is not important as all UDL
>    nodes are multicast routers.
> There is a typo there: "Scenario 5" should be "Scenario D".
> I guess I should change the text into "if a multicast listener exists as
> in the Scenario A and B..." to make it clear.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
William StanisLaus | 18 Dec 2002 06:50

Comments on draft-ietf-udlr-experiments-00

Hi

Comment/Clarification on UDLR-experiments-00
--------------------------------------------

Section 3.1.1 Scenario 3. 
------------------------
	Recevier needs a receviers hardware address.

Instead of doing Bridging in Feed for sending a packet from Receiver1 to 
Receiver2 i.e. Destination MAC address in MPE is Receiver2 MAC. Why don't we 
implement IP Fast Forwarding i.e. Destination IP address is Receiver2 IP, but 
Destination MAC address in MPE is Default Feed MAC.

Since anyway the Packet which has to send to Reciever2 has to pass through 
Default Feed. why don't we consider Default Feed as next-hop !!!

Advantages :
-----------
1. Reduces the possibility of IP packets getting dropped, since Receiver2 MAC 
not resolved. Since sending a ARP request (DVB interface) to receiver2 and 
waiting is really expensive with respect to IP outgoing Queue.

2. ARP Server implementation in Feed is fine... but not sure that all the 
receivers in the network are configured with this Feed as default Feed.

Disadvantages :
--------------
1. Performance with Bridging is relatively better than IP Fast Forwarding.
(Continue reading)

Permalink | Reply | 0 comments |
headers
William StanisLaus | 18 Dec 2002 10:01

RE: Comments on draft-ietf-udlr-experiments-00

Hi,
     Further, just thinking about FUMAC. As of now we define, FUMAC can be a 
simple transformation from IP to MAC, otherwise has to be resolved through 
ARP.

But just imagine, Receivers cannot contact other Receivers Directly, has to go 
through Feed as i said below. And if we agreed with IP Fast Forwarding, the 
only think left is FUMAC. In case the FUMAC is not through simple 
transformation from IP to MAC, I have a simple and silly suggestion :)

* Lets reserve a Multicast MAC for UDLR (Not DTCP Multicast IP) and use it in 
all Feed's (Only in Feeds) i.e. the Feed has to subscribe for this MAC in 
their interface driver. By doing so, feed can receive packets for which it is 
subscribed and process it. If the packet is for itself it processes it, 
otherwise it Forwards or Fast Forwards the packet based on the Dest. IP 
address.

Best Regards,
William.

>===== Original Message From William StanisLaus <williams77 <at> mailandnews.com> 
=====
>Hi
>
>
>Comment/Clarification on UDLR-experiments-00
>--------------------------------------------
>
>Section 3.1.1 Scenario 3.
>------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane