Re: [RPRWG] Gandalf - question on Framing
Devendra, that's _definitely_ not the reason. The difference is only about 16
bytes, and forcing a path away from Ethernet must have some other very sound
reason. Intermediate equipments definitely won't even work with the proposed
scheme.
Pretty soon the RPR standard document will be in front of entire industry and we
need to answer to all people, so we need to be convinced we're taking an
approach that makes sense.
I am looking forward to a response from Gandalf editors or SRP authors. I'm sure
they have a solid reason for doing so and preserving the packet format that was
done about 3 years ago; all of us need a good education on it.
Regards,
Pankaj
Devendra Tripathi wrote:
> My understanding is that it has been done to help intermediate equpments
> like muxers, terminators. Such equipments should not have to go deep in
> packet as they are real fast and slim chips doing the job. I am not trying
> to justify it one way or other.
>
> Regards,
> Devendra Tripathi
> CoVisible Solutions Inc.
> (formerly VidyaWeb, Inc)
> Pune, India
> Tel: +91-20-433-1362
>
> > -----Original Message-----
> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Pankaj K Jha
> > Sent: Saturday, December 01, 2001 7:03 AM
> > To: Martin Green
> > Cc: stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] Gandalf - question on Framing
> >
> >
> >
> > Thanks a lot, Martin. I feel if the framing is similar to that of
> > an Ethernet
> > then any test equipment with existing MAC will be easily able to
> > grab the frame
> > and analyze contents. Test equipments can easily work off of any
> > Ethertype value
> > such as IP, ARP/RARP, VLAN, IPX, AppleTalk, DECnet, ... and
> > analyze packets
> > without any problems or modifications. The rfc1700 has a list of these
> > Ethertypes, and IEEE has a standard form for applying for
> > additional Ethertypes.
> > I don't know why RPR would like to break this - the RPR header
> > can also be just
> > like any of these other protocols. Note that Ethertype is not
> > just for L3 PID,
> > it is also for other shims such as 802.1Q, MPLS, etc.
> >
> > You didn't write what the _benefit_ of the SRP approach is, and
> > what the _harm_
> > is in _not_ doing the way SRP is doing. I'd appreciate your help
> > on this. To
> > date, any one that I've spoken to didn't have an answer and
> > couldn't tell me why
> > it was done that way - except that it was done in SRP and the practice has
> > perpetuated now to a standards draft proposal. A description of
> > reasoning behind
> > this would help all of us understand this better.
> >
> > Grabbing on to CRC fields is not hard - the hard part is forcing
> > vendors to use
> > special MACs for monitoring RPR packets when there is no need.
> > Even if they must
> > go to a new MAC, there is no benefit they have in this unusual
> > prefix of header
> > bytes.
> >
> > If you could refer me to some pointers to papers that describe
> > these benefits of
> > doing this non-typical framing that would be great. Would you
> > happen to know of
> > some reading material on the advantages of this approach?
> >
> > Thanks in advance for any pointers,
> >
> > Best regards,
> > Pankaj
> >
> > Martin Green wrote:
> >
> > > Pankaj,
> > >
> > > The use of same physcial layer will be of the most benefit to
> > test vendors.
> > >
> > > I'm not sure of what level of equipment you describe, but most
> > vendors will
> > > have the flexibility to deal with new/different packet
> > structures. They need
> > > this ability for such activities as error generation/detection
> > (i.e., CRC,
> > > alignment, illegal frame size, frame capture). They do not use
> > an off the
> > > shelf Ethernet MAC. To be of any use, they will have to
> > interpret the bits
> > > of the RPR frame anyway (especially the header bits). The
> > position of the DA
> > > will not make their job any easier.
> > >
> > > Regards,
> > > Martin
> > >
> > > Pankaj K Jha wrote:
> > >
> > > > Question for Gandalf editors:
> > > >
> > > > I would like some understanding on benefits and rationale
> > behind putting
> > > > RPR header bytes in _front_ of Ethernet DA/SA fields in the Gandalf
> > > > proposal. If an RPR header is put in using an Ethertype life would be
> > > > much simpler, and we'd be able to use existing systems to test/monitor
> > > > RPR packets. I don't know why header bytes are put in this way in the
> > > > Gandalf proposal. For sure, a different MAC doesn't have to have an
> > > > unusual format unless there was some benefit in doing so.
> > > >
> > > > Since the header scheme is essentially the SRP scheme, could
> > the Gandalf
> > > > editors consult original authors about the intent of doing so and then
> > > > reply.
> > > >
> > > > Being able to look at RI, TTL, etc. very early ahead of MAC addresses
> > > > isn't a valid reason since we're only talking about
> > difference of a few
> > > > bytes.
> > > >
> > > > In general, I'd like RPR WGers to start discussing different
> > elements in
> > > > different proposals so we can make informed choices on
> > different issues
> > > > at the January meeting.
> > > >
> > > > Regards,
> > > > Pankaj
> >
> >