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

["Susan Hares" <[e-mail]>]

Mach:

Thank you for your input on the format of the requirements.  Let me chat
with Alia and Russ on that before I answer. 

I'd like to ask a few questions to clarify the rest of the ideas:

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. 

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

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

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. 

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. 

Thank you for the great input. 

Sue 




-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Mach Chen
Sent: Thursday, September 20, 2012 5:31 AM
To: Russ White; [e-mail]
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

> -----邮件原件-----
> 发件人: [e-mail] 
> [mailto:[e-mail]] 代
> 表 Russ White
> 发送时间: 2012年9月19日 21:38
> 收件人: [e-mail]
> 主题: [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
> 
> --
> <><
> [e-mail]
> [e-mail]
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/irs-discuss