Subject: [irs-discuss] Use Cases Draft First Cut

From: Russ White <[email-masked]>
Date: Wed, 19 Sep 2012 09:38:11 -0400

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

-- 
<><
[email-masked]
[email-masked]

---

From: Mach Chen <[email-masked]>
Date: Thu, 20 Sep 2012 09:30:47 +0000

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

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代
> 表 Russ White
> 发送时间: 2012年9月19日 21:38
> 收件人: [email-masked]
> 主题: [irs-discuss] Use Cases Draft First Cut
> 
> Y'all:
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Sep 2012 19:11:53 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Mach Chen
Sent: Thursday, September 20, 2012 5:31 AM
To: Russ White; [email-masked]
Subject: [irs-discuss] 答复: Use Cases Draft First Cut

Hi Authors,

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

> Last night I published a new draft on use cases for IRS. Please read 
> and send comments!
> 
> going to be changing a good bit; putting references in at this early 
> of a stage invites reference mismatches through major text revisions.
> 
> focus on use cases that reach beyond currently available mechanisms, 
> and show interaction between multiple pieces of an overall system.
> 
> 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.
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 21 Sep 2012 01:29:56 +0000

Hi Sue

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

> (Please note: I'm not disagreeing - just trying to find out more

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. 

> this works.  Maybe I missed something here.

Yes, we need talk more about this.

> I'll be in touch shortly offline.

Sure.

Best regards,
Mach