[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft sub-ip area meeting in SLC




Draft minutes of the SLC Sub-IP Area meeting

comments by Jan 11 at 8pm EST 
	thanks
		Bert & Scott

SUB-IP Area Open Meeting, SLC, Dec 10th, 2001, 09:00-11:30
----------------------------------------------------------
(minutes from Don Fedyk)

   Area mailing list:           subip-area@subip.ietf.org
   To Subscribe send email to:  majordomo@subip.ietf.org
      with in body:             subscribe subip-area

  Agenda for SUB-IP Area Open Meeting, Dec 10, 2001:

   5 min    - Admin (minute takers) and Agenda Bashing
   5 min    - Note: CCAMP discussion in wed Plenary
  15 min    - Ads Area Status
   5 min    - IPORPR Status
   5 min    - MPLS Status
   5 min    - GSMP status
  10 min    - IPO Status
  10 min    - TEWG Status
  10 min    - CCAMP Status
  10 min    - PPVPN Status
  10 min    - IETF - ITU relationships and division of work
  10 min    - Future of SUB-IP Area
  15 min    - MPLS and IETF
  30 min    - Open Mike
   5 min    - Wrap up

Ads Area Status
---------------

  Scott -
  The IPORPR working group will be moved back to Internet Area
  Sub-IP Mibs have to been waiting for an MIB-roadmap ID
              which is now done - MIB review has started 

  Bert -
  W.r.t. the MIBs, they don't even compile. They still talk
  about being experimental... various other nits.
  In general: to improve AD processing: Authors/editors and
  WG chairs better check ID NITS before submitting IDs 
  See: http://www.ietf.org/ID-nits.html
  If you address all the points listed in there... things may 
  move much faster.

  Scott
  Question:
  What should be done about the MPLS Recovery Framework with respect 
  to CCAMP? Do we wait for CCAMP.
 
  Frank C.
  CCAMP may not work out, don't wait.
 
  George S.
  Ditto
 
  Philip Mathews
  Progress recovery in MPLS in MPLS.
 
  Bert: 
  The worry we have is if this could be a more generic document.
  CCAMP is supposed to come up with a generic framweork
  Other WGs can then extend that framework with technology or
  protocol specific aspects of the framework.
 
  George S
  21 Months, slower than the ITU.
  We would like to see this get out. 
 
  ????
  MPLS document should be tested to see if this works.
  Becoming too slow. 
 
  ????
  MPLS framework does have general comments.
  Will this be the basis for the GMPLS document? 

  Kiereeti
  We will start new. Don't have a packet based control plane. 
  Will look at the document for useful pieces.

  General note. Security becoming more important. 
  Issues around an SMNP document. 

WG status overview by WG Chairs. 
--------------------------------

IPORPR - Frank Kastenholz
  WG deactivated waiting for the IEEE to produce a document on RPR.
  Then will reactivate to put IP over RPR.
 
MPLS - George Swallow
  In a wind down process. In terms of implementation experience.
  LDP fault tolerance complicated, simplifications proposed. 
 
  Bert
  Are all the documents still WG documents?
  In other words, pls check that the list of I-Ds on the WG 
  charter page are indeed all WG documents.
 
IPO - Dan Awduche
  Concerned with the technology aspects of the optical networks.
  Impairments and framework document.
  Impairments document going to last call
  Carrier requirements document. 
 
  Interdomain rouitng considerations for optical networks.
  Drafts discussing the work that is going on in the ITU 
  Protection and restoration issues
 
GSMP -  Avri Doria
  Work items GSMP to support GMPLS.
  Framework and Protocol.
  Two documents progressing.
  Partitioning the core elements?
 
TEWG - Ed Kern
  Restoration Hierarchy 
  BCP going to IESG
  Take a long look at direction no proper requirements
  filtering the documents.
  Originally out to the operations area.
  Throwing documents to informational as an option.
 
CCAMP - Kireeti Kompella
  Base signaling SDH/Sonet
  G709
  Link/metrics/topology
  Base documents
  Signaling documents
 
  LMP
  Is this ready for IETF last call?
  What is the status?
  Lou all addressed except for few minor issues. 
 
  Rough consensus for the signaling drafts. 
 
  Eve Varma
  please publish a summary of the comments and the disposition. 
 
  Kireeti
  We will address the issues with a summary.

PPVPN - Marco Carugi
  Solutions for PPVPNs.
  Main deliverables
  Framework and service requirements
  Goals and Milestones
  Approve wg documents
  BGP based
  VR approach
  Possible - CE- based IPSEC VPNS
 
  Port based based approach
  L2 VPN
  Optical VPNS
  
  Design Teams created:
  Service require (7 members)
  PPVPN Framework (9 members)
  Requirements for VPLS (7 members)
  Requirements for PPVPN discovery schemes (11 members)
  L2 VPN (9 members)
  L3 applicability DT soon. 

IETF - ITU relationships and division of work 
---------------------------------------------
  Bert:
  We had a small meeting/get-together last night to talk about
  about optical control. Too many vocal/"fighting" people
  on the mailing list. We wanted to try to get better 
  understanding of IETF-ITU relationship and who works on what.

  LMP and NTIP and VBI
  ITU said that this is treading into their space. 
  In SG-15 documents have taken place and documents are 
  available VBI acronym.
  Some conclusions don't see operators want it and need it 
  others as there is.
  Other want to address the whole space.
  More items in the ITU to define.
  Conclusion for consensus in the meeting: 
  - IETF would work on LMP WDM for pre-OTN network.
  - ITU will work on VBI for OTN networks. 
  Hopefully this will reduce the discussion on these topics.

  There was a discussion on whether things in SONET or SDH are 
  the same or different .
  All the SDH stuff fits in (is subset of) SONET.
  Some more items that need more discussion.
  More details will be available in CCAMP meeting. 
  
  MPLS OAM BOF.
  Deep disagreement on what level of OAM tools are available.
  There is a BOF this week for more discussion.

  Steven Trowbridge
  Liaison and documents sharing of ITU documents is available 
  through an ftp area.
  Both recommendations and works in progress.
  Need to accurately agree on the level of detail.

  Jerry Ash
  Resolution of the labels will that be discussed again? 
  (see above, it is on agenda for CCAMP)
 
Future of SUB-IP Area
---------------------
  Scott
  AD view on the progress of the area.
  The area will be closed down, probably after the next IETF meeting.
  Those WGs that are not concluded will move back into the
  appropriate areas.
  Time will tell if the sub-IP area was useful.

  The nomcom was not asked to find ADs for a long-term Sub-IP area. 

MPLS and IETF and Open Mike 
---------------------------
  Scott
  We whould like to have a discussion on how MPLS fits 
  into the future in the IETF? 
  Does MPLS have a place in the IETF?
  For example, should the IETF do technology over IP *and* MPLS?
 
  Lou Berger
  MPLS is good for the IETF to work on both data plane and the 
  control plane. According to RFC 2026 the IETF works on all
  technologies for IP or related to IP.

  George Swallow
  Two views:
  - MPLS adds capabilities to IP, lives off the IP control plane.
    Did not make sense for label distribution.
    So we built a protocol.
  - The other view MPLS is it own technology add QoS etc OAM 
    layer etc. 
  First camp falls in the IETF.
  The other can go somewhere else.
 
  Mina Azad Nortel Networks
  If on all technologies then it belongs otherwise it should go 
  else where. 
 
  Randy Bush
  MPLS as a switching technology, is a fairly clean technology. 
  It has uses. 
  When we get in trouble is when we go down and up layer 1 through layer 7.
  Must answer - "is this in our domain".
  IP is the control plane for every thing.
  Because IP is used for sushi delivery trucks does not mean 
  that we need this technology in the IETF. 
  Optical may not belong in the IETF. 
 
  Philip Mathew
  MPLS belongs in the IETF. Where it started.
  TE. Close relationship with other routing protocols.
  Some aspects of it should go off in other groups.
  Voice over IP example.
  MPLS is central to IP routers. 

  Frank Kastenholz
  MPLS is part of IP. MPLS uses our technology. Sushi example.
  Pride of ownership is not the reason. MPLS is not fundamental 

  Andy Malis
  Agree with Philip.
 
  Dan Awduche
  IETF must change to follow MPLS.
  Decisions for the IP over optical.
  Concepts are used for IP over FR etc.
  Evolve the IP control plane substantially.
  Evolve topologies and routing is the most fundamental
  technologies for this.
  Critical look at routing can come up with extensions that are 
  useful for IP.
  Clearly IETF should not be involved in developing fundament 
  technologies for optical networks. 
  ITU has to continually reexamine itself. 
  From pragmatic concept MPLS is very powerful IETF should continue
  in this area. Some pieces moved.
  But generally keep the MPLS here.

  ???
  Tunneling problems in general.
  Like to keep MPLS in for this reason.
  Tunneling technologies share many aspects.
 
  Angela Chui
  IP therefore optical is not a core competency.
  Want interoperability and standards are required.
  If we support this.
  Then we should do the work here. 

  Ron Bonica
  There are two views.
  MPLS views should be written down and then we can determine.
 
  Dave Allen
  If used for sushi trucks then we need to consider the 
  reactions with these trucks. 

  Ben Mackrane
  Connection oriented networks.
  If the IETF continues with MPLS must consider both aspects.

  Shai Herzog? 
  Looking at MPLS as a way IP evolves fitting in with marketing 
  needs. Extending Layer 2 to layer 3 because people like IP.
  That is why MPLS was of interest.
  If it is not required what will we use.
  Have not seen anything to replace it. I do see IP.

  Bilel Jamoussi 
  MPLS a protocol suite in IP networks. There is a lot of 
  interworking in layer 2 and not address in IP PWE3.
  Set of topics is not suited to the IETF.
  Pieces of MPLS that help IP networks should be here.
  GMPLS protocol should continue with close ITU interaction.

  Alex Conta ? 
  MPLS is an extension of IP routing. 
  Being too purist is not good. 
  
  Steve Blumental ?
  Some aspects are tightly coupled to routing
  Work/apps that use MPLS elsewhere

  Frank Kastenholtz
  Just because we like it does not mean we should do it.
  IETF is not the only standards organization.
  Stick to what we know.
  MPLS is useful. But that is not a reason for us to do MPLS.
  IP is everywhere. IP has won.
  This is a bad trend and you won't have the clean separation
  of being agnostic to the layer below.

  Kireeti Kompella
  MPLS is being used in IP network in how you structure the network. 
  Use MPLS for forwarding.
  Architectures for IP only network.
  These are protocols that are being used in the networks.
  Do IP on the edge MPLS in the Core. 
  If this is what people re doing with this.
  We should not be doing layer 2 interworking.
  MPLS is a valid tunneling technology. 
 
  Randy Bush
  I agree with you IP free cores and using this.
  ATM was the same. Does not need us to standardize this.
  No outstanding issue. MPLS is not an IP protocol.
  It is a layer 2 switch. It ain't IP.
  Just another layer 2 technology.
  John Moy wandered and wanted to build paths. 
  Cisco tags as well and MPLS is a compromise.
  Maybe that should be done here.
  Do we need a second universe? 
  But we do need this? Standardize this. 
  Nobody says throw it out.
  This just may not be the place to do this.
  There are ways to achieve this with IP.

  Daniel Awduche
  What we are doing here is the difference between change and 
  evolution. The constant is change.
  Current architectural paradigms.
  MPLS allows us to think of the network as a control system.
  MPLS has made this fundamental architectural change. 

  Verma
  The relationship is not a DMZ.
  Arguments about technologies.  
  Restoration architectures.
  Lots of discussions about architectures.
  Feels like the beginning of a slippery slope.
  Not getting to the best of the groups.
  Don't maximize the benefits here since we argue about
  optical parts of this.
 
  Loa Anderson
  Run an IP network with MPLS.
  Vendors do try to sell it as an ATM replacement.
  ATM replacement pieces could go somewhere else. 

  ???
  Get rid of MPLS.
  What is different from MPLS.
  PPP etc.
 
  Lou Berger
  MPLS as a control infrastructure technology.
  It is an information infrastructure. 
  You could run this all over PPP.
  Voice over PPP does not belong. 
  Is not different than PPP. 
 
  Eric Gray
  It is here or not here. 
  There are two ways the world is not that simple. 
  If we move stuff out side there will be more work on even 
  though they are not here
 
  Mark Townsly
  When you are involved with carrying some of these things over 
  IP networks and would not like to see these things thrown out.
  There is synergy and common development. These two things.
  Layer over IP is in scope. 
 
  ???
  Back in 1994 IP NG IPV6 has a flow ID.
  MPLS took this further.
  This could not happen in IP V6 WG.
  MPLS has noting to do with IP there is a very strong relationship.

  Joel Halpren
  MPLS control plane is in.
  Forwarding is simple so we did it. 
  Many other aspects are applications. 

  Francois
  Many ways relate to the IETF.
  Things that modify the IP control planes.
  There are things that belong elsewhere.
  Reuse things that use IP control planes. 

  ????
  Fine to use IP.
  Do away with fundamental layering rule. 
 
  Osama ?
  Should keep MPLS in scope of IETF
 
  Liam Casey
  Lack of efficiency - process should be efficient  - 
  Do not disband the sub-ip area
  
  Ron Bonica
  Document to propose places where MPLS is useful and
  what's appropriate 
 
  Verma
  Scope of MPLS WG --- 
  Scope of CCAMP as well -- 

Wrap-up
------- 
  Scott:
  Important to get the discussion out in the open. 
  further discussion on the SUB IP mailing list. 

  SUB-IP Area mailinglist:    subip-area@ietf.org
  to subscribe, send mail to: majordomo@subip.ietf.org
  in body of email:           subscribe subip-area