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

Anil R <anil@charter.net> Mon, 15 October 2012 20:29 UTC

Return-Path: <anil@charter.net>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDD921F8918 for <trill@ietfa.amsl.com>; Mon, 15 Oct 2012 13:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD3rVCsNqALk for <trill@ietfa.amsl.com>; Mon, 15 Oct 2012 13:29:27 -0700 (PDT)
Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by ietfa.amsl.com (Postfix) with ESMTP id DADC921F8916 for <trill@ietf.org>; Mon, 15 Oct 2012 13:29:26 -0700 (PDT)
Received: from imp11 ([10.20.200.11]) by mta21.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20121015202926.IDPE12025.mta21.charter.net@imp11>; Mon, 15 Oct 2012 16:29:26 -0400
Received: from [192.168.1.105] ([66.189.33.199]) by imp11 with smtp.charter.net id BYVR1k00a4Hn1RN05YVRjH; Mon, 15 Oct 2012 16:29:26 -0400
X-Authority-Analysis: v=1.1 cv=Mv9Cy8NsQItTEAHnXr6fCNbI23lcrkmyMeqLv9HU3yU= c=1 sm=1 a=y6CczY8QmW8A:10 a=yUnIBFQkZM0A:10 a=kj9zAlcOel0A:10 a=EiiBzwjGkpP7seHRDOKx7g==:17 a=hOpmn2quAAAA:8 a=48vgC7mUAAAA:8 a=pLiVgfiGzMYCl56jMTMA:9 a=CjuIK1q_8ugA:10 a=hUswqBWy9Q8A:10 a=lZB815dzVvQA:10 a=Twp5AgXOn507d4M3:21 a=CCbv_gVl0yRY5p9d:21 a=EiiBzwjGkpP7seHRDOKx7g==:117
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Anil R <anil@charter.net>
In-Reply-To: <CA+7+8TQSzYpHini5LVSwU1bMe7Vh=oUebTVfNU4fV5Ex4vHRgA@mail.gmail.com>
Date: Mon, 15 Oct 2012 16:29:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CBF4AEF-2AD5-46B0-8DC6-B280C6322036@charter.net>
References: <CA+7+8TSqrW7vuHneeVzyi1g7Wcy9YYuubMV2WecB71po8+1CdA@mail.gmail.com> <6B477636-3892-4666-AE8B-3D6BAE8A917D@charter.net> <CA+7+8TQSzYpHini5LVSwU1bMe7Vh=oUebTVfNU4fV5Ex4vHRgA@mail.gmail.com>
To: wenyu zou <nkzouwenyu@gmail.com>
X-Mailer: Apple Mail (2.1283)
Cc: trill@ietf.org
Subject: Re: [trill] Query on rbridgeSnoopingPortEntry in draft-ietf-trill-rbridge-mib
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2012 20:29:27 -0000

Wenyu,

>    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.

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


On Oct 14, 2012, at 10:20 AM, wenyu zou wrote:

> 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 <anil@charter.net>et>:
>> 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:
>> 
>>> 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
>>> _______________________________________________
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>> 
>> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill