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