OPSAWG Chairs: Christopher LILJENSTOLPE and Scott BRADNER DateAndTime: TUESDAY, November 15, 2011 0900-1130 Morning Session I - Combined with OPSAREA Open Meeting * The Chair (Christopher Liljenstolpe) spent 2 minutes on Note well and agenda bashing * The Chair presented the Status of the working group: ** 8 RFC's published, ** 2 WG ID's active ** 2 WG ID's expired ** 19 individual IDs offered for discussion * draft-ietf-opsawg-management-stds-02.txt: Presented by Mehmet Ersue ** Status: *** Close the issue of adding information on high-level overview of IETF MIB module *** Proposal: provider a chapter for the high level overview of IETF MIBs as complementary to the management task-based view *** Provides NIST SGIP IP suite WG for comments after this meeting ** What's next *** have another WGLC after the update ** Discussion: *** Dan Romascanu: This is a very good document. There is a need of maintaining. Quality of the document and structure has improved. *** Mehmet: Agree fully. ** Chair (Chris) call for next steps agreement *** Hum if you agree: majority *** Hum if you don't agree: none. * draft-ietf-opsawg-automated-network-configuration-02.txt: Presented by Tina Tsou ** This is the second last call for WG. ** Major changes: *** Got feedback from Kent Watsen and Wesley George *** Added explanation that pre-configuraiotn might be provided via pluggable memory sticks or near field communication *** Improved text describing the motivation and goals of the document *** Added text that large enterprise net ** Related ID's *** Draft-schoenw-opsawg-nm-dhc-02 *** Draft-schoenw-opsawg-nm-srv-02 Defines common Syslog ** Next Steps: *** 2nd WG LC on draft-ietf-opsawg-automated-network-configuration? *** What to do ** Discussion: *** Chris: Who has read the drafts: a few hands *** Wes George: I haven't read this draft. But will do so. *** Chris: any other comments? ** Chair (Chris) call for next steps agreement *** Hum if take to LC: majority *** Hum if no: none *** Chris: Wes please read the draft. We will give a couple of days to call WGLC. *** Dan: I am not sure if it is BCP document. * Draft-perreault-opsawg-natmib-bis: Presented by Tina Tsou ** RFC 4008 *** Generic NAT MIB *** IPv4 and IPv6 support (NAT[46][46]) *** Required by draft-ietf-behave-lsn-requirements *** Missing many features **** DS-Lite: sharing address pools between interfaces **** CGN: per-subscriber state table indexing, **** per-subscriber statistics, er-pool statistics, **** notification for IP/port, configuration, quota exceed **** NAT64 **** PCP ** Proposal: *** Add milestone to this working group's charter: produce a revision of RFC4008 taking into account recent developments such as DS-Lite, CGN, and NAT64 *** Adopt draft-perreault-opsawg-natmib-bis as WG document for fulfilling the above. ** Discussion *** Ron Bonica: Title of the file name: is it in Behave WG? Does it belong to Behave? *** Tina: but Behave is shutting down *** Linda Shore: there is prior work which might be related. Midconf, SNMP. Therefore, I don't feel it is ready for WGLC. *** Dan: my second question: need more answer: Who in this room can work on ? *** Dan: This is the new type of work for the WG. We do work for WG which is shutting down in OpArea. But what we are not charted is doing MIB work for other areas. To do this work, we need to make decision. *** Ron: to amplify what Dan just said. Doing MIB for other area might start a lot of work for us. We might end up doing MIB for routing, etc. the list can go for a long time. *** Tina: if this WG is not the right place, where should we go? *** Wes: The question is really where the orphans of Behave go? We should delay answering this question. I think we have larger problem. Maybe Behave is pre-maturely shutting down. *** Ron: Maybe there are things that shouldn't be done in Behave. I will leave it to Transport area. ** Action *** Chairs and AD's will discuss with Transport Area * draft-li-opsawg-loadbalance-mib-03.txt. Presented by Chen Li (China Mobile) ** Why we do this? *** Because Load Balancers are very important in the network ** The basic LB MIB nodes ** Questions? *** Ron speaking as the AD: the MIB made some assumption on what LB do. Those LD behaviors probably done by RFC. Do you know any RFC exist? *** Chen: not aware *** Ron: it might be difficult to standardize those MIB if there is no standard on Load Balance. *** Thomas Narten: you do the work where the expertise is. Does IETF have any expertise on LB? Who are the expertise on LB? *** Chen: we have worked with LB vendors, like F5. *** Ron: if IETF has never done any work on LB, it is not appropriate to talk about MIB. If you think that IETF should talk about LB, maybe you should start a BOF. *** Dan: When extend it to the unexplored area? There is no proper service defined by IETF. Maybe we should develop our management interface. This work is much too early. We probably need to do some work in organizations which have expertise in this area. Define our own technologies in this area. *** Melinda Shore: unsuccessful RFCs on services being joined or leave. I.e. rserpool (reliable server pooling) working group. We developed a protocol for servers to join and leave "pools" (service clusters). It assumed the use of SCTP as a transport protocol and did not include failing over state with connections, but it did fail over connections at the transport layer. *** Chris (taking the chair hat off): Even though IETF hasn't touched on LB service yet. But when they fail, they absolutely damage network. Having a model is definitely useful. Maybe should have a draft to describe LB first. Once you do it, you might find a lot of new things. I do believe having some standard interface will be useful. *** Ron: I agree those things are in the network and very important. Therefore, write an Enterprise MIB. There are Enterprise specific MIBs. This draft is from operators who need a standard MIB. But we can't standardize a standard when people who implement it are not in the room. *** Thomas Narten: if you don't have the mess who can make it happen, you won't have it right. You need LB vendors to support and come to the room. *** Chris: Where you want to do this? *** Chen: discuss offline. ** Action *** Chairs will discuss with authors off-line * draft-gu-opsawg-policies-migration-01.txt. Presented by Y Gu. ** Network Architecture example: ** Scope: *** Network state migration: **** At the first stage, we will focus on migrating the session table on Firewall **** The scenarios include network state migration: *** Between DCs. With acceptable distance *** Within the same DC *** Analyze the problem **** Need VM migration notifier, APIs ** Questions *** Ron as individual speaker: first question: how is it different from the previous attempt. Second question is the requirement of the TCP session. How long are the TCP sessions? For applications with Long TCP sessions? What do they do today? *** Gu: one example is Mobile user. If User is having conversation with a server for file sharing, games, and others, the TCP session can be very long. When a server has thousands of TCP sessions, it is not easy to find a time frame when all of the TCP sessions are done. *** Ron: TCP session between Mobile user and Server? What is it? *** Gu: The requirement is from China Mobile, conversation needs to be maintained. *** Chris: it sounds like that server is the media gateway. *** David Black: some VMs are providing backup and running loadbalancing. You can get this situation. Backup service can be very in-tolerant to connection drop. E.g Tape *** Melinda Shore: There are connections between handset to control servers. Detection of topology, what is SA, what is DA, secure *** Ron: just because the problem is solvable, does it mean that we need to solve it? May be should ask it to be solved at different layers. *** Senthil Sivakumar: This is not a VM migration issues. Today mobile system already solves this. Anything which has state will have this issue. *** : assuming TCP session is long lived, is not right. Many applications *** Wes: In the context re-numbering, if the session continuing important? Do we need to solve this problem? Sim6 is potentially requiring long lasting session. I disagree that previous speakers assume that session is always short lived. What makes more sense is say that some needs to maintain session while address change. Need to consider both cases. *** David Black: agree with Wes that we should not assume that all sessions are short lived. Your front end interface TCP session is different from the backend TCP sessions. The backend tcp sessions can be very long, like TCP session to Tape. *** Melinda Shore: I don't see how Address change is related. ** Next Actions *** List discussion * draft-xu-virtual-subnet-06.txt Presented by X. Xu ** Presentation *** Why VM mobility across data center? *** Subnet extension *** Scalability *** Unknown unicast reducation/avoidance *** ARP broadcast reduction *** Virtual subnet overview **** Is a host route based IP only *** Control Plane *** Data Plane: Unicast *** No need for ARP broadcast *** Site multi-homing ** Questions *** David Black: What do you think need to be standardized? *** Xu: No need of change of protocol. *** David Black: I assume that this kind of draft is more useful for L2VPN or L3VPN? *** Xu: no protocol change. Just an informational draft. *** Ron: There is no protocol change. No requirement for anyone else to make change. *** Xu: just requirement for someone to make changes to implementation. *** Ron: Is this an operational experience document? *** Xu: Yes. *** Ron: You need to say at the beginning that this is an experience. There is no requirement for follow up. *** Benson: do you say that it is L2VPN? *** Xu: from the point of view of network. *** Benson: do you have any good reference for ARP proxy? RFC1027 is almost same as other proxies, but not quite the same. *** Xu: local gateway will return its own MAC address for remote host. *** Chris: you are looking forward to write an informational draft showing how to use IETF tools. Suggest you them to clarify the issues. ** Next Actions *** List discussion