Subject: [magma] MLDv2 fast leave (section A.2)

From: KASHIMA Hiroaki <[email-masked]>
Date: Mon, 23 Feb 2004 17:32:00 +0900

Hi,

I have one more question.

Does anyone have made the method to implement "fast leave" 
(mentioned in A.2 item 1) to supress the source-deletion timer 
LLQT * Robustness Variable?

Please teach me details if the method exists.

Thanks in advance.
--
KASHIMA, Hiroaki <[email-masked]>
Software Development Department-II,
IP system Division, Fujitsu Ltd

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

---

From: "Raja K" <[email-masked]>
Date: Mon, 23 Feb 2004 20:11:04 +0530

Hello Kashima,

As per my understanding, the fast leave feature is interface specific.

a)In MLDv1/MLDv2 router, fast leave can be enabled on all those interfaces
having single host connected. So when Done message comes instead of
suppressing the source-deletion timer to LLQT * robustness, we can stop
forwarding as it is from the last listener and Updates Multicast Routing
Protocol about it.

b)In MLDv2 router, fast leave can also be enabled on all other interfaces
having more than single host connected,If all hosts do MLDv2, then the
routers can keep track of each host that is a listener of the
Multicast-Address, and can stop forwarding as soon as it receives a Done
message from the last listener and Updates Multicast Routing protocol about
it.

Hope , i'm able to answer your question.

Regards
Raja Kambhampati,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
KASHIMA Hiroaki
Sent: Monday, 23 February 2004 2:02 PM
To: [email-masked]
Subject: [magma] MLDv2 fast leave (section A.2)

Hi,

Thanks in advance.

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: "Raja K" <[email-masked]>
Date: Mon, 23 Feb 2004 20:11:04 +0530

Hello Kashima,

Regards
Raja Kambhampati,

-----Original Message-----

Hi,

Thanks in advance.

---

From: KASHIMA Hiroaki <[email-masked]>
Date: Tue, 24 Feb 2004 11:26:38 +0900

Thank you very much, Raja.

I forgot to say my main target... I want to know about MLDv2.

> message from the last listener and Updates Multicast Routing protocol about

Thank you.  That is almost same as I read and imagined.

Then...  are the below points correct?

- We can handle IS_IN() and TO_IN() with same method
  because we can find the change of each listener
  with checking IS_IN().

- same on IS_EX() and TO_EX().

- sendQ(MA,A) is still necessary for neighboring MLDv2 routers.

- IS_IN() and IS_EX() also cause the sendQ()
  as same as TO_IN() and TO_EX().

- When the interface is INCLUDE(X) and receive BLOCK(A) from the listener L,
  we can immediately delete (A-B) that is only reported from L.
  SendQ(MA, A-B: reported from other than L) is necessary.
  SendQ(MA, A-B: reported only from L) is not necessary.

- same as EXCLUDE(X,Y) and BLOCK(A).
--
KASHIMA, Hiroaki <[email-masked]>
Software Development Department-II,
IP system Division, Fujitsu Ltd

---

From: KASHIMA Hiroaki <[email-masked]>
Date: Tue, 24 Feb 2004 11:26:38 +0900