RE: RPR MIB question
"Wijnen, Bert (Bert)" <[email protected]> Tue, 8 Apr 2003 17:00:15 +0200
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <7D5D48D2CAA3D84C813F5B154F43B15501599DE5@nl0006exch001u.nl.lucent.com> |
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_01C2FDDF.8EBB8FCA Content-Type: text/plain; charset="iso-8859-1" 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 protected]] 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 protected] <mailto:[email protected]> ] Sent: Wednesday, March 26, 2003 9:36 AM To: [email protected] Subject: [IPORPR] RPR MIB question Any comments from IPORPR participants? > > -----Original Message----- > > From: Frank Kastenholz [ mailto:[email protected] <mailto:[email protected]> ] > > 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 protected] <mailto:[email protected]> ] > > >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 protected] https://www1.ietf.org/mailman/listinfo/iporpr <https://www1.ietf.org/mailman/listinfo/iporpr> ------_=_NextPart_001_01C2FDDF.8EBB8FCA Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>RE: [IPORPR] RPR MIB question</TITLE> <META content="MSHTML 5.00.3502.5390" name=GENERATOR></HEAD> <BODY> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=261335714-08042003>From Keith McKloghrieI got back:</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=261335714-08042003><FONT size=2> <P>> Subject: Re: FW: [IPORPR] RPR MIB question</P> <P>> </P> <P>> </P> <P>> I can't get excited over this. This is just another "Specific area of</P> <P>> clarification" as defined in section 4 of RFRC 2863. As long as it</P> <P>> is defined within the neighbourhood of the generic behaviour (and it's</P> <P>> documented somewhere), then it is fine.</P> <P>> </P> <P>> Keith.</P></FONT></SPAN></FONT></DIV> <DIV> </DIV> <P><FONT size=2>Thanks,<BR>Bert </FONT></P> <BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"> <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Glenn Parsons [mailto:[email protected]]<BR><B>Sent:</B> vrijdag 4 april 2003 1:07<BR><B>To:</B> Wijnen, Bert (Bert)<BR><B>Cc:</B> Dan Romascanu (E-mail)<BR><B>Subject:</B> RE: [IPORPR] RPR MIB question<BR><BR></DIV></FONT> <P><FONT color=#0000ff face=Arial size=2>Bert,</FONT> </P> <P><FONT color=#0000ff face=Arial size=2>Thanks for following up on my email and our discussion at IETF</FONT> </P> <P><FONT color=#0000ff face=Arial size=2>Did you get any response from the MIB experts?</FONT> </P> <P><FONT color=#0000ff face=Arial size=2>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.</FONT></P> <P><FONT color=#0000ff face=Arial size=2>Thanks,</FONT> <BR><FONT color=#0000ff face=Arial size=2>Glenn.</FONT> </P> <UL> <P><FONT face=Monaco size=2>-----Original Message-----</FONT> <BR><FONT face=Monaco size=2>From: Wijnen, Bert (Bert) [</FONT><U><FONT color=#0000ff face=Monaco size=2><A href="mailto:[email protected]">mailto:[email protected]</A></FONT></U><FONT face=Monaco size=2>]</FONT> <BR><FONT face=Monaco size=2>Sent: Wednesday, March 26, 2003 9:36 AM</FONT> <BR><FONT face=Monaco size=2>To: [email protected]</FONT> <BR><FONT face=Monaco size=2>Subject: [IPORPR] RPR MIB question</FONT> </P><BR> <P><FONT face=Monaco size=2>Any comments from IPORPR participants?</FONT> </P> <P><FONT face=Monaco size=2>> > -----Original Message-----</FONT> <BR><FONT face=Monaco size=2>> > From: Frank Kastenholz [</FONT><U><FONT color=#0000ff face=Monaco size=2><A href="mailto:[email protected]">mailto:[email protected]</A></FONT></U><FONT face=Monaco size=2>]</FONT> <BR><FONT face=Monaco size=2>> > Sent: vrijdag 21 maart 2003 15:21</FONT> <BR><FONT face=Monaco size=2>> > To: Wijnen, Bert (Bert); Keith McCloghrie (E-mail)</FONT> <BR><FONT face=Monaco size=2>> > Cc: Glenn Parsons; 'Thomas Narten'; Dan Romascanu (E-mail); 'Wijnen,</FONT> <BR><FONT face=Monaco size=2>> > Bert (Bert)'</FONT> <BR><FONT face=Monaco size=2>> > Subject: RE: Another Review of RPR MIB</FONT> <BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > It's been a _long_ time since I looked at this stuff, but my _guess_</FONT> <BR><FONT face=Monaco size=2>> > (and I must emphasize the word GUESS) is that it depends on how</FONT> <BR><FONT face=Monaco size=2>> > you model the interface -- in particular, it would depend on how</FONT> <BR><FONT face=Monaco size=2>> > you define the interface stacking. </FONT><BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > If you model the 802.17 interface as a single Interface, then I</FONT> <BR><FONT face=Monaco size=2>> > would think that the promiscuity would reflect whether the</FONT> <BR><FONT face=Monaco size=2>> > higher layers of software (i.e. the clients of 802.17 such as</FONT> <BR><FONT face=Monaco size=2>> > IP) see all the packets that "go by" the station or not.</FONT> <BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > If you model the 802.17 interface as a stack of interfaces,</FONT> <BR><FONT face=Monaco size=2>> > some of which might be the lower-level phys (if I have my </FONT><BR><FONT face=Monaco size=2>> > terminology right). Then some of these interfaces are in</FONT> <BR><FONT face=Monaco size=2>> > promiscuous mode, others are not, depending on whether</FONT> <BR><FONT face=Monaco size=2>> > they pass all packets up to the next higher interface stack</FONT> <BR><FONT face=Monaco size=2>> > element or not. </FONT><BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > This is my guess. It's worth the paper it's printed on :-)</FONT> <BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > Frank Kastenholz</FONT> <BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > Another comment... Glenn says that</FONT> <BR><FONT face=Monaco size=2>> > "RPR MAC never accepts unicast addresses other than to </FONT><BR><FONT face=Monaco size=2>> > itself when unicast is on local ring"</FONT> <BR><FONT face=Monaco size=2>> > This may be what the standard says to do. However, I have to believe</FONT> <BR><FONT face=Monaco size=2>> > that some vendors will develop hardware that has the ability to </FONT><BR><FONT face=Monaco size=2>> > promiscuously sniff every packet on the ring and report that packet</FONT> <BR><FONT face=Monaco size=2>> > up to the higher layers -- without stripping the packet off. Think</FONT> <BR><FONT face=Monaco size=2>> > of protocol analyzers (or security eavesdroppers) and their needs...</FONT> <BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> > >-----Original Message-----</FONT> <BR><FONT face=Monaco size=2>> > >From: Glenn Parsons [</FONT><U><FONT color=#0000ff face=Monaco size=2><A href="mailto:[email protected]">mailto:[email protected]</A></FONT></U><FONT face=Monaco size=2>]</FONT> <BR><FONT face=Monaco size=2>> > >Sent: donderdag 20 maart 2003 23:21</FONT> <BR><FONT face=Monaco size=2>> > >To: 'Wijnen, Bert (Bert)'</FONT> <BR><FONT face=Monaco size=2>> > >Cc: 'Thomas Narten'; Dan Romascanu (E-mail); 'Frank Kastenholz'</FONT> <BR><FONT face=Monaco size=2>> > >Subject: Another Review of RPR MIB</FONT> <BR><FONT face=Monaco size=2>> > ></FONT> <BR><FONT face=Monaco size=2>> > >.. snip ..</FONT> <BR><FONT face=Monaco size=2>> > ></FONT> <BR><FONT face=Monaco size=2>> > >There is a concern that promiscuous mode as defined in the </FONT><BR><FONT face=Monaco size=2>> > >Interface MIB (as ifPromiscuous) does not strictly apply </FONT><BR><FONT face=Monaco size=2>> > >to RPR. As far a we can tell there are three possible</FONT> <BR><FONT face=Monaco size=2>> > >mapping options since we understand that we must support it.</FONT> <BR><FONT face=Monaco size=2>> > >Can you suggest which is the most appropriate?</FONT> <BR><FONT face=Monaco size=2>> > ></FONT> <BR><FONT face=Monaco size=2>> > >There 3 options are:</FONT> <BR><FONT face=Monaco size=2>> > > always false - </FONT><BR><FONT face=Monaco size=2>> > > RPR MAC never accepts unicast addresses other than to </FONT><BR><FONT face=Monaco size=2>> > > itself when unicast is on local ring </FONT><BR><FONT face=Monaco size=2>> > > always true - </FONT><BR><FONT face=Monaco size=2>> > > RPR MAC as a function of transit path always deals with</FONT> <BR><FONT face=Monaco size=2>> > > every packet regardless if it is delivered to a local</FONT> <BR><FONT face=Monaco size=2>> > > client</FONT> <BR><FONT face=Monaco size=2>> > > true - </FONT><BR><FONT face=Monaco size=2>> > > bridge relay client attached and the RPR MAC accepts</FONT> <BR><FONT face=Monaco size=2>> > > unicast to self, multicast, remote unicast marked </FONT><BR><FONT face=Monaco size=2>> > > with floodbit ; </FONT><BR><FONT face=Monaco size=2>> > > false - otherwise</FONT> <BR><FONT face=Monaco size=2>> > ></FONT> <BR><FONT face=Monaco size=2>> > >Cheers, </FONT><BR><FONT face=Monaco size=2>> > >Glenn. </FONT><BR><FONT face=Monaco size=2>> > </FONT><BR><FONT face=Monaco size=2>> </FONT><BR><FONT face=Monaco size=2>_______________________________________________</FONT> <BR><FONT face=Monaco size=2>IPORPR mailing list</FONT> <BR><FONT face=Monaco size=2>[email protected]</FONT> <BR><U><FONT color=#0000ff face=Monaco size=2><A href="https://www1.ietf.org/mailman/listinfo/iporpr" target=_blank>https://www1.ietf.org/mailman/listinfo/iporpr</A></FONT></U> </P><BR></UL></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C2FDDF.8EBB8FCA--