From iporpr-admin@ietf.org Wed Oct 3 19:40:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03782 for ; Wed, 3 Oct 2001 19:40:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21043; Wed, 3 Oct 2001 19:35:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA21013 for ; Wed, 3 Oct 2001 19:34:59 -0400 (EDT) Received: from exchange.netpliance.com (exchange.netpliance.net [216.136.56.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03687 for ; Wed, 3 Oct 2001 19:34:57 -0400 (EDT) Received: by exchange.netpliance.net with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 18:32:06 -0500 Message-ID: <135697BB9C68D411B84700B0D04991CA0366DAA5@exchange.netpliance.net> From: Stephen Egbert To: "'iporpr@ietf.org'" Date: Wed, 3 Oct 2001 18:31:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14C63.7F8A06F0" Subject: [IPORPR] SRP - Algorithm selector? Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C14C63.7F8A06F0 Content-Type: text/plain; charset="iso-8859-1" In my review of one of the RPR Access Protocol, SRP; I've been reviewing the various SRP algorithms such as SRP-fa and other vendor's SRP-specific algorithm. Shouldn't we investigate the possibility of adding another field/control-packet to inform neighbor nodes of which SRP algorithm is being used? Apparently, Cisco's SRP-fa certainly is the early entrant and predominate leader so far. There's words in other vendors' RPR presentations found in RPRAlliance.Org and ieee802.org/17 websites touting better merits over SRP-fa, but I'm more concern about fractional division within the RPR market, particularly SRP algorithm. I suggest we explore whether we should stay with one SRP algorithm or not, and if not, whether we should provide for algorithm selection or informing with neighbor nodes. Steve Egbert TippingPoint Technologies, Inc. ------_=_NextPart_001_01C14C63.7F8A06F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SRP - Algorithm selector?

In my review of one of the RPR Access Protocol, SRP; = I've been reviewing the various SRP algorithms such as SRP-fa and other = vendor's SRP-specific algorithm.

Shouldn't we investigate the possibility of adding = another field/control-packet to inform neighbor nodes of which SRP = algorithm is being used?

Apparently, Cisco's SRP-fa certainly is the early = entrant and predominate leader so far.  There's words in other = vendors' RPR presentations found in RPRAlliance.Org and ieee802.org/17 = websites touting better merits over SRP-fa, but I'm more concern about = fractional division within the RPR market, particularly SRP = algorithm.

I suggest we explore whether we should stay with one = SRP algorithm or not, and if not, whether we should provide for = algorithm selection or informing with neighbor nodes.

Steve Egbert
TippingPoint Technologies, Inc.

------_=_NextPart_001_01C14C63.7F8A06F0-- _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 3 21:10:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05710 for ; Wed, 3 Oct 2001 21:10:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23097; Wed, 3 Oct 2001 21:06:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23066 for ; Wed, 3 Oct 2001 21:05:58 -0400 (EDT) Received: from morpheus.lanterncom.com ([64.161.157.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05631 for ; Wed, 3 Oct 2001 21:05:54 -0400 (EDT) Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 17:53:50 -0700 Message-ID: <58BE468BAC66D511AFE6000347251A2D5394DF@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'Stephen Egbert'" , "'iporpr@ietf.org'" Subject: RE: [IPORPR] SRP - Algorithm selector? Date: Wed, 3 Oct 2001 17:53:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org I think all stations on the ring would have to implement the same "fairness" algorithm, or we won't be able to achieve fairness. I don't have a formal proof for this, but that's how it appears to be, intuitively. If vendor A and vendor B implement different algorithms, and a provider uses their boxes on the same ring, exchanging this information will be not be of any use. (Unless of course vendors implement multiple fairness algorithms and pick the appropriate one after negotiating this with other nodes on the ring. But it doesn't seem likely that anyone would want to do that.) -Anoop -----Original Message----- From: Stephen Egbert [mailto:segbert@tippingpoint.com] Sent: Wednesday, October 03, 2001 4:31 PM To: 'iporpr@ietf.org' Subject: [IPORPR] SRP - Algorithm selector? In my review of one of the RPR Access Protocol, SRP; I've been reviewing the various SRP algorithms such as SRP-fa and other vendor's SRP-specific algorithm. Shouldn't we investigate the possibility of adding another field/control-packet to inform neighbor nodes of which SRP algorithm is being used? Apparently, Cisco's SRP-fa certainly is the early entrant and predominate leader so far. There's words in other vendors' RPR presentations found in RPRAlliance.Org and ieee802.org/17 websites touting better merits over SRP-fa, but I'm more concern about fractional division within the RPR market, particularly SRP algorithm. I suggest we explore whether we should stay with one SRP algorithm or not, and if not, whether we should provide for algorithm selection or informing with neighbor nodes. Steve Egbert TippingPoint Technologies, Inc. _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Thu Oct 4 04:09:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01369 for ; Thu, 4 Oct 2001 04:09:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09229; Thu, 4 Oct 2001 04:00:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09180 for ; Thu, 4 Oct 2001 04:00:30 -0400 (EDT) Received: from mxtlv1.corrigent.com ([199.203.64.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01285 for ; Thu, 4 Oct 2001 04:00:26 -0400 (EDT) Received: by mxtlv1.corrigent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Oct 2001 10:00:55 +0200 Message-ID: <8FA6CEF9A4E42B48A5F8DC038655B353607B4F@mxtlv1.corrigent.com> From: Leon Bruckman To: "'iporpr@ietf.org'" Subject: RE: [IPORPR] SRP - Algorithm selector? Date: Thu, 4 Oct 2001 10:00:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org I agree with Anoop that all nodes in a ring should use the same fairness algorithm, but my understanding is that Stephen means to have an indication of which algorithm is to be used in a node to avoid nodes in the same ring using different fairness algorithms without any warning or alarm. My opinion is that since the 802.17 WG is still debating the fairness algorithm issue, and it is still trying to come to a single solution, the IPORPR should wait until it is clear if more than one fairness algorithm will be standardized. Leon -----Original Message----- From: Anoop Ghanwani [mailto:anoop@lanterncom.com] Sent: Thursday, October 04, 2001 2:54 AM To: 'Stephen Egbert'; 'iporpr@ietf.org' Subject: RE: [IPORPR] SRP - Algorithm selector? I think all stations on the ring would have to implement the same "fairness" algorithm, or we won't be able to achieve fairness. I don't have a formal proof for this, but that's how it appears to be, intuitively. If vendor A and vendor B implement different algorithms, and a provider uses their boxes on the same ring, exchanging this information will be not be of any use. (Unless of course vendors implement multiple fairness algorithms and pick the appropriate one after negotiating this with other nodes on the ring. But it doesn't seem likely that anyone would want to do that.) -Anoop -----Original Message----- From: Stephen Egbert [mailto:segbert@tippingpoint.com] Sent: Wednesday, October 03, 2001 4:31 PM To: 'iporpr@ietf.org' Subject: [IPORPR] SRP - Algorithm selector? In my review of one of the RPR Access Protocol, SRP; I've been reviewing the various SRP algorithms such as SRP-fa and other vendor's SRP-specific algorithm. Shouldn't we investigate the possibility of adding another field/control-packet to inform neighbor nodes of which SRP algorithm is being used? Apparently, Cisco's SRP-fa certainly is the early entrant and predominate leader so far. There's words in other vendors' RPR presentations found in RPRAlliance.Org and ieee802.org/17 websites touting better merits over SRP-fa, but I'm more concern about fractional division within the RPR market, particularly SRP algorithm. I suggest we explore whether we should stay with one SRP algorithm or not, and if not, whether we should provide for algorithm selection or informing with neighbor nodes. Steve Egbert TippingPoint Technologies, Inc. _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Thu Oct 4 09:01:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10325 for ; Thu, 4 Oct 2001 09:01:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17608; Thu, 4 Oct 2001 08:51:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17575 for ; Thu, 4 Oct 2001 08:51:43 -0400 (EDT) Received: from ottawa02.lanterncom.com ([216.191.227.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09710 for ; Thu, 4 Oct 2001 08:51:38 -0400 (EDT) Received: by OTTAWA02 with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Oct 2001 08:52:15 -0400 Message-ID: <4BAC766A2FCDD4119C5E00E018021DE9234DD6@OTTAWA02> From: Albert Herrera To: "'Leon Bruckman'" , "'iporpr@ietf.org'" Subject: RE: [IPORPR] SRP - Algorithm selector? Date: Thu, 4 Oct 2001 08:52:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org A single fairness algorithm would be best. However, should any negotiations be required, it should be done by 802.17 and the information relayed to L3 if necessary. Albert > -----Original Message----- > From: Leon Bruckman [mailto:leonb@corrigent.com] > Sent: Thursday, October 04, 2001 4:01 AM > To: 'iporpr@ietf.org' > Subject: RE: [IPORPR] SRP - Algorithm selector? > > > I agree with Anoop that all nodes in a ring should use the > same fairness > algorithm, but my understanding is that Stephen means to have > an indication > of which algorithm is to be used in a node to avoid nodes in > the same ring > using different fairness algorithms without any warning or alarm. > My opinion is that since the 802.17 WG is still debating the fairness > algorithm issue, and it is still trying to come to a single > solution, the > IPORPR should wait until it is clear if more than one > fairness algorithm > will be standardized. > > Leon > > -----Original Message----- > From: Anoop Ghanwani [mailto:anoop@lanterncom.com] > Sent: Thursday, October 04, 2001 2:54 AM > To: 'Stephen Egbert'; 'iporpr@ietf.org' > Subject: RE: [IPORPR] SRP - Algorithm selector? > > > I think all stations on the ring would have to > implement the same "fairness" algorithm, or we > won't be able to achieve fairness. I don't have > a formal proof for this, but that's how it > appears to be, intuitively. If vendor A and > vendor B implement different algorithms, and a > provider uses their boxes on the same ring, > exchanging this information will be not be of > any use. (Unless of course vendors implement > multiple fairness algorithms and pick the appropriate > one after negotiating this with other nodes on the > ring. But it doesn't seem likely that anyone > would want to do that.) > > -Anoop > > -----Original Message----- > From: Stephen Egbert [mailto:segbert@tippingpoint.com] > Sent: Wednesday, October 03, 2001 4:31 PM > To: 'iporpr@ietf.org' > Subject: [IPORPR] SRP - Algorithm selector? > > > In my review of one of the RPR Access Protocol, SRP; I've > been reviewing the > various SRP algorithms such as SRP-fa and other vendor's SRP-specific > algorithm. > Shouldn't we investigate the possibility of adding another > field/control-packet to inform neighbor nodes of which SRP > algorithm is > being used? > Apparently, Cisco's SRP-fa certainly is the early entrant and > predominate > leader so far. There's words in other vendors' RPR > presentations found in > RPRAlliance.Org and ieee802.org/17 websites touting better merits over > SRP-fa, but I'm more concern about fractional division within the RPR > market, particularly SRP algorithm. > I suggest we explore whether we should stay with one SRP > algorithm or not, > and if not, whether we should provide for algorithm selection > or informing > with neighbor nodes. > Steve Egbert > TippingPoint Technologies, Inc. > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Thu Oct 4 09:44:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12473 for ; Thu, 4 Oct 2001 09:44:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19235; Thu, 4 Oct 2001 09:34:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19205 for ; Thu, 4 Oct 2001 09:34:37 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12005 for ; Thu, 4 Oct 2001 09:34:32 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 09:31:19 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM9ZVF; Thu, 4 Oct 2001 09:33:27 -0400 From: "Kastenholz, Frank" To: iporpr@ietf.org Message-Id: <5.0.2.1.2.20011004093555.00ad8090@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 04 Oct 2001 09:38:27 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [IPORPR] Our proposed new charter Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Hi folks Over a week ago we sent out a proposal for a new charter. There has not been a lot of discussion nor have there been many comments on it. Does this mean that everyone has read it and is extremely happy with it and that Albert and I should go ahead and submit it to the IESG? Frank Kastenholz co-chair, IPoRPR _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Thu Oct 4 15:42:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23784 for ; Thu, 4 Oct 2001 15:42:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02045; Thu, 4 Oct 2001 15:36:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02017 for ; Thu, 4 Oct 2001 15:36:02 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23653 for ; Thu, 4 Oct 2001 15:35:57 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f94JYqS04546 for ; Thu, 4 Oct 2001 15:34:52 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 4 Oct 2001 15:35:11 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <42PMC9NS>; Thu, 4 Oct 2001 15:35:01 -0400 Message-ID: From: "Glenn Parsons" To: iporpr@ietf.org Subject: RE: [IPORPR] Our proposed new charter Date: Thu, 4 Oct 2001 15:34:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D0B.A421C4A0" X-Orig: Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C14D0B.A421C4A0 Content-Type: text/plain; charset="iso-8859-1" Frank, Since no one has spoken up, I will say something (reminds me of the London meeting :-) Generally, I think the revision is good. As I mentioned in the London meeting, option 1 will likely be the choice made by most. Certainly, the other options will require more time to understand the complexities and perhaps detail them. So it makes sense to separate them into different documents. Further, I am happy to see alignment with the 802.17 milestones. There is no point second-guessing what 802.17 might specify -- we have to wait for their stable output before discussing the details of IPoRPR. That said, I do have a couple of comments: - I gather from the discussion at the meeting and the lack of a milestone that the IPoRPR Framework will not be published as an RFC and that it is merely an Internet Draft placeholder for the issues. I would suggest that this is made a little clearer in the charter. - I object to the seemingly judgmental terms 'basic' and 'advanced' for the two protocol documents. I think 'core' and 'extended' would be more appropriate ... or even just first and second. - I had thought based on London, that we would propose a MIB document for this group. The charter now encourages WG members to input into the 802.17 MIB. While I agree with this, it raises a bigger and more fundamental question -- so let me play the devil's advocate. If we encourage the MIB work to be rolled into the 802.17 spec, why don't we do the same thing for the use of IP on RPR? Cheers, Glenn. > ---------- > From: Kastenholz, Frank > Sent: Thursday, October 4, 2001 9:38 AM > To: iporpr@ietf.org > Subject: [IPORPR] Our proposed new charter > > > Hi folks > > Over a week ago we sent out a proposal for > a new charter. There has not been a lot > of discussion nor have there been many > comments on it. > > Does this mean that everyone has read it > and is extremely happy with it and that > Albert and I should go ahead and submit > it to the IESG? > > Frank Kastenholz > co-chair, IPoRPR > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > > ------_=_NextPart_001_01C14D0B.A421C4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPORPR] Our proposed new charter

Frank,

Since no one has = spoken up, I will say something (reminds me of the London meeting = :-)

Generally, I think = the revision is good.  As I mentioned in the London meeting, = option 1 will likely be the choice made by most.  Certainly, the = other options will require more time to understand the complexities and = perhaps detail them.  So it makes sense to separate them into = different documents.  Further, I am happy to see alignment with = the 802.17 milestones.  There is no point second-guessing what = 802.17 might specify -- we have to wait for their stable output before = discussing the details of IPoRPR.

That said, I do have = a couple of comments:

     - I gather = from the discussion at the meeting and the lack of a milestone that the = IPoRPR Framework will not be published as an RFC and that it is merely = an Internet Draft  placeholder for the issues.  I would = suggest that this is made a little clearer in the charter.

    - I object to the = seemingly judgmental terms 'basic' and 'advanced' for the two protocol = documents.  I think 'core' and 'extended' would be more = appropriate ... or even just first and second.

    - I had thought = based on London, that we would propose a MIB document for this = group.  The charter now encourages WG members to input into the = 802.17 MIB.  While I agree with this, it raises a bigger and more = fundamental question -- so let me play the devil's advocate.  If = we encourage the MIB work to be rolled into the 802.17 spec, why don't = we do the same thing for the use of IP on RPR?

Cheers,
Glenn.

    ----------
    From:   Kastenholz, Frank
    Sent:   Thursday, October 4, 2001 9:38 AM
    To:     = iporpr@ietf.org
    Subject: =        [IPORPR] Our proposed new charter


    Hi folks

    Over a week ago we sent out a = proposal for
    a new charter. There has not been a = lot
    of discussion nor have there been = many
    comments on it.

    Does this mean that everyone has read = it
    and is extremely happy with it and = that
    Albert and I should go ahead and = submit
    it to the IESG?

    Frank Kastenholz
    co-chair, IPoRPR

    _______________________________________________
    IPORPR mailing list
    IPORPR@ietf.org
    http://www.ietf.org/mailman/listinfo/iporpr=


------_=_NextPart_001_01C14D0B.A421C4A0-- _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Thu Oct 4 19:12:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26192 for ; Thu, 4 Oct 2001 19:12:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08746; Thu, 4 Oct 2001 19:08:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08715 for ; Thu, 4 Oct 2001 19:08:32 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26132 for ; Thu, 4 Oct 2001 19:08:29 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 19:05:49 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM96N9; Thu, 4 Oct 2001 19:07:59 -0400 From: "Kastenholz, Frank" To: Glenn Parsons , iporpr@ietf.org Message-Id: <5.0.2.1.2.20011004184929.00b0f530@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 04 Oct 2001 19:06:00 -0400 Subject: RE: [IPORPR] Our proposed new charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Wow, someone is reading my email! :-) At 03:34 PM 10/4/01 -0400, Glenn Parsons wrote: > - I gather from the discussion at the meeting and the lack of a milestone that the IPoRPR Framework will not be published as an RFC and that it is merely an Internet Draft placeholder for the issues. I would suggest that this is made a little clearer in the charter. We probably will put it forward as an RFC sometime ... don't know exactly when. The idea is to keep it open as an ID so that it can be easily updated as revisions are desired. These revisions might be in response to something 802 does, they might be something we think of, or maybe because it's thursday... >- I object to the seemingly judgmental terms 'basic' and 'advanced' for the two protocol documents. I think 'core' and 'extended' would be more appropriate ... or even just first and second. No judgement was meant. Will change to Core/Extended. >- I had thought based on London, that we would propose a MIB document for this group. The charter now encourages WG members to input into the 802.17 MIB. While I agree with this, it raises a bigger and more fundamental question -- so let me play the devil's advocate. If we encourage the MIB work to be rolled into the 802.17 spec, why don't we do the same thing for the use of IP on RPR? The MIB is an "interesting issue". There are two basic options here - We do a MIB - 802 does a MIB The argument for us doing the MIB is that the IETF has the SNMP/ SMI/... expertise so whatever we produce is almost guaranteed by definition to be "right" with regard to those issues. Of course, what the IETF does _not_ have is 802.17 technical knowledge, so while the MIB might pass all the SMI tests, it might not actually be good for anything. So the avenue that we're pursuing is to - have 802.17 do all the MIB work - we encourage IETF-ers, especially those with MIB/SMI experience, to participate in the 802 work. They can then exert any needed corrective influences. - Bert Wijnen, one of our ADs, is looking for a sharp MIB-person who can be convinced to go join the 802.17 work in the spirit of the previous bullet item. - Albert and I will try to arrange some informal reviews by us of the IEEE MIB when the time is right. As you might have guessed, thisis all quite informal. Since it's informal, we really can't put it into the charter. If we try to formalize things then there is a whole big IESG/IAB morass that is best avoided. If these methods fail, there are other avenues that we can go down, but it's best to hold them as a strategic reserve... A secondary issue that has been raised is availability of the actual MIB document. This should not be all that big a deal since 802 specs are now available online for $0.00. So, if you are interested in seeing a good MIB come out of 802.17, I suggest you join their group (see http://www.ieee802.org/17/ for info) Frank Kastenholz Co-Chair, IPoRPR _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From bighits@bighitsnow.com Sat Oct 6 21:23:02 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01925 for ; Sat, 6 Oct 2001 21:23:02 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f971Bsu19404; Sat, 6 Oct 2001 18:11:55 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f971Btt15236; Sat, 6 Oct 2001 18:11:59 -0700 (PDT) Received: from mail.bighitsnow.com (bighitsnow.com [207.0.63.19]) by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f971BK327737; Sat, 6 Oct 2001 18:11:20 -0700 (PDT) Received: from web-script(nobody).bighitsnow.com (207.0.63.19) by mail.bighitsnow.com (8.9.3/8.9.3) with SMTP id f9712YU18378; Sat, 6 Oct 2001 21:02:34 -0400 Date: Sat, 6 Oct 2001 21:02:34 -0400 Message-Id: <200110070102.f9712YU18378@mail.bighitsnow.com> From: Explode Sales with Reply-To: Explode Sales with To: Explode Sales with Subject: 37,500 visitors and 75,000 banner exposures every month? Are you looking to bring your company to the next level? Or are you a new company working with a tight advertising budget? Or are you looking to test a new business idea, a new product or a new service to see if it's viable without any risk? Then you need big impact advertising without the cost. That's exactly what our mass marketing program does. You'll get expensive advertising at such ridiculously inexpensive prices, it enables you to advertise virtually anything for a profit and it enables you to advertise with virtually no risk. But more importantly, it will make an immediate and noticeable impact because we've eliminated 99% of the costs for you! There is no other marketing program in existence that comes close to reaching so many people for so little cost. Just $99 will get you a GUARANTEED 37,500 visitors to your site plus it will get you a minimum of 75,000 banner ads on the same sites that charge over $3000 for 75,000 banner ads. Spots in this program are limited, so hurry on over: http://www.bighitsnow.com Click Here ______________________________________________ Subscribe to our Biz. Op. E-Zine and learn How To Make Money on the Internet, send a blank email to: subscribe@bighitsnow.com To be Removed, send a blank email to: remove@bighitsnow.com From iporpr-admin@ietf.org Sun Oct 7 13:25:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24714 for ; Sun, 7 Oct 2001 13:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00812; Sun, 7 Oct 2001 13:17:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00781 for ; Sun, 7 Oct 2001 13:17:49 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24658 for ; Sun, 7 Oct 2001 13:17:47 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f97HGru24776 for ; Sun, 7 Oct 2001 13:16:53 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f97HGlw24771 for ; Sun, 7 Oct 2001 13:16:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [IPORPR] Our proposed new charter Date: Sun, 7 Oct 2001 19:15:42 +0200 Message-ID: Thread-Topic: [IPORPR] Our proposed new charter Thread-Index: AcFNKVwpT6U7Dd6MSGGaGFAKI9dA/ACKUxjg From: "Romascanu, Dan (Dan)" To: "Kastenholz, Frank" , "Glenn Parsons" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA00782 Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Content-Transfer-Encoding: 8bit Hi, My 2 cents on the MIB issue, based upon my experience with the Ethernet MIBs. The approach that is proposed below has chances to work if the IEEE 802.17 WG agrees to include an SNMP MIB in its list of deliverables. I emphasize SNMP MIB, because other IEEE 802 WGs - like 802.3 (Ethernet) chose in the past to write 'protocol independent' MIBs - which were defining the structure and behavior of the management objects, and allow for 'protocol specific' MIBs (SNMP, CMIP!) to be defined by other organizations. Regards, Dan > >- I had thought based on London, that we would propose a MIB > document for this group. The charter now encourages WG > members to input into the 802.17 MIB. While I agree with > this, it raises a bigger and more fundamental question -- so > let me play the devil's advocate. If we encourage the MIB > work to be rolled into the 802.17 spec, why don't we do the > same thing for the use of IP on RPR? > The MIB is an "interesting issue". > There are two basic options here > - We do a MIB > - 802 does a MIB > > The argument for us doing the MIB is that the IETF has the SNMP/ > SMI/... expertise so whatever we produce is almost guaranteed > by definition to be "right" with regard to those issues. Of course, > what the IETF does _not_ have is 802.17 technical knowledge, so > while the MIB might pass all the SMI tests, it might not actually > be good for anything. So the avenue that we're pursuing is to > - have 802.17 do all the MIB work > - we encourage IETF-ers, especially those with MIB/SMI > experience, to participate in the 802 work. They can > then exert any needed corrective influences. > - Bert Wijnen, one of our ADs, is looking for a sharp > MIB-person who can be convinced to go join the 802.17 > work in the spirit of the previous bullet item. > - Albert and I will try to arrange some informal > reviews by us of the IEEE MIB when the time is right. > As you might have guessed, thisis all quite informal. > Since it's informal, we really can't put it into the > charter. If we try to formalize things then there is a > whole big IESG/IAB morass that is best avoided. > If these methods fail, there are other avenues that > we can go down, but it's best to hold them as a > strategic reserve... > > A secondary issue that has been raised is availability of the > actual MIB document. This should not be all that big a deal > since 802 specs are now available online for $0.00. > > So, if you are interested in seeing a good MIB > come out of 802.17, I suggest you join their > group (see http://www.ieee802.org/17/ for info) > > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 10:41:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05063 for ; Tue, 9 Oct 2001 10:41:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23777; Tue, 9 Oct 2001 10:36:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23746 for ; Tue, 9 Oct 2001 10:36:22 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04925 for ; Tue, 9 Oct 2001 10:36:15 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 10:33:29 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0CJB; Tue, 9 Oct 2001 10:35:42 -0400 From: "Kastenholz, Frank" To: "Romascanu, Dan (Dan)" , Glenn Parsons , iporpr@ietf.org Message-Id: <5.0.2.1.2.20011009102638.00b2bc30@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Oct 2001 10:29:51 -0400 Subject: RE: [IPORPR] Our proposed new charter In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 07:15 PM 10/7/01 +0200, Romascanu, Dan (Dan) wrote: >Hi, > >My 2 cents on the MIB issue, based upon my experience with the Ethernet >MIBs. > >The approach that is proposed below has chances to work if the IEEE >802.17 WG agrees to include an SNMP MIB in its list of deliverables. We, the IETF's IPoRPR working group, can not tell the IEEE 802.17 group what to do, of course. Hence the strong encouragement for individual IPoRPR participants with specific interests to take part in the 802.17 working group... (hint, hint, :-) >I >emphasize SNMP MIB, because other IEEE 802 WGs - like 802.3 (Ethernet) >chose in the past to write 'protocol independent' MIBs - which were >defining the structure and behavior of the management objects, and allow >for 'protocol specific' MIBs (SNMP, CMIP!) to be defined by other >organizations. If that happens, we (the IETF IPoRPR group) should be able to quickly put together a SNMP/SMI/IETF-specific form of the MIB... But we'd rather see the 802.17 group "do the right thing" Frank Kastenholz co-chair, IPoRPR _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 13:10:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08289 for ; Tue, 9 Oct 2001 13:10:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29421; Tue, 9 Oct 2001 13:01:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29392 for ; Tue, 9 Oct 2001 13:01:37 -0400 (EDT) Received: from ottawa02.lanterncom.com ([216.191.227.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08157 for ; Tue, 9 Oct 2001 13:01:32 -0400 (EDT) Received: by OTTAWA02 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Oct 2001 13:02:24 -0400 Message-ID: <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> From: Albert Herrera To: iporpr@ietf.org Subject: RE: [IPORPR] Proposed new IPoRPR charter Date: Tue, 9 Oct 2001 13:02:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org 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:FKastenholz@unispherenetworks.com] > Sent: Wednesday, September 26, 2001 8:57 AM > To: iporpr@ietf.org > Cc: bwijnen@lucent.com; narten@raleigh.ibm.com; sob@harvard.edu > 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 > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 13:37:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09782 for ; Tue, 9 Oct 2001 13:37:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00621; Tue, 9 Oct 2001 13:33:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00565 for ; Tue, 9 Oct 2001 13:33:15 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09575 for ; Tue, 9 Oct 2001 13:33:10 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 13:30:23 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0C6J; Tue, 9 Oct 2001 13:32:37 -0400 From: "Kastenholz, Frank" To: iporpr@ietf.org Message-Id: <5.0.2.1.2.20011009132750.0282fb40@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Oct 2001 13:37:51 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [IPORPR] Last Call on the Proposed Charter Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org There have not been a lot of comments on the Charter. Specifically, - Some minor editorial comments from a couple of folks - We have to add a work item to finish the framework. We propose that we make the date to submit it as an informational RFC in November of next year. The charter has us developing the "basic" IP-over-RPR stuff by the summer and getting the "advanced" version done in November. This way the framework can reflect the lessons learned from doing these specifications. Comments? Questions? - There is Albert's comment, addressed in a separate note. So we'd like to get all the comments in by Wednesday of next week (17 October). This is three weeks from when we sent out the proposal and just over a week from today. Frank Kastenholz co-chair, IPoRPR _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 13:41:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10112 for ; Tue, 9 Oct 2001 13:41:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00636; Tue, 9 Oct 2001 13:33:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00570 for ; Tue, 9 Oct 2001 13:33:15 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09577 for ; Tue, 9 Oct 2001 13:33:10 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 13:30:23 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0C62; Tue, 9 Oct 2001 13:32:37 -0400 From: "Kastenholz, Frank" To: Albert Herrera , iporpr@ietf.org Message-Id: <5.0.2.1.2.20011009132206.027f9240@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Oct 2001 13:27:50 -0400 Subject: RE: [IPORPR] Proposed new IPoRPR charter In-Reply-To: <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 01:02 PM 10/9/01 -0400, Albert Herrera wrote: >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 (*). ... >> 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. 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 _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 14:04:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10831 for ; Tue, 9 Oct 2001 14:04:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01363; Tue, 9 Oct 2001 13:58:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01336 for ; Tue, 9 Oct 2001 13:58:51 -0400 (EDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10666 for ; Tue, 9 Oct 2001 13:58:46 -0400 (EDT) Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 942308266E for ; Tue, 9 Oct 2001 13:58:17 -0400 (EDT) Message-Id: <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Oct 2001 13:50:49 -0400 To: iporpr@ietf.org From: RJ Atkinson Subject: RE: [IPORPR] Proposed new IPoRPR charter In-Reply-To: <5.0.2.1.2.20011009132206.027f9240@uniwest1> References: <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org >>> 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 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 rja@inet.org _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 14:25:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11173 for ; Tue, 9 Oct 2001 14:25:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02264; Tue, 9 Oct 2001 14:17:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02233 for ; Tue, 9 Oct 2001 14:17:47 -0400 (EDT) Received: from ottawa02.lanterncom.com ([216.191.227.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11050 for ; Tue, 9 Oct 2001 14:17:42 -0400 (EDT) Received: by OTTAWA02 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Oct 2001 14:18:34 -0400 Message-ID: <4BAC766A2FCDD4119C5E00E018021DE9234DE4@OTTAWA02> From: Albert Herrera To: "'RJ Atkinson'" , iporpr@ietf.org Subject: RE: [IPORPR] Proposed new IPoRPR charter Date: Tue, 9 Oct 2001 14:18:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Ran, Thanks for the feedback. The way I see this panning out is that IPORPR will also act as a focal point for these issues. As an example, TE has a design team and they need input from focal groups such as ours to make sure the right issues are raised. I have no problem for TEWG taking these on. I just want to make sure they do. Albert > -----Original Message----- > From: RJ Atkinson [mailto:rja@inet.org] > Sent: Tuesday, October 09, 2001 1:51 PM > To: iporpr@ietf.org > Subject: RE: [IPORPR] Proposed new IPoRPR charter > > > > >>> 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 > > 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 > rja@inet.org > > > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 14:45:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11463 for ; Tue, 9 Oct 2001 14:45:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02499; Tue, 9 Oct 2001 14:30:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02455 for ; Tue, 9 Oct 2001 14:30:06 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11241 for ; Tue, 9 Oct 2001 14:30:01 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 14:27:20 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0DBQ; Tue, 9 Oct 2001 14:29:34 -0400 From: "Kastenholz, Frank" To: RJ Atkinson , iporpr@ietf.org Message-Id: <5.0.2.1.2.20011009143352.00ae5220@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Oct 2001 14:34:48 -0400 Subject: RE: [IPORPR] Proposed new IPoRPR charter In-Reply-To: <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> References: <5.0.2.1.2.20011009132206.027f9240@uniwest1> <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Ran, Paragraph 5 of the proposed charter says: 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. Does this satisfy your concerns? Frank Kastenholz co-chair, IPoRPR At 01:50 PM 10/9/01 -0400, RJ Atkinson wrote: >>>> 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 > > 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 >rja@inet.org > > > >_______________________________________________ >IPORPR mailing list >IPORPR@ietf.org >http://www.ietf.org/mailman/listinfo/iporpr _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 15:08:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11752 for ; Tue, 9 Oct 2001 15:08:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03155; Tue, 9 Oct 2001 14:49:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03125 for ; Tue, 9 Oct 2001 14:49:10 -0400 (EDT) Received: from ottawa02.lanterncom.com ([216.191.227.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11522 for ; Tue, 9 Oct 2001 14:49:05 -0400 (EDT) Received: by OTTAWA02 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Oct 2001 14:49:57 -0400 Message-ID: <4BAC766A2FCDD4119C5E00E018021DE9234DE7@OTTAWA02> From: Albert Herrera To: "'Kastenholz, Frank'" , Albert Herrera , iporpr@ietf.org Subject: RE: [IPORPR] Proposed new IPoRPR charter Date: Tue, 9 Oct 2001 14:49:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org > -----Original Message----- > From: Kastenholz, Frank [mailto:FKastenholz@unispherenetworks.com] > Sent: Tuesday, October 09, 2001 1:28 PM > To: Albert Herrera; iporpr@ietf.org > Subject: RE: [IPORPR] Proposed new IPoRPR charter > > > At 01:02 PM 10/9/01 -0400, Albert Herrera wrote: > >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 (*). > > ... > > >> 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. > > 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 > ? > More like L2 to L3 mapping of VPNs. > > Frank > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 16:35:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13022 for ; Tue, 9 Oct 2001 16:35:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05982; Tue, 9 Oct 2001 16:30:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05943 for ; Tue, 9 Oct 2001 16:30:24 -0400 (EDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12987 for ; Tue, 9 Oct 2001 16:30:17 -0400 (EDT) Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id C01858266E; Tue, 9 Oct 2001 16:29:50 -0400 (EDT) Message-Id: <5.1.0.14.2.20011009161649.01d7db40@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Oct 2001 16:22:23 -0400 To: Albert Herrera From: RJ Atkinson Subject: RE: [IPORPR] Proposed new IPoRPR charter Cc: iporpr@ietf.org In-Reply-To: <4BAC766A2FCDD4119C5E00E018021DE9234DE4@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 14:18 09/10/01, Albert Herrera wrote: >Ran, > >Thanks for the feedback. The way I see this panning out is that >IPORPR will also act as a focal point for these issues. That is not the way IETF charters usually work. Moreover, the words above are NOT in the actual charter text and have a rather different meaning than the actual charter text that was posted to the list. >As an example, TE has a design team and they need input from >focal groups such as ours to make sure the right issues are >raised. I have no problem for TEWG taking these on. I just >want to make sure they do. If they don't undertake it *after* 802.17 has a stable draft spec and iff we've got framing and such sorted out and iff there is some specific set of things to be undertaken, then we can add that item to the IPoRPR charter at that future point in time. Charters are living documents; they change from time to time. One need not get every conceivable item into the charter early on. The most successful IETF WGs have focused narrow charters, but then evolve their charter with time as situations require. My proposed approach is to have our charter narrowly focused on work that is not within scope other places and that is also clearly high-priority for this WG. For example, without a defined approach to framing, lots of the upper-layer stuff can't really be addressed anyway. We can wait and see on the other items -- certainly wait until after 802.17 has a stable draft and after we've sorted out framing and the basic issues at hand. Ran _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Tue Oct 9 16:38:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13044 for ; Tue, 9 Oct 2001 16:38:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06188; Tue, 9 Oct 2001 16:32:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06154 for ; Tue, 9 Oct 2001 16:32:03 -0400 (EDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13001 for ; Tue, 9 Oct 2001 16:31:56 -0400 (EDT) Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 6D2568266E; Tue, 9 Oct 2001 16:31:28 -0400 (EDT) Message-Id: <5.1.0.14.2.20011009162236.009fc780@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Oct 2001 16:24:00 -0400 To: "Kastenholz, Frank" From: RJ Atkinson Subject: RE: [IPORPR] Proposed new IPoRPR charter Cc: iporpr@ietf.org In-Reply-To: <5.0.2.1.2.20011009143352.00ae5220@uniwest1> References: <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> <5.0.2.1.2.20011009132206.027f9240@uniwest1> <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 14:34 09/10/01, Kastenholz, Frank wrote: >Ran, > >Paragraph 5 of the proposed charter says: > 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. > >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 _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 09:37:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09897 for ; Wed, 10 Oct 2001 09:37:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14963; Wed, 10 Oct 2001 09:34:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14929 for ; Wed, 10 Oct 2001 09:34:00 -0400 (EDT) Received: from ns1.c-cor.com (130.host.c-cor.com [12.17.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09743 for ; Wed, 10 Oct 2001 09:33:57 -0400 (EDT) Received: from scpo1.c-cor.com (scpo1.c-cor.com [192.168.128.223]) by ns1.c-cor.com (8.10.1/8.10.1) with ESMTP id f9ADQX305662; Wed, 10 Oct 2001 09:26:37 -0400 (EDT) Received: by scpo1.c-cor.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 09:25:16 -0400 Message-ID: <6F1A2AC356962442A036205A401D97D80D379A@ct01exch01.adc.com> From: "Closs, David" To: "'Albert Herrera'" , "'Kastenholz, Frank'" Cc: iporpr@ietf.org Subject: RE: [IPORPR] Proposed new IPoRPR charter Date: Wed, 10 Oct 2001 09:32:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org To the IETF and IP concerns in general, will IP data traversing one (some) RPR rings on its end-to-end journey be a significantly different scenario from the same data needing to traverse some L2 switches on its path? > -----Original Message----- > From: Albert Herrera [mailto:aherrera@lanterncom.com] > Sent: Tuesday, October 09, 2001 2:50 PM > To: 'Kastenholz, Frank'; Albert Herrera; iporpr@ietf.org > Subject: RE: [IPORPR] Proposed new IPoRPR charter > > > > > -----Original Message----- > > From: Kastenholz, Frank [mailto:FKastenholz@unispherenetworks.com] > > Sent: Tuesday, October 09, 2001 1:28 PM > > To: Albert Herrera; iporpr@ietf.org > > Subject: RE: [IPORPR] Proposed new IPoRPR charter > > > > > > At 01:02 PM 10/9/01 -0400, Albert Herrera wrote: > > >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 (*). > > > > ... > > > > >> 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. > > > > 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 > > ? > > > More like L2 to L3 mapping of VPNs. > > > > Frank > > > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > http://www.ietf.org/mailman/listinfo/iporpr > _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 10:07:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10538 for ; Wed, 10 Oct 2001 10:07:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15682; Wed, 10 Oct 2001 10:00:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15642 for ; Wed, 10 Oct 2001 10:00:19 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10406 for ; Wed, 10 Oct 2001 10:00:18 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 09:57:27 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0F1L; Wed, 10 Oct 2001 09:59:33 -0400 From: "Kastenholz, Frank" To: RJ Atkinson Cc: iporpr@ietf.org Message-Id: <5.0.2.1.2.20011010094335.0281fe30@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Oct 2001 10:00:21 -0400 Subject: RE: [IPORPR] Proposed new IPoRPR charter In-Reply-To: <5.1.0.14.2.20011009162236.009fc780@10.30.15.2> References: <5.0.2.1.2.20011009143352.00ae5220@uniwest1> <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> <5.0.2.1.2.20011009132206.027f9240@uniwest1> <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 04:24 PM 10/9/01 -0400, RJ Atkinson wrote: >At 14:34 09/10/01, Kastenholz, Frank wrote: > >>Ran, >> >>Paragraph 5 of the proposed charter says: >> 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. >> >>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 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 _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 10:23:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10824 for ; Wed, 10 Oct 2001 10:23:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16539; Wed, 10 Oct 2001 10:20:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16495 for ; Wed, 10 Oct 2001 10:20:05 -0400 (EDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10764 for ; Wed, 10 Oct 2001 10:20:04 -0400 (EDT) Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 8F3428266E; Wed, 10 Oct 2001 10:19:22 -0400 (EDT) Message-Id: <5.1.0.14.2.20011010101024.00a6bec0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Oct 2001 10:11:56 -0400 To: "Closs, David" From: RJ Atkinson Subject: RE: [IPORPR] Proposed new IPoRPR charter Cc: iporpr@ietf.org In-Reply-To: <6F1A2AC356962442A036205A401D97D80D379A@ct01exch01.adc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 09:32 10/10/01, Closs, David wrote: >To the IETF and IP concerns in general, will IP data traversing >one (some) RPR rings on its end-to-end journey be a significantly >different scenario from the same data needing to traverse some >L2 switches on its path? Absent a stable draft spec over in IEEE 802.17, I don't think that anyone can answer the above question definitively. At least some of us *hope* that 802.17 will just look like any other LAN-style technology (e.g. FDDI, Ethernet, Token Ring) for IP purposes. Ran _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 10:28:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10982 for ; Wed, 10 Oct 2001 10:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16684; Wed, 10 Oct 2001 10:22:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16653 for ; Wed, 10 Oct 2001 10:22:36 -0400 (EDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10806 for ; Wed, 10 Oct 2001 10:22:34 -0400 (EDT) Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 9779C8266E; Wed, 10 Oct 2001 10:22:05 -0400 (EDT) Message-Id: <5.1.0.14.2.20011010101210.00a68a20@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 10 Oct 2001 10:14:39 -0400 To: "Kastenholz, Frank" From: RJ Atkinson Subject: RE: [IPORPR] Proposed new IPoRPR charter Cc: iporpr@ietf.org In-Reply-To: <5.0.2.1.2.20011010094335.0281fe30@uniwest1> References: <5.1.0.14.2.20011009162236.009fc780@10.30.15.2> <5.0.2.1.2.20011009143352.00ae5220@uniwest1> <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> <5.0.2.1.2.20011009132206.027f9240@uniwest1> <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org At 10:00 10/10/01, Kastenholz, Frank wrote: >So I do not believe that the charter is overly broad. > >Frank Kastenholz >co-chair, IPoRPR 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 rja@inet.org _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 11:18:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12012 for ; Wed, 10 Oct 2001 11:18:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19343; Wed, 10 Oct 2001 11:11:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19312 for ; Wed, 10 Oct 2001 11:11:08 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11901 for ; Wed, 10 Oct 2001 11:11:07 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 11:08:18 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0FM4; Wed, 10 Oct 2001 11:10:22 -0400 From: "Kastenholz, Frank" To: RJ Atkinson Cc: iporpr@ietf.org Message-Id: <5.0.2.1.2.20011010105400.02831d90@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Oct 2001 11:15:39 -0400 Subject: RE: [IPORPR] Proposed new IPoRPR charter In-Reply-To: <5.1.0.14.2.20011010101210.00a68a20@10.30.15.2> References: <5.0.2.1.2.20011010094335.0281fe30@uniwest1> <5.1.0.14.2.20011009162236.009fc780@10.30.15.2> <5.0.2.1.2.20011009143352.00ae5220@uniwest1> <5.1.0.14.2.20011009134007.01dc6540@10.30.15.2> <5.0.2.1.2.20011009132206.027f9240@uniwest1> <4BAC766A2FCDD4119C5E00E018021DE9234DE1@OTTAWA02> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org 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. At 10:14 AM 10/10/01 -0400, RJ Atkinson wrote: >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 >rja@inet.org _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From iporpr-admin@ietf.org Wed Oct 10 13:19:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15435 for ; Wed, 10 Oct 2001 13:19:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24291; Wed, 10 Oct 2001 13:14:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24259 for ; Wed, 10 Oct 2001 13:14:05 -0400 (EDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15185 for ; Wed, 10 Oct 2001 13:14:04 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 13:11:19 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TGHM0FZ1; Wed, 10 Oct 2001 13:13:27 -0400 From: "Kastenholz, Frank" To: iporpr@ietf.org Message-Id: <5.0.2.1.2.20011010131253.02826620@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Oct 2001 13:18:43 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [IPORPR] Meeting in Salt Lake City Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org Hi New topic :-) Is there any reason for the working group to meet at the Salt Lake City IETF meeting? Albert and I emailed briefly and don't see any issues, especially since we have no work to do until we get the charter fixed up. So, unless there is a need voiced from the working group, we're inclined not to schedule a session. The cut-off date for requesting a slot is 1700EST, 19 November, which is a Monday, about 5 1/2 weeks from now. This is the secretariat's cut-off date. Frank Kastenholz co-chair, IPoRPR _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From peter.lewis@upperside.fr Mon Oct 15 09:14:31 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27212 for ; Mon, 15 Oct 2001 09:14:30 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9FCq0k15477 for ; Mon, 15 Oct 2001 05:52:00 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f9FCptB28955 for ; Mon, 15 Oct 2001 05:51:55 -0700 (PDT) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f9FCmFS26958 for ; Mon, 15 Oct 2001 05:48:16 -0700 (PDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f9FCnp612781 for ; Mon, 15 Oct 2001 14:49:51 +0200 (CEST) Message-ID: <024501c15577$a12c78c0$0601a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World 2002: operators speak out Date: Mon, 15 Oct 2001 14:48:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0242_01C15588.645834A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0242_01C15588.645834A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MPLS World 2002: operators speak out AT&T, Equant, Infonet, Terabeam, Storm Telecom, LambdaNet, Telefonica=85 = Why have these operators chosen to implement MPLS? What type of VPN do = they operate? What is the return on investment? How does the MPLS = protocol fit into their existing architectures, especially ATM and Frame = Relay? How do they regard the recent developments made to MPLS, = especially GMPLS? What are the technical shortcomings. =20 Answers will be given during MPLS World 2002. =20 Get more details at: http://www.upperside.fr/congress02/mplsworld2002.htm ------=_NextPart_000_0242_01C15588.645834A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
MPLS World 2002: operators speak out
 
AT&T, Equant, Infonet, Terabeam, Storm Telecom, = LambdaNet,=20 Telefonica=85 Why have these operators chosen to implement MPLS? What = type of VPN=20 do they operate? What is the return on investment? How does the MPLS = protocol=20 fit into their existing architectures, especially ATM and Frame Relay? = How do=20 they regard the recent developments made to MPLS, especially GMPLS? What = are the=20 technical shortcomings.
 
Answers will be given during MPLS World = 2002.
 
Get more details at:
http://www.= upperside.fr/congress02/mplsworld2002.htm
 
------=_NextPart_000_0242_01C15588.645834A0-- From iporpr-admin@ietf.org Mon Oct 15 09:17:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27394 for ; Mon, 15 Oct 2001 09:17:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22565; Mon, 15 Oct 2001 09:10:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22532 for ; Mon, 15 Oct 2001 09:10:06 -0400 (EDT) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26979 for ; Mon, 15 Oct 2001 09:10:04 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f9FDA4630707 for ; Mon, 15 Oct 2001 15:10:04 +0200 (CEST) Message-ID: <028401c1557a$74183880$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Mon, 15 Oct 2001 15:08:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01C1558B.375DE500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [IPORPR] MPLS World 2002: operators speak out Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0281_01C1558B.375DE500 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MPLS World 2002: operators speak out AT&T, Equant, Infonet, Terabeam, Storm Telecom, LambdaNet, Telefonica=85 = Why have these operators chosen to implement MPLS? What type of VPN do = they operate? What is the return on investment? How does the MPLS = protocol fit into their existing architectures, especially ATM and Frame = Relay? How do they regard the recent developments made to MPLS, = especially GMPLS? What are the technical shortcomings. =20 Answers will be given during MPLS World 2002. =20 Get more details at: http://www.upperside.fr/congress02/mplsworld2002.htm ------=_NextPart_000_0281_01C1558B.375DE500 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
MPLS World 2002: operators speak out
 
AT&T, Equant, Infonet, Terabeam, Storm Telecom, = LambdaNet,=20 Telefonica=85 Why have these operators chosen to implement MPLS? What = type of VPN=20 do they operate? What is the return on investment? How does the MPLS = protocol=20 fit into their existing architectures, especially ATM and Frame Relay? = How do=20 they regard the recent developments made to MPLS, especially GMPLS? What = are the=20 technical shortcomings.
 
Answers will be given during MPLS World = 2002.
 
Get more details at:
http://www.= upperside.fr/congress02/mplsworld2002.htm
 
------=_NextPart_000_0281_01C1558B.375DE500-- _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr From signup1@ecommercechargecards.com Tue Oct 23 00:09:50 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06574 for ; Tue, 23 Oct 2001 00:09:50 -0400 (EDT) From: signup1@ecommercechargecards.com Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9N3w1Y18922 for ; Mon, 22 Oct 2001 20:58:02 -0700 (PDT) Received: from proxy2.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f9N3wFS12662 for ; Mon, 22 Oct 2001 20:58:16 -0700 (PDT) Received: from mail.ecommercechargecards.com (ecommercechargecards.com [207.0.63.18]) by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f9N3s6Q06339 for ; Mon, 22 Oct 2001 20:54:06 -0700 (PDT) Received: from web-script(nobody).ecommercechargecards.com (207.0.63.18) by mail.ecommercechargecards.com (8.9.3/8.9.3) with SMTP id f9N3ns023647 for ; Mon, 22 Oct 2001 23:49:55 -0400 To: iporpr@external.cisco.com Subject: ADV:CREDIT CARD PROCESSING Date: Mon, 22 Oct 2001 20:52:22 Message-Id: <490.365957.474803@unknown> Reply-To: signup@ecommercechargecards.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ********************************************************** To be removed from further mailings please respond to this email with "remove" in the subject line. ********************************************************** Dear Friend, Discover how you can accept credit cards directly from your website without ever having to purchase or lease expensive credit card equipment. If you are interested in learning more please click on the link below. INSTANT ACCOUNT SET-UPS, LOWEST RATES AND COMPLETE SHOPPINGCART SOLUTIONS AVAILABLE! http://www.webmktplace.com Feel free to call us @ 1.800.288.7363 If you prefer you can respond to this email@ mailto:signup@ecommercechargecards.com Please include NAME, PHONE# and best time to call. IBS/PBS 7657 Winnetka Canoga Park Ca From iporpr-admin@ietf.org Tue Oct 23 03:27:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23275 for ; Tue, 23 Oct 2001 03:27:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29132; Tue, 23 Oct 2001 03:20:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29104 for ; Tue, 23 Oct 2001 03:20:28 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23208 for ; Tue, 23 Oct 2001 03:20:24 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9N7JLS13945 for ; Tue, 23 Oct 2001 03:19:21 -0400 (EDT) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 23 Oct 2001 03:19:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <4SX6WRWW>; Tue, 23 Oct 2001 03:19:24 -0400 Message-ID: From: "Glenn Parsons" To: iporpr Cc: "Kastenholz, Frank" Subject: RE: [IPORPR] Proposed new IPoRPR charter Date: Tue, 23 Oct 2001 03:19:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15B93.09615B60" X-Orig: Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Resilient Packet Rings X-BeenThere: iporpr@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15B93.09615B60 Content-Type: text/plain; charset="iso-8859-1" I just noticed that I didn't respond to this.... oops :-( I trust this is not too late. > 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. > My comment on the Framework was agreement that it was not to be published as an RFC. It's purpose will have been served by next November and it would only duplicate the documents that are in the charter and will have been published as RFCs. > 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!) > On MIBs, I think that having the IETF do the MIBs (and IPoRPR in this case) makes sense for two reasons: 1) People look for MIBs with the IETF, not other standards bodies 2) It allows for us to distill out the useful portions of these other standards bodies work (from a MIB perspective). > - 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!) > 802 input is important and I commend Dan for his work touring IETF, 802.3, MEF, ... to define Ethernet MIBs. However, I think it that a MIB is probably low on the importance list in 802.17 and would be a useful complement for this WG to encourage its creation (by adding it to our charter). Cheers, Glenn. ------_=_NextPart_001_01C15B93.09615B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPORPR] Proposed new IPoRPR charter

I just noticed that = I didn't respond to this....  oops :-(   I trust this is = not too late.

    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. =

My comment on the = Framework was agreement that it was not to be published as an = RFC.  It's purpose will have been served by next November and it = would only duplicate the documents that are in the charter and will = have been published as RFCs.

    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!)

On MIBs, I think = that having the IETF do the MIBs (and IPoRPR in this case) makes sense = for two reasons:
        1) People look for MIBs with the IETF, not = other standards bodies

            2) It allows for us to distill out the useful = portions of these other standards bodies work (from a MIB perspective). =

    - 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!)

802 input is = important and I commend Dan for his work touring IETF, 802.3, MEF, ... = to define Ethernet MIBs.  However, I think it that a MIB is = probably low on the importance list in 802.17 and would be a useful = complement for this WG to encourage its creation (by adding it to our = charter).

Cheers,
Glenn.


------_=_NextPart_001_01C15B93.09615B60-- _______________________________________________ IPORPR mailing list IPORPR@ietf.org http://www.ietf.org/mailman/listinfo/iporpr