[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minutes for the subip meeting in SLC
minutes of the SLC Sub-IP Area meeting
Open Area Meeting, SLC, Dec 10th, 2001, 09:00-11:30
----------------------------------------------------------
(thanks to Don Fedyk for the raw minutes)
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 moving back to the Internet Area
Sub-IP Mibs have 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.
The CCAMP WG may not work out, don't wait.
George S.
Ditto
Philip Mathews
Progress a document about recovery in MPLS in the MPLS WG.
Bert:
The worry we have is if this could be a more generic document.
CCAMP is supposed to come up with a generic framework.
Other WGs can then extend that framework with technology or
protocol specific aspects of the framework.
George S
Doc completed 21 months ago! (The IETF is slower than the ITU.)
We would like to see this get out.
Unidentified Person
MPLS document should be tested to see if this works.
IETF is becoming too slow.
Ben Mack-Crane
The existing MPLS Recovery Framework is quite general
and could be extended to cover TDM, optical, etc.
Significant work went into agreeing on common terminology.
The CCAMP recovery work should use this as a starting point rather
than starting over.
Kiereeti
We will start new. Don't have a packet based control plane.
Will use the doc we are discussing as a starting point
summary:
The message to ADs from the floor was to move the ID forward
(progress the doc). The ADs expect to do so but expect that the
IESG will want to add a note to explain that once CCAMP comes with a
generic document, that this one then may have to be changed.
WG status overview by WG Chairs.
--------------------------------
IPORPR - Frank Kastenholz
WG deactivated the WG waiting for the IEEE to produce a document
specifying RPR. Then will reactivate to put IP over RPR.
MPLS - George Swallow
The MPLS WG is in a wind down process. Lots of MPLS implementation
experience. LDP fault tolerance complicated, simplifications proposed.
Bert
Are all the documents still WG documents?
In other words, please check that the list of I-Ds on the WG
charter page are indeed all MPLS WG documents.
George
WG will go through the list at this meeting and cull out
what is not needed
IPO - Dan Awduche
IPO WG is concerned with the technology aspects of the optical
networks. Documents are proceeding - Impairments document going
to last call. Still work to do on framework and carrier requirements
documents.
Interdomain rouitng considerations for optical networks.
Drafts discussing the work that is going on in the ITU including
Protection and restoration issues
Two major items not addressed yet: Applicability statements
for GMPLS and a traffic engineering doc that is peculiar to optical
networks.
GSMP - Avri Doria
Framework, protocol & MIB are basically done.
Next task: partitioning the core elements?
TEWG - Ed Kern
Restoration Hierarchy BCP going to IESG
Will take a long look at the IDs pending, if not there is not
strong support, the WG will not advance docs. (Rough consensus will
become more brutal to insure better quality docs go forward.) Silence
is no longer accepted as agreement. Throwing some documents to
informational as an option.
CCAMP - Kireeti Kompella
The work is moving forward quite nicely. Wrapping up protection
and restoration work. LMP work finished LC. Routing docs under
way, but target for LC at this meeting. More work on pre-OTN
networks and signaling for G.709.
Future directions: Security, More MIBS, recharter or disband.
Is GMPLS ready for IETF last call?
Lou all addressed except for few minor issues.
Rough consensus seen for the signaling drafts.
Eve Varma
Please publish a summary of the comments and the disposition.
Kireeti
We will create a summary of issues and resolutions.
PPVPN - Marco Carugi
Solutions for PPVPNs.
Main deliverables include framework and service requirements.
Design team based approach to create initial versions of IDs
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. There are 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 the documents are
available.
Some confusion:
Some people don't see that operators want these
Other want to address the whole space.
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 .
Almost all SONET stuff fits in (is a subset of) SDH.
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
or needed.
There is a BOF this week for more discussion.
Steven Trowbridge
A new website in the IESG to handle liaisons with the ITU.
ITU has set up an area on their website to show liaisons and
provide docs to IETF folks. ITU has also set up an FTP site
that will allow access to ITU docs that need to be accessed by
IETF. We should try to send info from IETF to ITU. Bert W
noted that individuals do NOT represent IETF. New RFC to
better define the liaison process between the IETF and the ITU.
ID will be out soon, Scott is the author.
Jerry Ash
Will the resolution to the GMPLS labels issue, as agreed by
IETF and ITU-T reps:
a) be posted to the CCAMP list for agreement, and
b) be reviewed by ITU-T SG15 for agreement?
Scott
The answer to both is 'yes'.
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 and lives off the IP control plane.
- 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
If MPLS is 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.
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 not part of IP. MPLS does use our technology. Sushi example.
Pride of ownership is not a reason to do it here. MPLS is not
fundamental to the IETF.
Andy Malis
Agree with Philip.
Dan Awduche
The Internet is about change, and the IETF cannot
expect to remain immune to these changes.
It has been deicided to use MPLS for IP over optical.
The same concepts are used for IP over FR etc.
We need to evolve the IP control plane substantially.
And evolve topologies and routing is the most fundamental
technologies for this. A 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.
Unidentified Person
The are many tunneling problems in general.
Like to keep MPLS in at least as a tunneling protocol.
Other IETF tunneling technologies share many aspects with MPLS.
Angela Chui
We want interoperability and standards are required to do that.
If we support this then we should do the work here.
Ron Bonica
The two MPLS views should be written down and then we can determine.
Dave Allen
If used for sushi trucks then we need to consider the
interactions with these trucks.
Ben Mack-Crane
MPLS is used to create both connectionless and connection-oriented
networks. These two forms of networking have fundamentally different
behavior and thus require different features from the networking
technology. If the IETF continues with MPLS, both uses of MPLS
must be addressed.
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 not MPLS 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 that are not addressed in PWE3.
Some sets of topics are 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 Blumenthal
Some aspects are tightly coupled to routing and should be
done here. Work/apps that use MPLS should be done 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-networks.
These are protocols that are being used in the networks.
Do IP on the edge MPLS in the Core.
If this is what people are doing with this then we should do it.
We should not be doing layer 2 interworking.
MPLS is a valid tunneling technology.
Randy Bush
I agree with you that there are IP free cores that use MPLS.
ATM was the same. Does not need us to standardize this.
No outstanding issues. 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 tagswitching as well, and MPLS is a compromise.
Maybe that should be done here.
But do we need a second universe? (everything over MPLS
as well as the sam ethings over IP)
But do we need to do standardize this?
Nobody says throw it out.
This just may not be the place to do this.
There are ways to achieve the same thing with IP.
Daniel Awduche
What we are doing here is the difference between change and
evolution. The constant is change.
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.
Lots of arguments about technologies, for example restoration
architectures. Lots of discussions about architectures.
This feels like the beginning of a slippery slope.
Not getting to the best of the working groups.
Don't maximize the benefits of MPLS here since we argue about
optical parts of this.
Loa Anderson
People run IP networks with MPLS.
Vendors do try to sell it as an ATM replacement.
ATM replacement pieces could go somewhere else.
Unidentified Person
Get rid of MPLS.
What way is ppp different from MPLS?.
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.
At some levels it 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.
Unidentified Person
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 but 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 MPLS relates 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
Need to define scope of MPLS WG.
And the scope of CCAMP as well --
Wrap-up
-------
Scott:
No consensus reached as to what to do with MPLS.
It was clear that we now have a split where one group thinks
we (IETF) should only do the minimum-MPLS related things
while others think we should do a lot more. Seems we need more
discussion and more reflection before we make decisions on what
type of work to entertain and what to leave to other organisations.
But it was important to get the discussion out in the open.
Further discussion will be on the SUB IP mailing list and
we will look at each WG as we consider recharters etc.
------------------------------------------------------------
Area mailing list: subip-area@subip.ietf.org
To Subscribe send email to: majordomo@subip.ietf.org
with in body: subscribe subip-area