[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft sub-ip area meeting in SLC
The following statement was attributed to me (Daniel Awduche)
in the minutes:
> "The IETF must change to follow MPLS."
This is incorrect. What I stated was something to the
effect that:
"The Internet is about change, and the IETF cannot
expect to remain immune to these changes."
Please correct the minutes accordingly.
Cheers,
/Dan
> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Monday, January 07, 2002 10:53 AM
> To: subip-area@subip.ietf.org
> Subject: 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
>
>
>