Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
Necdet, this discussion serves to highlight the importance of having state
diagrams that we can all refer to when explaining how any portion of the
protocol works. Without state diagrams anything can be fixed. The problem
arises in that some of those fixes may be mutually exclusive. Until we have
the state diagrams, we are never talking about the same protocol, but about
one that has this or that special feature which addresses some problem with
someone else's description of the draft.
All, I suggest that comprehensive state diagrams (or tables) are a critical
prerequisite to our understanding the capabilities and potential
deficiencies with the protocols described by our draft. We should make the
creation of them our highest priority (followed by release of the simulation
models).
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: "Necdet Uzun" <nuzun@xxxxxxxxx>
To: <djz@xxxxxxxxxxx>
Cc: "Mike Takefman" <tak@xxxxxxxxx>; "Anoop Ghanwani"
<anoop@xxxxxxxxxxxxxx>; <stds-802-17@xxxxxxxx>
Sent: Tuesday, June 25, 2002 8:38 PM
Subject: Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
>
> David,
>
> All due respect, I disagree with respect to your statement below. Please
see
> my comments below.
>
> Thanks.
>
> Necdet
>
> David James wrote:
>
> > Mike,
> >
> > With respect to:
> >
> > > an advantage of wrapping over steering is
> > > that since the decision is local it can be
> > > done quicker and there is a much lower
> > > degree of packet loss...
> >
> > This is only true if the wrapped frames are not discarded
> > before the distribution of new topology information,
>
> No, you do not need the topology information to disable the TTL decrement
> operation for the packets with the wrong ring ID. What you need is to pass
a
> single protection switching message to all nodes from the node that gets
> wrapped. Consider this, a node detects a fault and determines to go into
wrap
> and sends a broadcast protection message to all other nodes and waits for
1ms
> (processing time of a protection message: disable TTL decrement if RI does
> not match) then wraps the attachment points at packet boundary. As the
> protection packets have the highest priority in the transit path, all
nodes
> disable the TTL decrement for incorrect RI . Similarly whenever the same
node
> discovers the recovery of the fault, it first generates a protection
message
> with the appropriate recovery info and waits for 1 ms and unwraps.
>
> No, packet loss other than the 2 times 1ms waiting time.
>
> Anything wrong with this?
>
> >
> > which is the case with the selective-no-decrement TTL
> > rules being proposed by some(:>).
> >
> > 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 6:51 PM
> > > To: Anoop Ghanwani
> > > Cc: 'djz@xxxxxxxxxxx '; 'stds-802-17@xxxxxxxx '
> > > Subject: Re: [RPRWG] control TTL (the 255-station and 2000-km issue)
> > >
> > >
> > >
> > > Anoop,
> > >
> > > an advantage of wrapping over steering is
> > > that since the decision is local it can be
> > > done quicker and there is a much lower
> > > degree of packet loss, as all of the
> > > packets in flight towards the failed
> > > span can be wrapped.
> > >
> > > Service providers have presented to the WG
> > > that the lower level of packet loss in wrap
> > > was a key requirement for them. The question
> > > is what SLAs are relevant to service providers.
> > >
> > > Based on all of the input received at the WG,
> > > both steer and wrap were accomdated to allow
> > > vendors to meet the needs of their customers.
> > >
> > > cheers,
> > >
> > > mike
> > >
> > > Anoop Ghanwani wrote:
> > > >
> > > > > 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.
> > > >
> > > > Mike,
> > > >
> > > > This tells me why all nodes need to know about a
> > > > failure even when wrapping. But now that all nodes
> > > > need to know about the failure, why do I need
> > > > wrapping?
> > > >
> > > > This is a serious question. In the past, I've
> > > > always answered it by saying that with wrapping,
> > > > only nodes local to the fault need to know about
> > > > it. But if that's not the case, then I'll be
> > > > stumped every time this question comes up.
> > > > If steering can be done within 50 msec, is
> > > > doing it any faster with wrapping worth the
> > > > bandwidth overhead?
> > > >
> > > > -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
> > >
>