From mailnull@www1.ietf.org Tue Mar 4 01:44:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26367 for ; Tue, 4 Mar 2003 01:44:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h246skB30266 for iporpr-archive@odin.ietf.org; Tue, 4 Mar 2003 01:54:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h246skp30263 for ; Tue, 4 Mar 2003 01:54:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26358 for ; Tue, 4 Mar 2003 01:43:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h246omp30125; Tue, 4 Mar 2003 01:50:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h246npp30080 for ; Tue, 4 Mar 2003 01:49:51 -0500 Received: from web41501.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26272 for ; Tue, 4 Mar 2003 01:38:59 -0500 (EST) Message-ID: <20030304064100.37883.qmail@web41501.mail.yahoo.com> Received: from [12.210.22.195] by web41501.mail.yahoo.com via HTTP; Mon, 03 Mar 2003 22:41:00 PST Date: Mon, 3 Mar 2003 22:41:00 -0800 (PST) From: raj sharma Subject: Re: [IPORPR] A question on RPR's service policy To: Anthem ChenMin , Anoop Ghanwani Cc: iporpr@ietf.org In-Reply-To: <000901c2dbc6$7af6fe10$480d7aa8@anthem> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , So, as I embellish the response of my esteemed and learned colleague, I may come across as purist or even a fundamentalist of Class Based QOS (CBQOS). CBQOS systems expect a deterministic per-hop behavior. This is fundamental to the principle of classifying traffic to aggregate classes and fixing a deterministic behavior of each class through network nodes. If this principle is violated CBQOS is of minimal value - perhaps relegated to a marketing slide! In a class based system it is accepted if transit traffic is given a higher egress scheduling priority than the *same* class of traffic added at that node. But, a lower class traffic allowed to transit first than a higher priority traffic waiting to enter creates a *quota system* in a class based system. To be explicit, a single transit queue RPR node *always* give transit traffic the highest priority regardless of the class. Calling this class based QOS is speculative at best. IMHO, the single transit queue design in RPR is a dead duck ! You can use is as a decoy but it has very little value beyond that:) It somehow comes across as *cheap* due to low transit path buffering requirements. While, a single transit queue acts like a *dumb repeater* the dual transit queue design is not very noble either when you consider the IEEE 802 shackles it has around. This shackle is that: in IEEE 802 networks it is a taboo (usually associated with religions we talk about at an arm's length)to loose packets between the transmit side of one MAC and the receive side of another. Consequentially, in 802.17, one cannot loose packets while they are in *transit*. The result is that imminent packet loss throws class based scheduling out of the door to meet this new *congressional* mandate. So, Best Effort traffic (which interne t considers to be discardable) is not in RPR) impacts the behavior of Express Forwarded (EF) traffic. If BE traffic as an impact on EF and one calls it CBQOS - this makes me dyslexic;( Bottom line, your fluid will have turbulance in it when it goes through implementations that either have a one or two transit queues. Now, the landscape is much different when the number of classes and the number of transit queues is the same!! What is your opinion of: Either making RPR having one or two classes or making RPR having any number of classes. One class of service is like thick net- 10 Mbps Ethernet- either you can go or you cannot. Or, 2 class of service - either you have have confirmed tickets or your on standby. Is it palatable for a multi-hop standby passenger to blow way confirmed seat holders at transit points? raj --- Anthem ChenMin wrote: > Thank you very much.And I understand the priority > queuing you talked about. > Maybe I need to explain my question this way: > In the single queue, say, the passby low priority > queue, there would be different fluid flow that are > classified by Source-Destination. In that sense, in > the single queue, when the server take different > policy, the output of the server will be different. > If we analyze it in a Packet Switch way, there would > be no problem to regard it as FIFO model, but when > we analyze it as a fluid model, is it more > convenient to let flows(different sources and > destinations) share the server? > > More explicitly, for example, > X1 is the low priority flow from 1-->5 > X2 is the low priority flow from 2-->4 > Then when looking at 3rd node, it is easy to derive > d/dt(X1+X2), but what is dX1/dt and dX2/dt? It > depends on how the server serve the flow... > > Hope to get more idea from you.. > Thanks > > Best > > Anthem > ----- Original Message ----- > From: "Anoop Ghanwani" > To: "'Anthem ChenMin '" > Sent: Sunday, February 23, 2003 10:21 PM > Subject: RE: [IPORPR] A question on RPR's service > policy > > > > > > This question is probably more appropriate for the > IEEE 802.17 > > list. See http://www.ieee802.org/17. > > > > To answer your question, the service discipline at > a node > > depends on the transit queue architecture. It's > class-based > > priority scheduling, rather than either FIFO or > GPS. With > > a single transit queue, the service discipline at > node is: > > > > - Transit queue > > - Insert Class A > > - Insert Class B > > - Insert Class C > > > > With dual transit buffer, the priority changes > depending > > on the occupancy of the secondary transit queue. > > (Class A is transported in primary transit queue > > and B and C in secondary transit queue.) > > > > If secondary transit queue is < STQlowthresh > > > > - Transit primary > > - Insert Class A > > - Insert Class B > > - Insert Class C > > - Transit secondary > > > > If secondary transit queue is > STQlowthresh, but > < STQFullthresh > > > > - Transit primary > > - Insert Class A > > - Insert Class B > > - Transit secondary > > - Insert Class C > > (A node doesn't get to insert Class C traffic in > this mode.) > > > > If secondary transit queue = STQfullthresh > > > > - Transit primary > > - Transit secondary > > - Insert Class A > > - Insert Class B > > - Insert Class C > > (A node doesn't get to insert any traffic in this > mode.) > > > > I am not 100% sure about the scheduling rules for > the > > 2 transit queue case but the above is what I think > it is. > > One thing to note is that once a frame is admitted > by the > > MAC, the scheduling discipline at every node > guarantees > > that it will not be dropped due to congestion. > Also > > there is no reordering of frames within a class. > > > > Hope this helps. > > > > -Anoop > > > > -----Original Message----- > > From: Anthem ChenMin > > To: iporpr@ietf.org > > Sent: 2/23/03 6:25 PM > > Subject: [IPORPR] A question on RPR's service > policy > > > > I have a question. If we analyze the RPR in fluid > model, what is the > > service policy? FIFO? Or Generalized process > sharing? > > If that is FIFO, seems like if there are different > class of same > > priority packets, after passing through one node, > it would be distorted > > afterwards.. > > Anyone can help me? > > Thanks > > > > Anthem > > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > https://www1.ietf.org/mailman/listinfo/iporpr __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr From mailnull@www1.ietf.org Tue Mar 4 13:59:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05514 for ; Tue, 4 Mar 2003 13:59:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24JAH705130 for iporpr-archive@odin.ietf.org; Tue, 4 Mar 2003 14:10:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24JAH505127 for ; Tue, 4 Mar 2003 14:10:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05496 for ; Tue, 4 Mar 2003 13:59:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24J9x505086; Tue, 4 Mar 2003 14:09:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24J8N505014 for ; Tue, 4 Mar 2003 14:08:23 -0500 Received: from morpheus.lanterncom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05450 for ; Tue, 4 Mar 2003 13:57:16 -0500 (EST) Received: by MORPHEUS with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 10:51:24 -0800 Message-ID: <58BE468BAC66D511AFE6000347251A2D01313C3B@MORPHEUS> From: Nader Vijeh To: "'raj sharma'" , Anthem ChenMin , Anoop Ghanwani Cc: iporpr@ietf.org Subject: RE: [IPORPR] A question on RPR's service policy Date: Tue, 4 Mar 2003 10:51:23 -0800 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-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , The only way to control dx1/dt, dx2/dt versus d(x1+x2)/dt is to have a virtual or physical queue per x at ingress, all transit nodes as well as the egress port. CBQ by definition can not separate the flows and a flow approaching its peak rate will cause second flow to fall below its committed rate (unless network is provisioned for the peak rate). The other approach is Virtual WFQ at each congestion point and a closed loop flow control. This requires per flow queues at the ingress/egress of each node, but a queue-less transit. With this approach only committed rate provisioning is required for the network. In other words Sigma(CIR) can approach link Capacity C, while sigma(PIR) >> C. Regards, Nader -----Original Message----- From: raj sharma [mailto:mr_raj_sharma@yahoo.com] Sent: Monday, March 03, 2003 10:41 PM To: Anthem ChenMin; Anoop Ghanwani Cc: iporpr@ietf.org Subject: Re: [IPORPR] A question on RPR's service policy So, as I embellish the response of my esteemed and learned colleague, I may come across as purist or even a fundamentalist of Class Based QOS (CBQOS). CBQOS systems expect a deterministic per-hop behavior. This is fundamental to the principle of classifying traffic to aggregate classes and fixing a deterministic behavior of each class through network nodes. If this principle is violated CBQOS is of minimal value - perhaps relegated to a marketing slide! In a class based system it is accepted if transit traffic is given a higher egress scheduling priority than the *same* class of traffic added at that node. But, a lower class traffic allowed to transit first than a higher priority traffic waiting to enter creates a *quota system* in a class based system. To be explicit, a single transit queue RPR node *always* give transit traffic the highest priority regardless of the class. Calling this class based QOS is speculative at best. IMHO, the single transit queue design in RPR is a dead duck ! You can use is as a decoy but it has very little value beyond that:) It somehow comes across as *cheap* due to low transit path buffering requirements. While, a single transit queue acts like a *dumb repeater* the dual transit queue design is not very noble either when you consider the IEEE 802 shackles it has around. This shackle is that: in IEEE 802 networks it is a taboo (usually associated with religions we talk about at an arm's length)to loose packets between the transmit side of one MAC and the receive side of another. Consequentially, in 802.17, one cannot loose packets while they are in *transit*. The result is that imminent packet loss throws class based scheduling out of the door to meet this new *congressional* mandate. So, Best Effort traffic (which interne t considers to be discardable) is not in RPR) impacts the behavior of Express Forwarded (EF) traffic. If BE traffic as an impact on EF and one calls it CBQOS - this makes me dyslexic;( Bottom line, your fluid will have turbulance in it when it goes through implementations that either have a one or two transit queues. Now, the landscape is much different when the number of classes and the number of transit queues is the same!! What is your opinion of: Either making RPR having one or two classes or making RPR having any number of classes. One class of service is like thick net- 10 Mbps Ethernet- either you can go or you cannot. Or, 2 class of service - either you have have confirmed tickets or your on standby. Is it palatable for a multi-hop standby passenger to blow way confirmed seat holders at transit points? raj --- Anthem ChenMin wrote: > Thank you very much.And I understand the priority > queuing you talked about. > Maybe I need to explain my question this way: > In the single queue, say, the passby low priority > queue, there would be different fluid flow that are > classified by Source-Destination. In that sense, in > the single queue, when the server take different > policy, the output of the server will be different. > If we analyze it in a Packet Switch way, there would > be no problem to regard it as FIFO model, but when > we analyze it as a fluid model, is it more > convenient to let flows(different sources and > destinations) share the server? > > More explicitly, for example, > X1 is the low priority flow from 1-->5 > X2 is the low priority flow from 2-->4 > Then when looking at 3rd node, it is easy to derive > d/dt(X1+X2), but what is dX1/dt and dX2/dt? It > depends on how the server serve the flow... > > Hope to get more idea from you.. > Thanks > > Best > > Anthem > ----- Original Message ----- > From: "Anoop Ghanwani" > To: "'Anthem ChenMin '" > Sent: Sunday, February 23, 2003 10:21 PM > Subject: RE: [IPORPR] A question on RPR's service > policy > > > > > > This question is probably more appropriate for the > IEEE 802.17 > > list. See http://www.ieee802.org/17. > > > > To answer your question, the service discipline at > a node > > depends on the transit queue architecture. It's > class-based > > priority scheduling, rather than either FIFO or > GPS. With > > a single transit queue, the service discipline at > node is: > > > > - Transit queue > > - Insert Class A > > - Insert Class B > > - Insert Class C > > > > With dual transit buffer, the priority changes > depending > > on the occupancy of the secondary transit queue. > > (Class A is transported in primary transit queue > > and B and C in secondary transit queue.) > > > > If secondary transit queue is < STQlowthresh > > > > - Transit primary > > - Insert Class A > > - Insert Class B > > - Insert Class C > > - Transit secondary > > > > If secondary transit queue is > STQlowthresh, but > < STQFullthresh > > > > - Transit primary > > - Insert Class A > > - Insert Class B > > - Transit secondary > > - Insert Class C > > (A node doesn't get to insert Class C traffic in > this mode.) > > > > If secondary transit queue = STQfullthresh > > > > - Transit primary > > - Transit secondary > > - Insert Class A > > - Insert Class B > > - Insert Class C > > (A node doesn't get to insert any traffic in this > mode.) > > > > I am not 100% sure about the scheduling rules for > the > > 2 transit queue case but the above is what I think > it is. > > One thing to note is that once a frame is admitted > by the > > MAC, the scheduling discipline at every node > guarantees > > that it will not be dropped due to congestion. > Also > > there is no reordering of frames within a class. > > > > Hope this helps. > > > > -Anoop > > > > -----Original Message----- > > From: Anthem ChenMin > > To: iporpr@ietf.org > > Sent: 2/23/03 6:25 PM > > Subject: [IPORPR] A question on RPR's service > policy > > > > I have a question. If we analyze the RPR in fluid > model, what is the > > service policy? FIFO? Or Generalized process > sharing? > > If that is FIFO, seems like if there are different > class of same > > priority packets, after passing through one node, > it would be distorted > > afterwards.. > > Anyone can help me? > > Thanks > > > > Anthem > > > _______________________________________________ > IPORPR mailing list > IPORPR@ietf.org > https://www1.ietf.org/mailman/listinfo/iporpr __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr From mailnull@www1.ietf.org Thu Mar 6 02:38:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27096 for ; Thu, 6 Mar 2003 02:38:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h267nJ410011 for iporpr-archive@odin.ietf.org; Thu, 6 Mar 2003 02:49:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267nIO10008 for ; Thu, 6 Mar 2003 02:49:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27076 for ; Thu, 6 Mar 2003 02:37:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267iKO09736; Thu, 6 Mar 2003 02:44:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h267hnO09704 for ; Thu, 6 Mar 2003 02:43:49 -0500 Received: from web41511.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26871 for ; Thu, 6 Mar 2003 02:32:22 -0500 (EST) Message-ID: <20030306073426.16535.qmail@web41511.mail.yahoo.com> Received: from [12.210.22.195] by web41511.mail.yahoo.com via HTTP; Wed, 05 Mar 2003 23:34:26 PST Date: Wed, 5 Mar 2003 23:34:26 -0800 (PST) From: raj sharma Subject: RE: [IPORPR] A question on RPR's service policy To: Nader Vijeh , Anthem ChenMin , Anoop Ghanwani Cc: iporpr@ietf.org In-Reply-To: <58BE468BAC66D511AFE6000347251A2D01313C3B@MORPHEUS> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , --- Nader Vijeh wrote: Raj responds......see embedded comments: > The only way to control dx1/dt, dx2/dt versus > d(x1+x2)/dt is to have a > virtual or physical queue per x at ingress, all > transit nodes as well as the > egress port. CBQ by definition can not separate the > flows and a flow > approaching its peak rate will cause second flow to > fall below its committed > rate (unless network is provisioned for the peak > rate). Nader, why involve calculus when we dont need it (dx/dt - really?). CBQ by definition does not care about rat's *fine assets* about flows. i.e. this is the difference between intserv and diffserv: One deals with aggregated flows and the other deals on per flow basis - like ATM - yuch:( (I must have stepped on somthing slimy) > The other approach is Virtual WFQ at each congestion > point and a closed loop > flow control. This requires per flow queues at the > ingress/egress of each > node, but a queue-less transit. Queue-less transit: Sounds like you have been sitting under the bodhi tree too long! > With this approach > only committed rate > provisioning is required for the network. In other > words Sigma(CIR) can > approach link Capacity C, while sigma(PIR) >> C. Suspicious math! Never encountered this in school, college or normal life (dreams maybe - mea culpa). Anyway, what kind of kool aid is this ? __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr From mailnull@www1.ietf.org Wed Mar 26 12:36:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04835 for ; Wed, 26 Mar 2003 12:36:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QHvhs16601 for iporpr-archive@odin.ietf.org; Wed, 26 Mar 2003 12:57:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHvhO16598 for ; Wed, 26 Mar 2003 12:57:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04814 for ; Wed, 26 Mar 2003 12:36:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHvMO16559; Wed, 26 Mar 2003 12:57:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QHt0O16442 for ; Wed, 26 Mar 2003 12:55:00 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04739 for ; Wed, 26 Mar 2003 12:33:35 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2QHZsJ15010 for ; Wed, 26 Mar 2003 12:35:54 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 18:35:50 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550137BC4F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: iporpr@ietf.org Date: Wed, 26 Mar 2003 18:35:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPORPR] RPR MIB question Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , Any comments from IPORPR participants? > > -----Original Message----- > > From: Frank Kastenholz [mailto:fkastenholz@juniper.net] > > Sent: vrijdag 21 maart 2003 15:21 > > To: Wijnen, Bert (Bert); Keith McCloghrie (E-mail) > > Cc: Glenn Parsons; 'Thomas Narten'; Dan Romascanu (E-mail); 'Wijnen, > > Bert (Bert)' > > Subject: RE: Another Review of RPR MIB > > > > It's been a _long_ time since I looked at this stuff, but my _guess_ > > (and I must emphasize the word GUESS) is that it depends on how > > you model the interface -- in particular, it would depend on how > > you define the interface stacking. > > > > If you model the 802.17 interface as a single Interface, then I > > would think that the promiscuity would reflect whether the > > higher layers of software (i.e. the clients of 802.17 such as > > IP) see all the packets that "go by" the station or not. > > > > If you model the 802.17 interface as a stack of interfaces, > > some of which might be the lower-level phys (if I have my > > terminology right). Then some of these interfaces are in > > promiscuous mode, others are not, depending on whether > > they pass all packets up to the next higher interface stack > > element or not. > > > > This is my guess. It's worth the paper it's printed on :-) > > > > Frank Kastenholz > > > > Another comment... Glenn says that > > "RPR MAC never accepts unicast addresses other than to > > itself when unicast is on local ring" > > This may be what the standard says to do. However, I have to believe > > that some vendors will develop hardware that has the ability to > > promiscuously sniff every packet on the ring and report that packet > > up to the higher layers -- without stripping the packet off. Think > > of protocol analyzers (or security eavesdroppers) and their needs... > > > > > > > > >-----Original Message----- > > >From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] > > >Sent: donderdag 20 maart 2003 23:21 > > >To: 'Wijnen, Bert (Bert)' > > >Cc: 'Thomas Narten'; Dan Romascanu (E-mail); 'Frank Kastenholz' > > >Subject: Another Review of RPR MIB > > > > > >.. snip .. > > > > > >There is a concern that promiscuous mode as defined in the > > >Interface MIB (as ifPromiscuous) does not strictly apply > > >to RPR. As far a we can tell there are three possible > > >mapping options since we understand that we must support it. > > >Can you suggest which is the most appropriate? > > > > > >There 3 options are: > > > always false - > > > RPR MAC never accepts unicast addresses other than to > > > itself when unicast is on local ring > > > always true - > > > RPR MAC as a function of transit path always deals with > > > every packet regardless if it is delivered to a local > > > client > > > true - > > > bridge relay client attached and the RPR MAC accepts > > > unicast to self, multicast, remote unicast marked > > > with floodbit ; > > > false - otherwise > > > > > >Cheers, > > >Glenn. > > > _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr From mailnull@www1.ietf.org Wed Mar 26 13:32:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06445 for ; Wed, 26 Mar 2003 13:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QIr9r21343 for iporpr-archive@odin.ietf.org; Wed, 26 Mar 2003 13:53:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIr9O21340 for ; Wed, 26 Mar 2003 13:53:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06432 for ; Wed, 26 Mar 2003 13:31:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QIqtO21267; Wed, 26 Mar 2003 13:52:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QImOO21009 for ; Wed, 26 Mar 2003 13:48:24 -0500 Received: from claven.luminous.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06260 for ; Wed, 26 Mar 2003 13:26:58 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [IPORPR] RPR MIB question X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 26 Mar 2003 10:28:47 -0800 Message-ID: Thread-Topic: [IPORPR] RPR MIB question Thread-Index: AcLzvrvSv1yZPTtVQaOmvXRJifJ4QgAAyK/w From: "Peter Jones" To: Cc: "Wijnen, Bert (Bert)" , "Gal Mor (E-mail)" , "Constantinos Bassias (E-mail)" , "Glenn Parsons (E-mail)" , "Dan Romascanu (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2QImOO21010 Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi There, I'll comment, but you should know that I am the original source of the discussion in the .17 working group. The interface modeling is that we have as follows: 802.17 interface | | ------- ---- | | west Span east span interface interface Where the span interface will either be HDLC/GFP over Sonet/SDH (inc virtual concatenated pipes which obviously have a interface stack of their own), or a gige phy (NOT MAC) layer. I think in both these cases promiscuous mode will be reported as false as these interfaces are modeled as point to point and do not do MAC address processing. The RPR MAC itself is modeled as a single interface instance. The interface counters will report what is sent to/received from the higher level clients. I think of this as the "interface" being at the "topo" of the MAC. As Glenn says, we have three options for ifPromiscuousMode: 1) Always false 2) Always true 3) true is a bridge relay client is present I think that 1) is not correct because we do have a case (when a 802.1D bridge relay is attached) where the rx rules of the MAC are modified to allow it to accept extra frames (unicast destination where the DA is not a member of the ring, but not unicast to other stations on the ring)). I think that 2) is not correct because the "RPR interface" should be (is??) at the top of the MAC, and so packets passing through the transit path doesn't affect the interface counters etc. This also seems to match other MAC's like token ring or even traditional ethernet where the frames all pass thought all MACs on the segment. In these cases, promiscuous mode reports that the normal receive packet filtering has been disabled to pass all data frames to the client. I think that 3) is the closest to correct (see discussions of 1) and 2) above). I agree that it's not perfect because even when a bridge is present the MAC will not pass all frames to the higher level client (i.e. bridge relay), but it will get more that if the bridge relay is not present. I also agree with Frank that people will develop full promiscuous MACs for using in protocol analyzers. On a slightly related subject - does anyone know if their is a group working on a GFP MIB? Regards Peter -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wednesday, March 26, 2003 9:36 AM To: iporpr@ietf.org Subject: [IPORPR] RPR MIB question Any comments from IPORPR participants? > > -----Original Message----- > > From: Frank Kastenholz [mailto:fkastenholz@juniper.net] > > Sent: vrijdag 21 maart 2003 15:21 > > To: Wijnen, Bert (Bert); Keith McCloghrie (E-mail) > > Cc: Glenn Parsons; 'Thomas Narten'; Dan Romascanu (E-mail); 'Wijnen, > > Bert (Bert)' > > Subject: RE: Another Review of RPR MIB > > > > It's been a _long_ time since I looked at this stuff, but my _guess_ > > (and I must emphasize the word GUESS) is that it depends on how > > you model the interface -- in particular, it would depend on how > > you define the interface stacking. > > > > If you model the 802.17 interface as a single Interface, then I > > would think that the promiscuity would reflect whether the > > higher layers of software (i.e. the clients of 802.17 such as > > IP) see all the packets that "go by" the station or not. > > > > If you model the 802.17 interface as a stack of interfaces, > > some of which might be the lower-level phys (if I have my > > terminology right). Then some of these interfaces are in > > promiscuous mode, others are not, depending on whether > > they pass all packets up to the next higher interface stack > > element or not. > > > > This is my guess. It's worth the paper it's printed on :-) > > > > Frank Kastenholz > > > > Another comment... Glenn says that > > "RPR MAC never accepts unicast addresses other than to > > itself when unicast is on local ring" > > This may be what the standard says to do. However, I have to believe > > that some vendors will develop hardware that has the ability to > > promiscuously sniff every packet on the ring and report that packet > > up to the higher layers -- without stripping the packet off. Think > > of protocol analyzers (or security eavesdroppers) and their needs... > > > > > > > > >-----Original Message----- > > >From: Glenn Parsons [mailto:gparsons@nortelnetworks.com] > > >Sent: donderdag 20 maart 2003 23:21 > > >To: 'Wijnen, Bert (Bert)' > > >Cc: 'Thomas Narten'; Dan Romascanu (E-mail); 'Frank Kastenholz' > > >Subject: Another Review of RPR MIB > > > > > >.. snip .. > > > > > >There is a concern that promiscuous mode as defined in the > > >Interface MIB (as ifPromiscuous) does not strictly apply > > >to RPR. As far a we can tell there are three possible > > >mapping options since we understand that we must support it. > > >Can you suggest which is the most appropriate? > > > > > >There 3 options are: > > > always false - > > > RPR MAC never accepts unicast addresses other than to > > > itself when unicast is on local ring > > > always true - > > > RPR MAC as a function of transit path always deals with > > > every packet regardless if it is delivered to a local > > > client > > > true - > > > bridge relay client attached and the RPR MAC accepts > > > unicast to self, multicast, remote unicast marked > > > with floodbit ; > > > false - otherwise > > > > > >Cheers, > > >Glenn. > > > _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr