Re: [RPRWG] RE: Evaluation of timeToLive alternatives
With all due respect, after going around a number of times on the reflector
with concerns like the one below, I would strongly recommend that the
parties to the discussion get a conference call together to resolve the
issue and then post a jointly agreed resolution to the reflector.
Our reflector is great for raising issues and for finding out who the other
concerned individuals are. It is lousy as a medium for a running
conversation. It becomes great again for posting the agreed resolution of
issues.
Please try to use it this way, and use the phone or face to face meetings to
work through issues that really do require a conversation.
Best regards,
Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: "Anoop Ghanwani" <anoop@xxxxxxxxxxxxxx>
To: "'Necdet Uzun'" <nuzun@xxxxxxxxx>; "Anoop Ghanwani"
<anoop@xxxxxxxxxxxxxx>
Cc: "'Jim Kao'" <jkao@xxxxxxxxx>; "'Mike Takefman'" <tak@xxxxxxxxx>; "David
V. James" <dvj@xxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Friday, June 28, 2002 12:58 PM
Subject: RE: [RPRWG] RE: Evaluation of timeToLive alternatives
>
>
> Necdet,
>
> The problem still remains because you'll have
> duplication if a node dies and you wrap. The TTL
> in the packet will allow it to go one node further
> than it should. It's just that the node receiving
> the packet won't be the source node, so at least
> you won't have incorrect learning. But the
> duplication problem remains.
>
> -Anoop
>
> > -----Original Message-----
> > From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> > Sent: Friday, June 28, 2002 9:03 AM
> > To: Anoop Ghanwani
> > Cc: 'Jim Kao'; 'Mike Takefman'; David V. James; stds-802-17@xxxxxxxx
> > Subject: Re: [RPRWG] RE: Evaluation of timeToLive alternatives
> >
> >
> > Anoop,
> >
> > Coming back to your example, if you do not want source the
> > see the flooded
> > packet and setting WE=0 is not an option (it seems to be it
> > is though),
> > flood it from both ringlet with TTL=N/2 where N is the number
> > of nodes on
> > the ring. Even after a wrap protection event source will not
> > see the packet
> > twice on the ringlet that it was originated from unless N/2
> > nodes disappears
> > at the same time (< convergence time of topology discovery).
> >
> > Would this solve your problem.
> >
> > Thanks.
> >
> > Necdet
> >
> > Anoop Ghanwani wrote:
> >
> > > Jim,
> > >
> > > What you say is correct for the enhanced bridging
> > > proposal, but those require local source node
> > > identification anyway. In the basic bridging proposal,
> > > as far as I understand it, all packets are flooded.
> > >
> > > -Anoop
> > >
> > > > -----Original Message-----
> > > > From: Jim Kao [mailto:jkao@xxxxxxxxx]
> > > > Sent: Thursday, June 27, 2002 10:36 PM
> > > > To: Anoop Ghanwani
> > > > Cc: 'Necdet Uzun'; Anoop Ghanwani; 'Mike Takefman'; David
> > V. James;
> > > > stds-802-17@xxxxxxxx
> > > > Subject: RE: [RPRWG] RE: Evaluation of timeToLive alternatives
> > > >
> > > >
> > > > Anoop,
> > > >
> > > > Your example is applied to flooding packet only. For the
> > > > regular known MAC bridge packet, it will take the shortest path.
> > > > The problem will not be existed.
> > > > What Necdet suggest can apply to the flooding packet.
> > > >
> > > > Thanks,
> > > > Jim
> > > >
> > > > At 05:35 PM 6/27/2002 -0700, Anoop Ghanwani wrote:
> > > >
> > > >
> > > > >Necdet,
> > > > >
> > > > >I wasn't aware that wrapping was not intended to
> > > > >work for bridged frames. All the folks in the BAH group
> > > > >have been busy scratching their heads for about 4 months
> > > > >now worrying about how to make this stuff work with both
> > > > >wrapping and steering. Poor fellas (me included!).
> > > > >
> > > > >-Anoop
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
> > > > > > Sent: Thursday, June 27, 2002 4:34 PM
> > > > > > To: Anoop Ghanwani
> > > > > > Cc: 'Mike Takefman'; David V. James; stds-802-17@xxxxxxxx
> > > > > > Subject: Re: [RPRWG] RE: Evaluation of timeToLive alternatives
> > > > > >
> > > > > >
> > > > > > Anoop,
> > > > > >
> > > > > > We do have a do not wrap bit in the packet header. If a
> > > > > > packet is bridged
> > > > > > packet it should set the WE bit right (i.e., do not WRAP).
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Necdet
> > > > > >
> > > > > > Anoop Ghanwani wrote:
> > > > > >
> > > > > > > Mike,
> > > > > > >
> > > > > > > Based on the flooding analysis that was presented
> > > > > > > at the last meeting, source stripping is required
> > > > > > > regardless of whether one does basic or enhanced
> > > > > > > bridging.
> > > > > > >
> > > > > > > Consider the following bridging example. Without
> > > > > > > source-stripping, if we're doing wrapping, and a node
> > > > > > > on the ring dies, the packet will be able to make its
> > > > > > > way back to the source with a valid TTL (because one
> > > > > > > of the nodes that would have decremented TTL has
> > > > > > > disappeared). If we don't have the source address
> > > > > > > (or some other way to identify the source) in the
> > > > > > > frame, then the source will pick up that frame as a
> > > > > > > regular bridged frame, and will learn the source
> > > > > > > address of the frame as being on the ring, which is
> > > > > > > incorrect.
> > > > > > >
> > > > > > > If we're serious about any kind of bridging, I think
> > > > > > > we will need a way to explicitly identify at least
> > > > > > > the source node (even if we don't care about
> > > > > > > explicitly identifying the destination node).
> > > > > > >
> > > > > > > -Anoop
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > > > > > > > Sent: Thursday, June 27, 2002 1:09 PM
> > > > > > > > To: David V. James
> > > > > > > > Cc: Anoop Ghanwani; stds-802-17@xxxxxxxx
> > > > > > > > Subject: Re: Evaluation of timeToLive alternatives
> > > > > > > >
> > > > > > > >
> > > > > > > > David,
> > > > > > > >
> > > > > > > > I hate to give a legalistic response, but here it goes.
> > > > > > > >
> > > > > > > > You are assuming facts not in evidence, specifically
> > > > > > > > that enhanced bridging and not basic bridging is
> > > > > > > > supported. I am a proponent of basic bridging.
> > > > > > > >
> > > > > > > > This algorithm does not work for basic bridging
> > > > > > > > and hence is flawed. To be clear, the reason it
> > > > > > > > does not work is that the the SA of a basic bridge
> > > > > > > > is not present in the frame.
> > > > > > > >
> > > > > > > > That being said, I will look at the algorithms
> > > > > > > > intent and evaluate it once the WG makes a decision
> > > > > > > > to support enhanced bridging.
> > > > > > > >
> > > > > > > > As a side note: Its the Canada Day Long weekend coming
> > > > > > > > up, so reponse times will be even slower, and the
> > > > > > > > US long weekend is following so we might have to discuss
> > > > > > > > futher in a restaurant in Vancouver.
> > > > > > > >
> > > > > > > > cheers,
> > > > > > > >
> > > > > > > > mike
> > > > > > > >
> > > > > > > > "David V. James" wrote:
> > > > > > > > >
> > > > > > > > > Mike,
> > > > > > > > >
> > > > > > > > > I can see two ways of performing timeToLive timeouts,
> > > > > > > > > listed below:
> > > > > > > > > 1) Source-specified.
> > > > > > > > > a) Before being sent, the source sets:
> > > > > > > > > frame.timeToLive=dataBase.hopsToDestination
> > > > > > > > > b) Special frame-dependent/topology-dependent
> > > > > > > > > stuff happens at the wrap point to prevent
> > > > > > > > > the estimate in (a) from becoming incorrect.
> > > > > > > > > c) Potential multidrop endpoints check and
> > > > > > > > > discardframes based on:
> > > > > > > > > frame.timeToLive==1
> > > > > > > > > No error is logged.
> > > > > > > > > d) Potential duplicates are discarded based on:
> > > > > > > > > frame.timeToLive==0
> > > > > > > > > An error is logged.
> > > > > > > > > 2) Destination-specified.
> > > > > > > > > a) Before being sent, the source sets:
> > > > > > > > > frame.timeToLive=255
> > > > > > > > > b) Potential multidrop endpoints check and
> > > > > > > > > discard frames based on:
> > > > > > > > > frame.DSID=myState.DSID
> > > > > > > > > c) Potential duplicates are discarded based on:
> > > > > > > > > frame.timeToLive>database.hopsfFromSource&&
> > > > > > > > > frame.timeToLive!=
> > > > > > > > >
> > database.hopsFromSource+database.stationsOnRing
> > > > > > > > >
> > > > > > > > > I believe that the option (2) has several benefits:
> > > > > > > > > i) The timeToLive field is processed in all frames.
> > > > > > > > > ii) The timeToLive always means distance-from-source.
> > > > > > > > > iii) Error logs are accurate, since timeToLive frames
> > > > > > > > > are never discarded during steady-state
> > operations.
> > > > > > > > >
> > > > > > > > > Can you comments on your perception of these
> > conclusions?
> > > > > > > > >
> > > > > > > > > DVJ
> > > > > > > > >
> > > > > > > > > David V. James, PhD
> > > > > > > > > Chief Architect
> > > > > > > > > Network Processing Solutions
> > > > > > > > > Data Communications Division
> > > > > > > > > Cypress Semiconductor, Bldg #3
> > > > > > > > > 3901 North First Street
> > > > > > > > > San Jose, CA 95134-1599
> > > > > > > > > Work: +1.408.545.7560
> > > > > > > > > Cell: +1.650.954.6906
> > > > > > > > > Fax: +1.408.456.1962
> > > > > > > > > Work: djz@xxxxxxxxxxx
> > > > > > > > > Base: dvj@xxxxxxxxxxxx
> > > > > > > > >
> > > > > > > > > >>-----Original Message-----
> > > > > > > > > >>From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > > > > > > > >
> > >>[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> > > > > > > > Mike Takefman
> > > > > > > > > >>Sent: Monday, June 24, 2002 8:17 PM
> > > > > > > > > >>To: djz@xxxxxxxxxxx
> > > > > > > > > >>Cc: Anoop Ghanwani; stds-802-17@xxxxxxxx
> > > > > > > > > >>Subject: Re: [RPRWG] control TTL (the 255-station and
> > > > > > > > 2000-km issue)
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>That is a fair request David, and I will do
> > > > > > > > > >>my best to accomdate it.
> > > > > > > > > >>
> > > > > > > > > >>Consider instead a host on your ring. Are you
> > > > > > > > > >>suggesting that hosts have to behave as
> > > > > > > > > >>bridges do in terms of learning the mappings
> > > > > > > > > >>of MAC addresses to bridge IDs?
> > > > > > > > > >>
> > > > > > > > > >>If so, I believe you are placing an overly
> > > > > > > > > >>large burden on hosts, one that no other 802
> > > > > > > > > >>standard has done.
> > > > > > > > > >>
> > > > > > > > > >>Either way, the scenario I pointed out for bridges
> > > > > > > > > >>(that you deflected by pointing out that I was
> > > > > > > > > >>assuming a different scenario (which is fair
> > > > > > > > > >>on your part)) is back. A bridge flooding a non local
> > > > > > > > > >>packet for the first time, a host inserting a packet
> > > > > > > > > >>that is off ring, but does not know which bridge
> > > > > > > > > >>it exits (which in my world happens for every host
> > > > > > > > > >>packet). If that station goes off the ring, ttl
> > > > > > > > > >>will be the only mechanism to stop the double
> > > > > > > > > >>delivery.
> > > > > > > > > >>
> > > > > > > > > >>Don't get me wrong, I do like your slick trick,
> > > > > > > > > >>but your solution is to change the frame format
> > > > > > > > > >>and add new features, whereas I am working to
> > > > > > > > > >>fix the currently approved text.
> > > > > > > > > >>
> > > > > > > > > >>cheers,
> > > > > > > > > >>
> > > > > > > > > >>mike
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>David James wrote:
> > > > > > > > > >>>
> > > > > > > > > >>> Mike,
> > > > > > > > > >>>
> > > > > > > > > >>> I believe part of the problem is that you claiming
> > > > > > > > > >>> something that is not documented does not fail.
> > > > > > > > > >>> Its hard to argue, as the definition can change
> > > > > > > > > >>> whenever a failure is illustrated.
> > > > > > > > > >>>
> > > > > > > > > >>> Perhaps you should document the TTL stripping
> > > > > > > > > >>> protocols with some background text and
> > illustrations?
> > > > > > > > > >>> And, clearly define the synchronizatoin points
> > > > > > > > > >>> with Discovery, that are often implied.
> > > > > > > > > >>>
> > > > > > > > > >>> In my comments to D0.3 I have done this for
> > > > DSID scoping.
> > > > > > > > > >>> While this was much easier (since it doesn't have
> > > > > > > > > >>> all of TTL stripping exceptions and
> > problems), I believe
> > > > > > > > > >>> its only fair to ask for you to do the same.
> > > > > > > > > >>>
> > > > > > > > > >>> Then, we will be able to analysize a problem,
> > > > > > > > > >>> without the problem statement constantly changing.
> > > > > > > > > >>>
> > > > > > > > > >>> Even after that, there is the basic problem that:
> > > > > > > > > >>> 1) Bidirectional flooding is required for
> > performance.
> > > > > > > > > >>> 2) A single-stations failure of (1) generates a
> > > > duplicate
> > > > > > > > > >>> 3) An multi-station failure of DSID stripping
> > > > > > > > > >>> generates no duplicates.
> > > > > > > > > >>>
> > > > > > > > > >>> Remember, 2/3 is the failure scenario you mentioned
> > > > > > > > > >>> in previous email. Having agreed, I'm a bit
> > surprized
> > > > > > > > > >>> this no longer appears to be a concern to you, just
> > > > > > > > > >>> because the repercussions of that statement
> > changed...
> > > > > > > > > >>>
> > > > > > > > > >>> DVJ
> > > > > > > > > >>>
> > > > > > > > > >>> David V. James, PhD
> > > > > > > > > >>> Chief Architect
> > > > > > > > > >>> Network Processing Solutions
> > > > > > > > > >>> Data Communications Division
> > > > > > > > > >>> Cypress Semiconductor, Bldg #3
> > > > > > > > > >>> 3901 North First Street
> > > > > > > > > >>> San Jose, CA 95134-1599
> > > > > > > > > >>> Work: +1.408.545.7560
> > > > > > > > > >>> Cell: +1.650.954.6906
> > > > > > > > > >>> Fax: +1.408.456.1962
> > > > > > > > > >>> Work: djz@xxxxxxxxxxx
> > > > > > > > > >>> Base: dvj@xxxxxxxxxxxx
> > > > > > > > > >>>
> > > > > > > > > >>> > -----Original Message-----
> > > > > > > > > >>> > From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> > > > > > > > > >>> >
> > > > [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of
> > > > > > > > > >>Mike Takefman
> > > > > > > > > >>> > Sent: Monday, June 24, 2002 1:31 PM
> > > > > > > > > >>> > To: Anoop Ghanwani
> > > > > > > > > >>> > Cc: 'djz@xxxxxxxxxxx '; 'stds-802-17@xxxxxxxx '
> > > > > > > > > >>> > Subject: Re: [RPRWG] control TTL (the
> > 255-station and
> > > > > > > > 2000-km issue)
> > > > > > > > > >>> >
> > > > > > > > > >>> >
> > > > > > > > > >>> >
> > > > > > > > > >>> > Anoop,
> > > > > > > > > >>> >
> > > > > > > > > >>> > For a protection hierarchy to work all nodes
> > > > > > > > > >>> > need to know about all failures.
> > > > > > > > > >>> >
> > > > > > > > > >>> > I agree with your comment that this needs to be
> > > > > > > > > >>> > clearly documented as part of the standard.
> > > > > > > > > >>> > Futhermore, if the WG decides to accept this
> > > > > > > > > >>> > TTL decrement algorithm it must be documented
> > > > > > > > > >>> > properly.
> > > > > > > > > >>> >
> > > > > > > > > >>> > With regard to your last question / comment.
> > > > > > > > > >>> > In wrapping, the adjacent nodes can react
> > > > immediately if
> > > > > > > > > >>> > they have the highest priority failure. Thereby
> > > > > > > > > >>> > wrapping will have quicker reaction times to
> > > > > > > > > >>> > steering. The need to broadcast in the wrapping
> > > > > > > > > >>> > case is to support the hierarchy. If no hierarchy
> > > > > > > > > >>> > was supported, then the decision could be
> > completely
> > > > > > > > > >>> > local. In this case I would still argue that a
> > > > > > > > > >>> > broadcast of the event was useful for 2 reasons.
> > > > > > > > > >>> > 1) The same algorithm supports steering which is
> > > > > > > > > >>> > the default mode
> > > > > > > > > >>> > 2) The packets that are trapped on the wrong ring
> > > > > > > > > >>> > will get killed.
> > > > > > > > > >>> >
> > > > > > > > > >>> > cheers,
> > > > > > > > > >>> >
> > > > > > > > > >>> > mike
> > > > > > > > > >>> >
> > > > > > > > > >>> >
> > > > > > > > > >>> > Anoop Ghanwani wrote:
> > > > > > > > > >>> > >
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > Mike,
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > I was trying to say that when a node
> > "unwraps" due
> > > > > > > > > >>> > > to the ring healing, it can't throw away packets
> > > > > > > > > >>> > > forever because the ring might wrap at
> > some other
> > > > > > > > > >>> > > place making it valid for this node to
> > see packets
> > > > > > > > > >>> > > with the wrap bit set. Therefore a
> > node would have
> > > > > > > > > >>> > > to set some kind of timer (on the order
> > of RTT) and
> > > > > > > > > >>> > > only throw away packets for that duration.
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > The above discussion was trying to
> > solve the problem
> > > > > > > > > >>> > > where all nodes do not know about
> > protection events;
> > > > > > > > > >>> > > only those adjacent to the fault do. If
> > > > all nodes do
> > > > > > > > > >>> > > know about protection events, the solution
> > > > you mention
> > > > > > > > > >>> > > should work, but it does need to be
> > > > documented in the
> > > > > > > > > >>> > > spec.
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > [Off topic discussion]
> > > > > > > > > >>> > > To me, it seemed like the main argument for
> > > > > > doing wrapping
> > > > > > > > > >>> > > is that only nodes adjacent to the fault need
> > > > > > to know about
> > > > > > > > > >>> > > it and react to it. If all nodes do need
> > > > to know about
> > > > > > > > > >>> > > a protection event, then it it probably
> > > > more efficient
> > > > > > > > > >>> > > for them to use steering.
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > -Anoop
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > -----Original Message-----
> > > > > > > > > >>> > > From: Mike Takefman
> > > > > > > > > >>> > > To: Anoop Ghanwani
> > > > > > > > > >>> > > Cc: djz@xxxxxxxxxxx; stds-802-17@xxxxxxxx
> > > > > > > > > >>> > > Sent: 6/24/02 12:07 AM
> > > > > > > > > >>> > > Subject: Re: [RPRWG] control TTL (the
> > 255-station
> > > > > > > > and 2000-km issue)
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > Anoop,
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > wrapping nodes always communicate with
> > every other
> > > > > > > > > >>> > > node anyway. This is necessary for protection
> > > > > > > > > >>> > > heirarchy to work. Also, given the broadcast
> > > > > > > > > >>> > > nature of messages to make steering
> > work in under
> > > > > > > > > >>> > > 50 ms, I have no concern over all nodes knowing
> > > > > > > > > >>> > > that all protection events are done and
> > the ringlets
> > > > > > > > > >>> > > are healed.
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > If one waits for the ringlets to be healed
> > > > > > > > > >>> > > and then killing the packet life is fine. Or
> > > > > > > > > >>> > > maybe I did not understand your comment.
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > mike
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > Anoop Ghanwani wrote:
> > > > > > > > > >>> > > >
> > > > > > > > > >>> > > > > > The problem with (3), which you seem
> > > > to advocate,
> > > > > > > > > >>> > > > > > is the time gap between the wrap
> > > > action and the
> > > > > > > > > >>> > > > > > the distribution/settling of the
> > wrap state
> > > > > > > > information
> > > > > > > > > >>> > > > > > in other stations. During this time
> > > > > > difference, any
> > > > > > > > > >>> > > > > > and all TTL-strip based frames will
> > > > be discarded.
> > > > > > > > > >>> > > > >
> > > > > > > > > >>> > > > > A good point david, in response
> > please consider
> > > > > > > > the following
> > > > > > > > > >>> > > > >
> > > > > > > > > >>> > > > > Never decrement when on the wrong ring.
> > > > > > Once the wrap
> > > > > > > > > >>> > > > > state is left, kill the packet if
> > the ring id
> > > > > > > > > >>> > > > > is wrong. THus going into wrap does not
> > > > cause the
> > > > > > > > > >>> > > > > packets to be prematurely lost. When
> > > > leaving wrap
> > > > > > > > > >>> > > > > the packets will be killed once
> > everyone knows
> > > > > > > > > >>> > > > > the wrap is over.
> > > > > > > > > >>> > > >
> > > > > > > > > >>> > > > Mike,
> > > > > > > > > >>> > > >
> > > > > > > > > >>> > > > Does everyone on the ring know when a
> > > > wrap has occured
> > > > > > > > > >>> > > > and when it heals? I thought wrapping was a
> > > > > > local issue
> > > > > > > > > >>> > > > and only nodes adjacent to the fault know
> > > > about it.
> > > > > > > > > >>> > > > In that case, if the node at which
> > wrapping occurs
> > > > > > > > > >>> > > > detects a heal, and for some reason doesn't
> > > > > > pull a wrap
> > > > > > > > > >>> > > > packet off, it will continue to
> > circulate forever.
> > > > > > > > > >>> > > > The node can't be dropping wrapped
> > packets forever
> > > > > > > > > >>> > > > because the wrap could occur somewhere else at
> > > > > > > > > >>> > > > which time it would be a legal packet for
> > > > > > pass-through.
> > > > > > > > > >>> > > >
> > > > > > > > > >>> > > > -Anoop
> > > > > > > > > >>> > >
> > > > > > > > > >>> > > --
> > > > > > > > > >>> > > Michael Takefman tak@xxxxxxxxx
> > > > > > > > > >>> > > Manager of Engineering, Cisco Systems
> > > > > > > > > >>> > > Chair IEEE 802.17 Stds WG
> > > > > > > > > >>> > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > > > > > > > >>> > > voice: 613-254-3399 fax: 613-254-4867
> > > > > > > > > >>> >
> > > > > > > > > >>> > --
> > > > > > > > > >>> > Michael Takefman tak@xxxxxxxxx
> > > > > > > > > >>> > Manager of Engineering, Cisco Systems
> > > > > > > > > >>> > Chair IEEE 802.17 Stds WG
> > > > > > > > > >>> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > > > > > > > >>> > voice: 613-254-3399 fax: 613-254-4867
> > > > > > > > > >>> >
> > > > > > > > > >>
> > > > > > > > > >>--
> > > > > > > > > >>Michael Takefman tak@xxxxxxxxx
> > > > > > > > > >>Manager of Engineering, Cisco Systems
> > > > > > > > > >>Chair IEEE 802.17 Stds WG
> > > > > > > > > >>2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > > > > > > > >>voice: 613-254-3399 fax: 613-254-4867
> > > > > > > >
> > > > > > > > --
> > > > > > > > Michael Takefman tak@xxxxxxxxx
> > > > > > > > Manager of Engineering, Cisco Systems
> > > > > > > > Chair IEEE 802.17 Stds WG
> > > > > > > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > > > > > > voice: 613-254-3399 fax: 613-254-4867
> > > > > > > >
> > > > > >
> > > >
> >