Subject: RE: [IPORPR] Proposed new IPoRPR charter

From: Albert Herrera <[email-masked]>
Date: Tue, 9 Oct 2001 13:02:23 -0400

Given that 802.17 intends to meet service provider 
requirements for multi-customer rings, I'd like to 
specifically state customer separation requirements 
on the charter below (*).

Albert

> -----Original Message-----
> From: Kastenholz, Frank [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2001 8:57 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [IPORPR] Proposed new IPoRPR charter
> 
> ========================================================
> 
> Resilient Packet Rings, under development within the IEEE's 802.17
> RPRWG, will provide substantial enhancements in both efficiency and
> flexibility over current bi-directional ring topologies. Benefits of
> resilient packet rings (RPRs) will include spatial re-use (full
> utilization of both counter- rotating rings) while maintaining
> APS-like protection switching during media faults. The 802.17 RPRWG
> may develop mechanisms for topology discovery, congestion control,
> and protection switching. Reference the IEEE 802.17 RPRWG at
> http://www.ieee802.org/17/ for further information. 
> 
> The IPoRPR working group is chartered to develop the necessary
> standards for encapsulating, transmitting, and IPv4, IPv6, and MPLS
> over IEEE 802.17 Resilient Packet Rings. Some, but not all, of the
> specific issues that may need to be addressed are
>   - Packet Encapsulation
>   - Address Mapping
>   - MTU concerns
>   - Multicast and Broadcast
>   - Mapping of Diffserv to any QOS mechanisms developed for 802.17
>   - Network Management
>   - Routing Protocols
>   - MPLS
>   - Traffic Engineering
> 

*Given that 802.17 supports Service Provider requirements for
*multi-customer rings, issues to be addressed also include 
*mapping of L2 RPR customer separation mechanisms to L3 VPNs.

> At this time we do not know the nature of 802.17's work. Therefore we
> can not say with any degree of certainty which of these technical
> issues need to be addressed and which do not. The goal of this list
> is to enumerate possible issues to ensure that the working group
> evaluates them.
> 
> The IPORPR Framework draft (draft-ietf-iporpr-framework-##.txt)
> defines three levels of 802.17/IP interaction:
>   1.  L3 view of an RPR ring as a traditional broadcast media
>   2.  A L3 service interface to an RPR ring for specific 
>       resource/services requests
>   3.  Enhance L3 awareness and interaction with an RPR ring. 
> In the interests of timely development of protocols, the 
> working group shall concentrate on the first level in order
> to get a "basic" protocol developed and fielded.  The later
> levels can then build on the implementation experience 
> gained in doing the first level.
> 
> The IPoRPR working group shall not duplicate work being done in other
> working groups nor shall it do work that directly overlaps the
> responsibilities of other working groups.  Where such issues arise,
> the working group chairs shall direct the participants to the other
> relevant working group and shall notify the other relevant working
> group's chairs of the issue.
> 
> The IPoRPR WG will coordinate with relevant working groups within the
> IETF to leverage existing work. The WG may also generate requirements
> for other IETF WGs as needed. Additionally, the WG may collaborate
> with other standards bodies and interoperability forums engaged in IP
> over optical activities (e.g., including ITU-T) to share information,
> minimize duplication of effort, and coordinate activities in order to
> promote interoperability and serve the best interest of the industry.
> 
> This charter is being developed before IEEE 802.17 produce their
> standard in the hopes that the IP-over-802.17 specifications can be
> ready very quickly after the IEEE 802.17 standards are available.  As
> a result, this charter is not as concise as would normally be the
> case. As IEEE 802.17 gets closer to having a firm specification, this
> charter may be revised to take 802.17's work into account.
> 
> The IPoRPR working group will also continue to revise the framework
> internet-draft (draft-ietf-iporpr-framework-##.txt as of this
> writing).
> 
> IPoRPR participants are STRONGLY ENCOURAGED to take part in any and
> all areas of 802.17 which are of interest to them. In particular,
> IEEE 802.17 is developing a MIB for the management of 802.17
> networks.  IPoRPR participants are encouraged to take part in this
> effort to ensure that the MIB is appropriate for the Internet's
> operational needs.  
> 
> 
> GOALS AND MILESTONES:
> 
> These Goals and Milestones are tentative. First, we do not know
> exactly what 802.17 will produce so some adjustment of the work
> items or times may be needed. Second, the dates are predicated
> on 802.17 meeting its schedule:
> - First draft in January 2002,
> - Last additions in March 2002,
> - IEEE 802.17 Working Group Ballot June 2002
> - Last technical changes September 2002
> - LMSC ballot November 2002
> - Publication as a standard March 2003
> 
> March 2002     Publish first draft of the basic IP-over-RPR
>                specification as an Internet Draft.  This should
>                be published in time for the March 2002 IETF meeting.
>                This draft covers the first level of 802.17/IP 
>                interaction.
> 
> June 2002      Publish second draft of the basic IP-over-RPR 
>                specification as an Internet Draft. This should be
>                published in time for the July 2002 IETF meeting.
> 
> November  2002 Publish first draft of the advanced IP-over-RPR
>                specification as an Internet Draft. This draft
>                covers the second and third levels of 802.17/IP
> 	       interaction.
> 
> November 2002  Submit final draft to the Basic protocol to the 
>                IESG for Proposed Standard Status. This is timed
>                to occur at the same time as the IEEE's LMSC
>                ballot of November 2002.
> 
> January 2003   Publish second draft of the advanced IP-over-RPR
>                specification as an Internet Draft. This draft
>                covers the second and third levels of 802.17/IP
> 	       interaction.
> 
> June    2003   Submit the advanced IP-over-RPR Internet Draft
>                to the IESG for Proposed Standard Status
> 
> _______________________________________________
> IPORPR mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/iporpr
> 

_______________________________________________
IPORPR mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/iporpr

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Tue, 09 Oct 2001 13:27:50 -0400

>on the charter below (*).

...

>> Some, but not all, of the

For my own education, a service provider would have one
ring, to which they've attached multiple customers and they
want to "VPN-ize" each customer. Yes (more or less)?

Anyway, ssuming I'm fairly close to being right... I would 
not want to directly use a term such as "customer separation
mechanism" -- it _might_ be interpreted as limiting things
in ways we don't intend or presupposing a certain outcome 
from 802. Instead, why don't I make it a bit more generic.
Something like
 - Use and mapping of MPLS and L3 VPNS
?

Frank

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 09 Oct 2001 13:50:49 -0400

>>>   - Mapping of Diffserv to any QOS mechanisms developed for 802.17

        I would delete Albert's proposed new item, MPLS, 
Traffic Engineering, MTU, and Routing Protocols.  

        Rationale for my approach is that other IETF WGs already
exist with charters to do that work.  Moving that work here tends
to move the work away from the WGs that already have the greatest
expertise in making those various technologies work over an already 
diverse set of layer-2 technologies.  IEEE 802.17 will define an
MTU at layer-2.  Path MTU Discovery exists, is widely deployed,
and works.  So I don't see any legitimate MTU work for this WG.
Network Management is overly broad.  SNMP MIBs would be reasonable.

        Alternatley put, I would leave in the IPoRPR WG only these
items, some have been edited for clarity of meaning:
        Packet Encapsulation only if different from Ethernet
        Address Mapping (IPv4 ARP, IPv6 ND) only if different from Ethernet
        Multicast/broadcast issues only if 802.17 does not 
                support multicast or broadcast at layer-2
        DiffServ mapping from IPvN to 802.17 QoS only if 802.1p
                        is not supported by 802.17.
        Development of SMIv2-compliant MIB for "IP over 802.17"
                (Ideally this is joint-development with IEEE 802.17)

        IFF the other items are dropped by the existing IETF WGs 
that are chartered for those items, then this WG's charter could 
always be edited at that point in time to add them.  Having a long
laundry list of potential work items right now at least causes issues 
with WG focus.  Note that the "only if" words are quite deliberate.
Early indications are that *all* of the proposals to 802.17 can just
work for IP using existing approaches (e.g. used for IP/Ethernet-II).

        In short, we will likely get lucky and have no work to do.

Yours,

Ran
[email-masked]

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Tue, 09 Oct 2001 14:34:48 -0400

Ran,

Paragraph 5 of the proposed charter says:

Does this satisfy your concerns?

Frank Kastenholz
co-chair, IPoRPR

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 09 Oct 2001 16:24:00 -0400

>Does this satisfy your concerns?

        Please edit out the text from the current proposed draft charter 
that covers material that is within scope for the other WGs.

        There are many years of experience that broad expansive
charters don't usually yield productive IETF WGs.  I'd like this
WG to be productive.

Ran

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Wed, 10 Oct 2001 10:00:21 -0400

Ran

You're right about expansive charters leading to chaos.
However, there are three things to consider. 

First, the pileof "stuff" to be looked at in doing an 
IP-over-Foo specification has grown considerably over
the past several years. A simple "here is the header"
spec doesn't cut it anymore. All of the things that
we have listed are "features" of the IP protocol suite.
While I personally think that several of them are wastes
of time, we do have a professional responsibility to
consider each area.

Second, the charter breaks the work down into two general
piles -- a "basic" and an "advanced" IP-over-RPR specification
set. The basic one is meant to be a fairly simple spec
that can be done quickly, with little discussion needed, 
so that we can finish it and make it available coincident 
with the output of 802.17. Implementation and deployment can
quickly proceed. The "advanced" work will cover the more
complex issues and is expected to take longer and require
more discussion and so on. It is also possible that this
spec bogs down because of the complex issues to be dealt
with.  However, if this spec bogs down, we'll still have
the "basic" one done and out in the world and deployment
can proceed.

Third, the charter requires that any work that IPoRPR
identifies as being needed but which properly falls into 
some other working groups domain is sent to that working
group. We have already done some of this. For instance,
at WG's session at the Minneapolis IETF, there were two 
drafts that were presented. The WG decided that both
were better dealt with in other working groups and one
was directed to CCAMP and the other to TEWG. I expect,
and in fact the proposed charter requires, that we
continue in this vein.

So I do not believe that the charter is overly broad.

Frank Kastenholz
co-chair, IPoRPR

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 10 Oct 2001 10:14:39 -0400

>So I do not believe that the charter is overly broad.

Frank,

        If the co-chairs don't want input and review from WG members
that's fine, but please don't waste our time by vigorously asking for 
input and review, then rejecting all the input from the general
membership that shows up on the WG list.  :-(

Ran
[email-masked]

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Wed, 10 Oct 2001 11:15:39 -0400

Ran

We do wish input and review from the WG. However, as I am
sure you are aware, the IETF runs by consensus. One person's
dissent is widely considered to be insufficient to claim a
lack of consensus. 

Your claim that we are "rejecting all the input from the general
membership" is false. According to my records, there have been
three basic message threads concerning the charter. 
- The first was from Glenn Parsons which raised three concerns.
  Two of which were valid and the charter will be adjusted
  accordingly in the next edit. The third concern was on
  the MIB. I answered how we believed we covered the MIB.
  (Glenn, if my answer to you re the MIB was not OK, please speak
   up!)
- The second note was from Dan Romascanu.  I did not see any
  specific issues in his note, it looked like agreement with
  the plan I outlined in my response to Glenn Parson's note.
  (Dan, if I'm wrong in my interpretation, please let me know!)
- The third is the thread between you and Albert and me. Both 
  Albert and I have explained why we believe that the proposed
  charter has your concerns covered.

So the charge of rejecting input is, I feel, unfounded.

Frank Kastenholz
co-chair, IPoRPR

p.s. If anyone else sent comments on the charter, I missed them,
     so please send them again.