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

wenyu zou <nkzouwenyu@gmail.com> Tue, 16 October 2012 15:05 UTC

Return-Path: <nkzouwenyu@gmail.com>
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 E549721F89A2 for <trill@ietfa.amsl.com>; Tue, 16 Oct 2012 08:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1]
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 W8IKlipKX2xN for <trill@ietfa.amsl.com>; Tue, 16 Oct 2012 08:05:48 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7205B21F89AB for <trill@ietf.org>; Tue, 16 Oct 2012 08:05:47 -0700 (PDT)
Received: by mail-gh0-f172.google.com with SMTP id g10so1638268ghb.31 for <trill@ietf.org>; Tue, 16 Oct 2012 08:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JU+8XvnYisTZ1DL+q//gLsGbgBtUajUqh3mxCOrb8KY=; b=mWSYjtZ4WKREuLFcMNLWi+bPtceiXydDhqvkNrRG0LCpac+CuEq6HZgbvkcKqcn9Yr LylBoLIfwcObKmCvxNJx4dtT370zZ0dEWOlgnbP+wRJZ/V0Nr0zfwRhPuOe3oh0+GR6i hgxgk4N2yok7D+vofruV4+5TV6Tz8jGOZMauxfYSfN1HYhzzJ9oFEg2xrg2YiCBam/hu qIXB6GCiIEjVeE6ft3YS6R3jKeffZh9dtu8BpOUjA/AdjEN/rG/gprKAV/4AzMjT7yEW Ni2eMHxWydbaBrDORBPvS2WM91lS8f7LsMRgDV3zWuH9EkQTFkPaUs4pQwb8Ni7L3Vr7 cGlg==
MIME-Version: 1.0
Received: by 10.236.134.18 with SMTP id r18mr13900190yhi.45.1350399946721; Tue, 16 Oct 2012 08:05:46 -0700 (PDT)
Received: by 10.147.157.35 with HTTP; Tue, 16 Oct 2012 08:05:46 -0700 (PDT)
In-Reply-To: <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> <1CBF4AEF-2AD5-46B0-8DC6-B280C6322036@charter.net>
Date: Tue, 16 Oct 2012 23:05:46 +0800
Message-ID: <CA+7+8TQ7sXoX7ai-HHa6ESndgXrXHpvE2DwE_d6CPPz1Z=Hr1Q@mail.gmail.com>
From: wenyu zou <nkzouwenyu@gmail.com>
To: Anil R <anil@charter.net>
Content-Type: text/plain; charset=ISO-8859-1
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: Tue, 16 Oct 2012 15:05:50 -0000

Hi Anil,

> 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.
>
    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 <anil@charter.net>et>:
> 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
>
>