[mpls] 答复: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp

Xuxiaohu <xuxiaohu@huawei.com> Thu, 26 September 2013 01:47 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5775E21F964C for <mpls@ietfa.amsl.com>; Wed, 25 Sep 2013 18:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.087
X-Spam-Level:
X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=-2.701, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wM9GN4zZxarG for <mpls@ietfa.amsl.com>; Wed, 25 Sep 2013 18:47:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C789011E80F8 for <mpls@ietf.org>; Wed, 25 Sep 2013 18:47:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVW18498; Thu, 26 Sep 2013 01:47:08 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 02:46:18 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 26 Sep 2013 02:47:06 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Thu, 26 Sep 2013 09:46:59 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Yakov Rekhter <yakov@juniper.net>
Thread-Topic: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
Thread-Index: AQHOufk2IqVm6xvoD0KWW7Wyxwzn6pnXP09Q
Date: Thu, 26 Sep 2013 01:46:59 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211EED@NKGEML512-MBS.china.huawei.com>
References: <52303B3B.1060308@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08211A7E@NKGEML512-MBS.china.huawei.com> <201309251411.r8PEBkL16906@magenta.juniper.net>
In-Reply-To: <201309251411.r8PEBkL16906@magenta.juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.130]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org" <draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org>, Lizhong Jin <lizho.jin@gmail.com>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: [mpls] 答复: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Sep 2013 01:47:28 -0000

Hi Yakov,

> -----邮件原件-----
> 发件人: Yakov Rekhter [mailto:yakov@juniper.net]
> 发送时间: 2013年9月25日 22:12
> 收件人: Xuxiaohu
> 抄送: Loa Andersson; Lizhong Jin; Gregory Mirsky; Rajiv Asati (rajiva);
> draft-rekhter-mpls-pim-sm-over-mldp@tools.ietf.org; mpls-chairs@tools.ietf.org;
> VIGOUREUX, MARTIN (MARTIN); mpls@ietf.org
> 主题: Re: MPLS-RT review of draft-rekhter-mpls-pim-sm-over-mldp
> 
> Xiaohu,
> 
> > Hi,
> >
> > I have reviewed the document. I think this doc is coherent, technically sound
> > and ready to be considered for WG adoption.
> 
> Thanks.
> 
> > Two minor technical comments:
> >
> > 1) "... An implementation MAY support Option 1, as described in Section 2 of
> >    this document. An implementation MUST support Option 2, as described
> >    in Section 3 of this document."
> 
> > Comment: It would be better if the reason for the above implementation
> > suggestion can be given.
> 
> I do not have any strong reasons for the above choice. As I mentioned
> to Loa, I would really like the WG to determine which of the two is
> MUST and which one is MAY.
> 
> > 2) "... This document uses BGP Source Active auto-discovery routes, as
> >    defined in [MVPN-BGP]. This document also identifies the deployment
> >    scenarios where BGP Source Active auto-discovery routes will not be
> >    used."
> >
> > Comment: Besides the approach of originating Source Active auto-discovery
> > routes, shouldn't the MSDP-based approach be considered as well in option
> 1?
> 
> For one thing, use of the MSDP-based approach would require either
> (a) some sort of provisioning to establish a full mesh of MSDP peerings
> among all the edge routers, or (b) some sort of auto-discovery.
> Also, it is far from obvious that such full mesh scale any better
> than use of BGP with Source Active auto-discovery routes.

Thanks for the above explanation. Would it be better to include the above analysis text in the doc for clarification purposes?

Best regards,
Xiaohu

> > Several editorial comments:
> >
> > 1) "This document describes how to map mLDP P2MP tress to multicast
> > trees created by PIM-SM in ASM mode."
> >
> > /s/tress/trees
> 
> Thanks ! Will fix.
> 
> >
> > 2) "An implementation MAY support Option 1, as described in Section 2 of
> >    this document. An implementation MUST support Option 2, as described
> >    in Section 3 of this document."
> >
> > /s/Section2/Section3  /s/Section 3/Section 4
> 
> Sorry, my mistake. Will fix.
> 
> >
> > 3) "...One other scenario where no Source Active auto-discovery routes will b
> e
> >    used is described in section "Originating Source Active auto-
> >    discovery routes".
> >
> > /s/section/section 4.2 (since section 3.1 has the same title as section 4.2)
> 
> Sorry, my mistake. Will fix.
> 
> > 4) Source:  IPv6 RP address, 16 octets.
> > /s/Source/RP
> 
> Sorry, my mistake. Will fix.
> 
> Yakov.