Subject: [rbridge] Question on draft-ietf-trill-rbridge-mib-07

From: Mahesh Akula <[email-masked]>
Date: Thu, 5 Apr 2012 18:16:59 -0700

Hi Anil,

I have one question on draft-ietf-trill-rbridge-mib-07.

In rbridgeSnoopingPortTable, I see that we are maintaining for each Rbridge
port, list of IP Multicast Router addresses connected to that port.

>From what I understand from RFC 6325 section
4.7<http://tools.ietf.org/html/rfc6325#section-4.7> ,
all we care is for each port, are there IP multicast routers connected and
their types( ipv4/ipv6/both), so that we can pass along reports
accordingly.  It looks to me all we need is to maintain just one enum per
port with values (ipv4/ipv6/both).

Why do we need to maintain all IP Multicast router addresses in TRILL MIB?
Any other reasons?

Regards,
Mahesh
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Anil Rijhsinghani <[email-masked]>
Date: Thu, 5 Apr 2012 21:43:53 -0400

Mahesh,

As the INDEX is rbridgeBasePort, there is a unique entry per port and we are only maintaining per port the knowledge that there is at least one multicast router, either v4 or v6, and which one it is (useful from a management perspective). So it should not return a list of all IP multicast router addresses connected per port. The total number of entries in the table would be the number of Rbridge ports on which snooping has detected an IP multicast router.

Regards,
Anil

On Apr 5, 2012, at 9:16 PM, Mahesh Akula wrote:

> In rbridgeSnoopingPortTable, I see that we are maintaining for each Rbridge port, list of IP Multicast Router addresses connected to that port.
>  
> From what I understand from RFC 6325 section 4.7 , all we care is for each port, are there IP multicast routers connected and their types( ipv4/ipv6/both), so that we can pass along reports accordingly.  It looks to me all we need is to maintain just one enum per port with values (ipv4/ipv6/both).
>  
> Why do we need to maintain all IP Multicast router addresses in TRILL MIB? Any other reasons?
>  
> Regards,
> Mahesh
>  
>

---

From: Mahesh Akula <[email-masked]>
Date: Thu, 5 Apr 2012 19:08:49 -0700

Hi Anil,

But there can be both ipv4/ipv6 multicast routers attached to that link
right?

>>   IP multicast data SHOULD only be sent on links where there is either
   an IP multicast router for that IP type (IPv4 or IPv6) or ..

As the idea is to forward the data (and reports) only if there is a router
for that specific IP type, it looks to me it is more important to capture
whether only one IP type of multicast router is attached or both.

Also, as there can be more than one multicast router of each IP type
attached, capturing only one of them may not serve any purpose IMO.

Regards,
Mahesh

On Thu, Apr 5, 2012 at 6:43 PM, Anil Rijhsinghani <[email-masked]> wrote:

> Mahesh,
>
> As the INDEX is rbridgeBasePort, there is a unique entry per port and we
> are only maintaining per port the knowledge that there is at least one
> multicast router, either v4 or v6, and which one it is (useful from a
> management perspective). So it should not return a list of all IP multicast
> router addresses connected per port. The total number of entries in the
> table would be the number of Rbridge ports on which snooping has detected
> an IP multicast router.
>
> Regards,
> Anil
>
> In rbridgeSnoopingPortTable, I see that we are maintaining for each
> Rbridge port, list of IP Multicast Router addresses connected to that port.
>
> From what I understand from RFC 6325 section 4.7<http://tools.ietf.org/html/rfc6325#section-4.7> ,

---

From: Anil Rijhsinghani <[email-masked]>
Date: Fri, 6 Apr 2012 08:23:28 -0400

On Apr 5, 2012, at 10:08 PM, Mahesh Akula wrote:

> As the idea is to forward the data (and reports) only if there is a router for that specific IP type, it looks to me it is more important to capture whether only one IP type of multicast router is attached or both.

After reading the protocol section again, I think I agree with you here and will accommodate the above in yet another revision.
 
> Also, as there can be more than one multicast router of each IP type attached, capturing only one of them may not serve any purpose IMO.

Capturing one is better than all of them, which I think was one of your original issues in this thread. The thought here was to record at least one so that a manager can do some correlation when there's multicasting going on. If a multicast is being forwarded, some additional data on why it's being forwarded would be useful. A switch need only know of one alive on a port, in order to continue multicasting on that port. You're not normally going to have lots of multicast routers on every link in any case. Given your first suggestion, we could add rbridgeSnoopingPortAddrType to the INDEX, thus allowing a single object to be returned per instance: the address of the router. What do you think?

Regards,
Anil

---

From: Mahesh Akula <[email-masked]>
Date: Fri, 6 Apr 2012 14:45:58 -0700

Hi Anil,

On Fri, Apr 6, 2012 at 5:23 AM, Anil Rijhsinghani <[email-masked]> wrote:

> > As the idea is to forward the data (and reports) only if there is a
> router for that specific IP type, it looks to me it is more important to
> capture whether only one IP type of multicast router is attached or both.
>
> After reading the protocol section again, I think I agree with you here
> and will accommodate the above in yet another revision.
>
> Capturing one is better than all of them, which I think was one of your
> original issues in this thread. The thought here was to record at least one
> so that a manager can do some correlation when there's multicasting going
> on. If a multicast is being forwarded, some additional data on why it's
> being forwarded would be useful. A switch need only know of one alive on a
> port, in order to continue multicasting on that port. You're not normally
> going to have lots of multicast routers on every link in any case. Given
> your first suggestion, we could add rbridgeSnoopingPortAddrType to the
> INDEX, thus allowing a single object to be returned per instance: the
> address of the router. What do you think?
>

[MA]:  I personally still feel that we should just maintain only enum per
port (ipv4/ipv6/both). Because If there are multiple routers attached, the
value of the address will be non deterministic IMO.  But I dont see any
harm in having it otherwise.

Thank you,

Regards,
Mahesh