* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Opsawg Status Pages

Operations and Management Area Working Group (Active WG)
Ops Area: Robert Wilton, Warren Kumari | 2007-Jun-13 —  

IETF-82 opsawg agenda


These are also available from the materials page:
Session 2011-11-15 0900-1130: 102 - Audio stream - opsawg chatroom

iCal: ietf-82-opsawg.ics


          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 <missing notes>
          ** 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
          <unclear text - "Nedme">?
          *** 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
          <See attached presentation for basic proposal>
          ** 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
          *** 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: <see slides>
          ** 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
          *** 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
          *** 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.
          *** <unknown speaker who works for/with NSN>:
          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
          *** Xu:
          just requirement for someone to make changes to implementation.
          *** Ron:
          Is this an operational <may be "experience" or "experiment"> document?
          *** Xu:
          *** Ron:
          You need to say at the beginning that this is an <may be "experience"
          or "experiment">. 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 <unclear text - "converse"> them to
          clarify the issues.
          ** Next Actions
          *** List discussion

Generated from PyHt script /wg/opsawg/agenda.pyht Latest update: 24 Oct 2012 16:51 GMT -