[irs-discuss] 答复: 答复: Use Cases Draft First Cut

Mach Chen <mach.chen@huawei.com> Fri, 21 September 2012 01:30 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8993121E8047 for <irs-discuss@ietfa.amsl.com>; Thu, 20 Sep 2012 18:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NvSS8yNvPjX1 for <irs-discuss@ietfa.amsl.com>; Thu, 20 Sep 2012 18:30:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id CCBCF21E8041 for <irs-discuss@ietf.org>; Thu, 20 Sep 2012 18:30:05 -0700 (PDT)
Received: from (EHLO lhreml203-edg.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW35471; Fri, 21 Sep 2012 01:30:04 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com ( by lhreml203-edg.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 02:29:28 +0100
Received: from SZXEML401-HUB.china.huawei.com ( by lhreml402-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 02:30:03 +0100
Received: from SZXEML511-MBS.china.huawei.com ([]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 09:29:58 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Susan Hares <shares@ndzh.com>, "'Russ White'" <russw@riw.us>, "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Thread-Topic: =?gb2312?B?W2lycy1kaXNjdXNzXSC08Li0OiAgVXNlIENhc2VzIERyYWZ0IEZpcnN0IEN1?= =?gb2312?Q?t?=
Thread-Index: AQHNl4VcPICKTttoA0a0jN/iFmDx5ZeT9Z3Q
Date: Fri, 21 Sep 2012 01:29:56 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE22CA99C2C@SZXEML511-MBS.china.huawei.com>
References: <5059CAC3.5070100@riw.us> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE22CA99531@SZXEML511-MBS.china.huawei.com> <00bd01cd9785$551b00d0$ff510270$@ndzh.com>
In-Reply-To: <00bd01cd9785$551b00d0$ff510270$@ndzh.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [irs-discuss] =?gb2312?b?tPC4tDogILTwuLQ6ICBVc2UgQ2FzZXMgRHJhZnQg?= =?gb2312?b?Rmlyc3QgQ3V0?=
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 01:30:07 -0000

Hi Sue

> 2. Optimized Exit
> Interface status and bandwidth of the interfaces is useful to determine the
> per interface information.  Are you concerned to get this information so you
> know if you overload the interface?
> If this is the case, I understand your concern.

Yes, this is one of the concerns that I have. Actually I pointed out this is because the draft mentioned:
"...Interface level events
      also often trigger notifications from the RIB to local routing
      processes; these notifications would be invaluble for the
      controller to modify injected routing state in reaction to network
      topology events."

Accordingly, there should be the related capabilities and functions to get the "interface level events", at least to know the interface is up or down. 

> If you are trying to have the IRS commissioner look at the real time traffic
> along the path by using the IRS, please tell me why you think IRS is useful.
> (Please note: I'm not disagreeing - just trying to find out more
> information).

The simplest way is just to get the static physical bandwidth of the external links, then the controller could make decision to which edge and external link the traffic should be more appropriate to drawn. Further, the IRS commissioner could get real time traffic along the paths, the decision will be more accurate. 

> What is "sub-pub"?  Is this is the sub-interface?

I mean to say "subscribe-publish", according the wiki, it's a messaging pattern where senders of messages, called publishers, and the receivers called subscribers. For IRS interfaces, IMHO, it may be better to have this kind of functions, and then the controller can only need to receive necessary information it subscribed. 

> 3. BGP routing protocol.
> On the BGP protocol case, it is sometimes important to insert the route at
> the BGP level to distribution and change the routing infrastructure on more
> than one router.   Perhaps we should chat more offline in order about how
> this works.  Maybe I missed something here.

Yes, we need talk more about this.

> 4. On the MPLS ideas, Let's chat more about the use cases offline.
> I thought this might be a good use case.
> I'll be in touch shortly offline.


Best regards,

> Thank you for the great input.
> Sue
> -----Original Message-----
> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On
> Behalf Of Mach Chen
> Sent: Thursday, September 20, 2012 5:31 AM
> To: Russ White; irs-discuss@ietf.org
> Subject: [irs-discuss] 答复: Use Cases Draft First Cut
> Hi Authors,
> I just read your draft, here are my comments:
> 1. For each use case, there list a set of capabilities and requirements, but
> several of them are the same and repeat in each use case, IMHO, it may be
> better to put all requirements and capabilities into a separate sections and
> may be split into the requirement draft in the future.
> 2. Optimized Exit Control,
> "Summary of IRS Capabilities and Interactions:"
> Besides the listed capabilities, IMHO, there should be the capability to
> monitor the status, bandwidth of specific interfaces, hence to help the
> controller makes the decision. In addition , from the scalability and
> flexibility point of view, there should support sub-pub capability, the
> controller subscribe to and only receive some of the events, entries,
> interfaces, the agent also only need to send the subscribed information of
> the controller.
> 3. Within Data Center Routing
> It seems not nature to conclude that IRS is needed and useful from the usage
> of BGP in datacenter, read through the sections, it gives me the feeling
> that it actually proposes centralized routing. It requires to get/inject
> information from/into specific routing protocols to control the routing.
> Since the IRS assumed to have the capability to install routes directly into
> the rib, why we need to inject information to the routing protocol to
> implicitly control the routing? It cannot guarantee that injected routes
> finally work, because the routes have to compete with the routes from other
> protocols.
> 4. Central membership computation for MPLS based VPNs Seems that it
> proposes
> to replace MP-BGP with IRS, if so, besides the VPN routes distribution, the
> controller also need to maintain and allocate labels for each private route;
> in addition, there also needs some mechanisms for tunnel setup. So, besides
> the listed capabilities, there IRS need to support more capabilities.
> Best regards,
> Mach
> > -----邮件原件-----
> > 发件人: irs-discuss-bounces@ietf.org
> > [mailto:irs-discuss-bounces@ietf.org] 代
> > 表 Russ White
> > 发送时间: 2012年9月19日 21:38
> > 收件人: irs-discuss@ietf.org
> > 主题: [irs-discuss] Use Cases Draft First Cut
> >
> > Y'all:
> >
> > Last night I published a new draft on use cases for IRS. Please read
> > and send comments!
> >
> > http://datatracker.ietf.org/doc/draft-white-irs-use-case/
> >
> > Several points to consider:
> >
> > 1. I've left all references out at the moment. I suspect this text is
> > going to be changing a good bit; putting references in at this early
> > of a stage invites reference mismatches through major text revisions.
> >
> > 2. I've left out a couple of suggested use cases. I think we need to
> > focus on use cases that reach beyond currently available mechanisms,
> > and show interaction between multiple pieces of an overall system.
> >
> > 3. I've worded some summary points in requirements language,
> > specifically using SHOULD in a couple of places. We need to think
> > about whether or not these types of references are "proper" in a use
> > cases draft of this sort.
> >
> > 4. The text is probably still rough around the edges --I've focused
> > more on the justification for the work in the introduction than on the
> > actual text of the use cases. I'm certain the text in the actual use
> > cases will harden as we get comments and edit those sections.
> >
> > Again, please read and make comments!
> >
> > Russ
> >
> > --
> > <><
> > riwhite@verisign.com
> > russw@riw.us
> > _______________________________________________
> > irs-discuss mailing list
> > irs-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss