Subject: RE: [IPORPR] RPR MIB question

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 8 Apr 2003 17:00:15 +0200

From Keith McKloghrieI got back:
> Subject: Re: FW: [IPORPR] RPR MIB question

> I can't get excited over this. This is just another "Specific area of

> clarification" as defined in section 4 of RFRC 2863. As long as it

> is defined within the neighbourhood of the generic behaviour (and it's

> documented somewhere), then it is fine.

> Keith.

Thanks,
Bert 

-----Original Message-----
From: Glenn Parsons [mailto:[email-masked]]
Sent: vrijdag 4 april 2003 1:07
To: Wijnen, Bert (Bert)
Cc: Dan Romascanu (E-mail)
Subject: RE: [IPORPR] RPR MIB question

Bert, 

Thanks for following up on my email and our discussion at IETF 

Did you get any response from the MIB experts? 

I need to submit an updated draft next week.  If we have no guidance, then (from an IEEE 802.17 perspective) we'll leave this open until the next revision.

Thanks, 
Glenn. 

	-----Original Message----- 
From: Wijnen, Bert (Bert) [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, March 26, 2003 9:36 AM 
To: [email-masked] 
Subject: [IPORPR] RPR MIB question 

	Any comments from IPORPR participants? 

	> > -----Original Message----- 
> > From: Frank Kastenholz [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > 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:[email-masked] <mailto:[email-masked]> ] 
> > >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 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/iporpr <https://www1.ietf.org/mailman/listinfo/iporpr>