Subject: [trill] Query on rbridgeSnoopingPortEntry in draft-ietf-trill-rbridge-mib

From: wenyu zou <[email-masked]>
Date: Mon, 8 Oct 2012 20:52:20 +0800

Hi Authors,
    I have a questions about rbridgeSnoopingPortEntry in
draft-ietf-trill-rbridge-mib, which is indexed by rbridgeBasePort. For
one port, it maybe have many Multicast Routers in different VLANs. The
current structure of rbridgeSnoopingPortEntry set a limitation that
there is only one Multicast Router for one port. Why don't
rbridgeSnoopingPortEntry indexed by rbridgeVlanIndex like
rbridgeSnoopingAddrEntry?

Thanks.
Regards,
wenyu

---

From: Anil R <[email-masked]>
Date: Fri, 12 Oct 2012 10:23:49 -0400

Hi Wenyu,

The purpose of rbridgeSnoopingPortTable is only to show which RBridge ports have at least one multicast router connected, and hence need to be included in forwarding of multicast packets. Exactly how many multicast routers are there on a port is not important for this table. The purpose is not to give a list of multicast routers, but a list of ports on which at least one multicast router has been detected. You need only one multicast router on a port, for that port to be included in the list of ports where IP multicast is forwarded. Hence, the value of the IP address in this table can be any one of the routers that has been detected on that port.

This is not a IP Multicast snooping MIB, so you will not have all IP Multicast snooping information included in this group. You will get only the multicast snooping information relevant to the operation of a TRILL switch/RBridge.

Regards,
Anil

On Oct 8, 2012, at 8:52 AM, wenyu zou wrote:

> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: wenyu zou <[email-masked]>
Date: Sun, 14 Oct 2012 22:20:17 +0800

Hi Anil,
    1. If the rbridgeSnoopingPortAddr can be any one of the routers
that has been detected on that port, I think it's not useful and could
be deleted from the rbridgeSnoopingPortTable.
    2. Although the IP address of the routers is not important, what's
about the vlan information? Is it necessary to show the vlan
information of the routers? In RFC 6325, Section 4.5.3, paragraph 2,
"Further pruning SHOULD be done in two cases ... Each of these cases
is scoped per VLAN". So I think the rbridgeSnoopingPortEntry should be
indexed by port and vlan informations.
   3. rbridgeSnoopingPortAddrType is InetAddressType. What's the value
of rbridgeSnoopingPortAddrType if there are both IPv4 and IPv6 routers
on one port?
In RFC 6326, Section 2.3.6, the M4 or M6 flag can be set seperately.
So there is three possiblilities on one port: only IPv4 router, only
IPv6 routers, both IPv4 and IPv6 routers.

Thanks.
Regards,
wenyu

2012/10/12, Anil R <[email-masked]>:
> Hi Wenyu,
>
> The purpose of rbridgeSnoopingPortTable is only to show which RBridge ports
> have at least one multicast router connected, and hence need to be included
> in forwarding of multicast packets. Exactly how many multicast routers are
> there on a port is not important for this table. The purpose is not to give
> a list of multicast routers, but a list of ports on which at least one
> multicast router has been detected. You need only one multicast router on a
> port, for that port to be included in the list of ports where IP multicast
> is forwarded. Hence, the value of the IP address in this table can be any
> one of the routers that has been detected on that port.
>
> This is not a IP Multicast snooping MIB, so you will not have all IP
> Multicast snooping information included in this group. You will get only the
> multicast snooping information relevant to the operation of a TRILL
> switch/RBridge.
>
> Regards,
> Anil
>

---

From: Anil R <[email-masked]>
Date: Mon, 15 Oct 2012 16:29:31 -0400

Wenyu,

> indexed by port and vlan informations.

Agree with you, adding VLAN to the index would make sense here. Thanks for pointing it out.
This will be added in the next revision.

Regarding your comments 1 and 3, let me explain the reasoning behind specifying any one of the addresses. What a TRILL switch cares about, is knowing whether there is at least one IP multicast router behind that port (and vlan, as you point out). If so, it forwards multicast. Now let's say that the switch is forwarding multicast to a port/vlan where it really shouldn't be, according to a network manager. Apparently, there must be at least one IP multicast router there causing the multicast stream to be forwarded. This object will give you such information (tell you about at least one IP multicast router which is causing that leaking of multicast). The manager could then go figure out where it is, remove it, and then come back and see if the multicast leaking stopped. If not, go back to step 1. This was preferred, rather than specify a list of multicast routers, which is not a TRILL function.

Regards,
Anil

---

From: wenyu zou <[email-masked]>
Date: Tue, 16 Oct 2012 23:05:46 +0800

Hi Anil,

> This will be added in the next revision.
    Thanks for your agreement.

> Regarding your comments 1 and 3, let me explain the reasoning behind
> specifying any one of the addresses. What a TRILL switch cares about, is
> knowing whether there is at least one IP multicast router behind that port
> (and vlan, as you point out). If so, it forwards multicast. Now let's say
> that the switch is forwarding multicast to a port/vlan where it really
> shouldn't be, according to a network manager. Apparently, there must be at
> least one IP multicast router there causing the multicast stream to be
> forwarded. This object will give you such information (tell you about at
> least one IP multicast router which is causing that leaking of multicast).
> The manager could then go figure out where it is, remove it, and then come
> back and see if the multicast leaking stopped. If not, go back to step 1.
> This was preferred, rather than specify a list of multicast routers, which
> is not a TRILL function.

    There is not a TLV(or sub-TLV) including addresses of multicast
routers. And the manager could work with both rbridgeSnoopingPortEntry
and IP Multicast snooping MIB. With rbridgeSnoopingPortEntry, he can
see the type of the routers. And with IP Multicast snooping MIB, he
can see the address of routers detailly. This is my reason of comment
1.
    If rbridgeSnoopingPortAddr can be deleted, the problem in comment
3 is coming up. RbridgeSnoopingPortAddrType is InetAddressType, and
it's value can not include the situation that both IPv4 and IPv6
routers on one port. Shall we define a new set of value for
rbridgeSnoopingPortAddrType?

Thanks.
Regards,
wenyu

2012/10/16, Anil R <[email-masked]>:
> Regarding your comments 1 and 3, let me explain the reasoning behind
> specifying any one of the addresses. What a TRILL switch cares about, is
> knowing whether there is at least one IP multicast router behind that port
> (and vlan, as you point out). If so, it forwards multicast. Now let's say
> that the switch is forwarding multicast to a port/vlan where it really
> shouldn't be, according to a network manager. Apparently, there must be at
> least one IP multicast router there causing the multicast stream to be
> forwarded. This object will give you such information (tell you about at
> least one IP multicast router which is causing that leaking of multicast).
> The manager could then go figure out where it is, remove it, and then come
> back and see if the multicast leaking stopped. If not, go back to step 1.
> This was preferred, rather than specify a list of multicast routers, which
> is not a TRILL function.
>
> Regards,
> Anil
>
>