[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [IPORPR] RPR MIB question

Anyone likes to comment?

Thanks,
Bert 

-----Original Message-----
From: Peter Jones [mailto:PJones@luminous.com]
Sent: woensdag 26 maart 2003 19:29
To: iporpr@ietf.org
Cc: Wijnen, Bert (Bert); Gal Mor (E-mail); Constantinos Bassias
(E-mail); Glenn Parsons (E-mail); Dan Romascanu (E-mail)
Subject: RE: [IPORPR] RPR MIB question


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