Subject: Fwd: IETF Sub-IP area: request for input

From: Alex Zinin <[email-masked]>
Date: Wed, 4 Dec 2002 10:25:19 -0800

FYI below. (Sorry for cross-posting.)
Please post follow-ups to [email-masked].
--
Alex

This is a forwarded message
From: The IESG <[email-masked]>
To:
Cc:
Date: Wednesday, December 04, 2002, 8:08:49 AM
Subject: IETF Sub-IP area: request for input

===8<==============Original message text===============

IETF SUB-IP area

 The IESG announced in November of 2000 that a new SUB-IP temporary
 pseudo-area would be formed as a part of an effort to develop a
 "systematic approach to dealing with what we used to describe as
 "sub-IP" technologies." At the time the IESG said:

 "Over the years the boundary between 'wires' and IP protocols has
 become harder to define and the interaction has become more intertwined.
 For example, what appear as 'wires' or 'circuits' in a virtual network
 may in fact be routed datagrams in an underlying IP network. The
 topology of dynamic underlying networks such as ATM and soon switched
 optical networks can interact with IP-level traffic engineering and
 routing. Additionally, with IETF technologies such as MPLS we are
 defining a whole new class of 'wires'."
 (http://www.ietf.org/IESG/STATEMENTS/new-area.txt)

 After the December 2000 IETF meeting and taking into account the
 discussion at that meeting the IESG formed a "temporary" SUB-IP Area.
 IN the announcement of this action the IESG said:

 "It is temporary because the IESG believes that this concentrated
 sub-IP effort will likely be of short duration, on the order of a year
 or two. We feel that much of the work will be done by then, and the
 working groups closed. Any working groups that have not finished when
 the IESG determines that the area should be closed will be moved into
 existing the IETF areas where they seem to have the best fit." and "The
 IESG expects to review the development process and charters, however;
 if we conclude that this expectation is incorrect, we will need to make
 this area more formal. At that point, the nominating committee will be
 asked to supply dedicated area directors."
 (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt)

 Although the SUB-IP working groups have made considerable progress
 (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs
 under IESG consideration and an additional 11 IDs having been passed to
 the ADs for their evaluation) their work is not yet done (with 53
 working group IDs currently in progress). It does appear that some of
 the working groups could finish the work in their charters over the next
 6 months but it could be a lot longer for others.

 Because the end is in sight for some of the working groups and since the
 IESG had generally assumed that the area would be a temporary one and
 the second anniversary of the creation of the SUB-IP area is next spring,
 analysis was started in the IESG to figure out which areas would be the
 best ones for the SUB-IP working groups to move to so that they could
 continue their work.

 As part of that analysis a SUB-IP area session was held during the IETF
 meeting in Atlanta where this topic was discussed.

 There was a spirited discussion during the session on the best path
 forward. The opinions ranged from following the distribution of
 working groups, to doing so with some specific changes to keeping the
 working groups in a separate SUB-IP area. A sense of the room was
 taken at the end of the discussion and that sense was very strongly
 that the SUB-IP Area should become a "long-term" (the description that
 was used during the consensus call) one and that the nomcom be asked
 to nominate a person (or persons) to become director(s) of the SUB-IP
 area.

 To help provide more information as input for the IESG discussion we
 would like to continue the discussion started in Atlanta on the mailing
 list. It is our intention to keep the discussion on the future of the
 SUB-IP area open, but short-lived, because it would be a very good idea
 to let the nomcom know ASAP what the future holds as they need to know
 what expertise is needed in the ADs for the existing areas and if they
 need to search for additional people.

 The IESG aim is to be able to let the nomcom know what the future of
 the SUB-IP work is by the end of the day of Thursday Dec 12th. That
 date was chosen because it is the date of the next IESG teleconference
 yet it provides some time for a public discussion.

 The options seem to be:
                 1/ move WGs (back) to permanent areas: migrate the SUB-IP
 working groups to other IETF areas sometime soon, likely before next
 summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or
 other) directorates to ensure the continued coordination between the
 remaining WGs.

                 2/ establish a long-term area: decide that the SUB-IP
 area will be a long-term one, clearly define its charter, and ask the
 nomcom to select one or two people to be Area Directors

                 3/ status quo: continue the SUB-IP Area as a temporary,
 ad-hoc effort, much as it has been, with the IESG selecting two sitting
 ADs to continue the effort that Bert & Scott have been doing. But maybe
 give more responsibility to the working group's technical advisors,
 normally the AD from the area where the working group might otherwise
 live.

 Data points for the discussion:

 DP1. It does look like a number of the SUB-IP working groups will be
 finishing up their main work in the next year and be ready to be closed
 until it is time to revise the RFCs based on experience or to advance
 them on the standards track. The groups that should be finishing up
 include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp.

 DP2. WGs in SUB-IP or the work pursued in them came from existing
 well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp
 and ppvpn as its derivatives) came from RTG.

 DP3. There's still a need for technical oversight from permanent areas,
 so some WGs have a technical advisor--normally the AD from the area
 where the working group might otherwise live (e.g. CCAMP, and PPVPN
 with a RTG AD as the TA).

 DP4. SUB-IP directorate was very useful when the area was just created.
 It is currently passive and WGs continue operating just fine.

 DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP
 Area was working and there is no compelling reason to break it up.
 There is a need to clarify the charters of some of the working groups
 so that the different groups understand what the division of tasks are
 but it is hard to identify what problem would be solved by breaking up
 the area.

 DP6. Extensions to specific IETF technologies should be done in the
 working groups responsible for those technologies based on requirements
 provided by other working groups. For example, extensions to OSPF
 should be done by the OSPF working group based on input from other
 working groups or individuals rather than being done someplace else.

 Discussions about the options:

 1/ Move WGs (back) to permanent areas and close the area

 For:

 Each WG within SUB-IP definitely has a strong feature that maps it to a
 given permanent area [1]. The property that logically holds them together
 in SUB-IP now is the need for coordination wrt the technologies that are
 normally considered below the IP layer. While this was indeed necessary
 right after SUB-IP creation, DP4 suggests that the goal has been achieved
 and the focus is shifting back to coordination with permanent areas (e.g.,
 DP3, as well as the fact that RTG WGs are already dealing with SUB-IP
 related extensions). DP1 suggests that there will be about three active
 WGs within a year; at least two of them can be argued to belong in RTG
 area (where they originally came from, see DP2), so it wouldn't make a
 lot of sense to have two separate areas overlapping so considerably.
 PPVPN does not map strongly to any area, however it doesn't map strongly
 to SUB-IP either (MPLS is just one possible encapsulation method)

 Against:

 DP5 suggests that the feeling in the room was against closing the area,
 though there was also some support for the idea that moving MPLS and
 CCAMP to RTG would be a fine idea if the area were to be closed. The
 feeling was that the area has been working and that there is no strong
 argument that there is a need to change things at this time.

 2/ Establish a long-term area

 For:

 DP5 suggests that the community believes this is a good idea. See also
 the "Against" for option 1. In addition the opinion was expressed that
 having a specific area with specifically assigned management,
 knowledgeable in the field, would be an advantage. In addition, new
 SUP-IP work may develop in the future and it would be good to have a
 home for it.

 Against:

 See "For" arguments for option 1 above. Also, there was an assumption
 when the area was formed that it would be temporary and the size of the
 IESG is near max effective size. It is also expected that if the nomcom
 needs to find an AD(s) for SUB-IP, the set of required skills would
 be extremely similar to those needed for the RTG area, which again
 brings up the question of whether it makes sense to have two areas
 with so similar expertise scopes.

 3/ Status quo

 For:

 DP5 suggests that the way the area operates is fine and does not need
 fixing at this time. As DP1 predicts, there may not be many active
 SUB-IP working groups within a year and it may be best to wait until
 a few of the working groups finish their work and close before deciding
 on the long term direction for this work. The IESG would decide which
 ADs would be asked to manage the area in March.

 Against:

   A decision has to be made sooner or later, delaying the decision will
 not make it any easier to make.

 The IESG would like to hear from the community on this topic - please
 direct your comments to the [email-masked] list.

 The IESG will discuss the matter in its next telechat on December 12.

 --------------------------------------------------
 [1] possible WG to area mappings:

         - IPO has the IP-over-foo property, which is usually addressed
 in INT,

         - GSMP came from RTG

         - MPLS (aside from the fact that it came from RTG) deals with a
 technology that is arguably another IP forwarding paradigm and relies
 heavily on regular routing functionality and/or protocols.

         - CCAMP works on a generalized version of MPLS, which could map
 it to RTG as well

         - TEWG came from O&M

         - PPVPN: suggestions have been made of INT, because its tunneling
 which is closest to INT, RTG because some of the suggested discovery and
 VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV
 because of congestion control worries)

===8<===========End of original message text===========