[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RSVP Restart (was Re: update GMPLS signaling documents)
Yangguang,
> Indeed, you didn't answer my questions.
Perhaps it would be more correct to say that I didn't answer
your questions *to your satisfaction*. And if that is the case, then
I hope that the attached e-mail from Eric Gray (that he let me repost
to the list) would answer your questions to your satisfaction.
> Instead of informed readers, more
> important is to have better informed writers.
See the attached.
> BTW, I have no intention to let you design my product at all.
Glad to hear this !!!
Yakov.
---------------------------------------------------------------------
Date: Fri, 19 Oct 2001 15:38:58 EDT
To: Yangguang Xu <xuyg@lucent.com>
cc: Yakov Rekhter <yakov@juniper.net>
From: Eric Gray <eric.gray@sandburst.com>
Subject: Re: RSVP Restart (was Re: update GMPLS signaling documents)
Yangguang,
Careful, don't let this discussion descend into the nether regions of
name calling and finger pointing. :-)
The fact that the seeming remote neighbors use RSVP Hello is clear
once you realize that - for the purposes of hierarchical LSP setup, they
are adjacent. You may recall this from an off-line discussion we had.
Yakov's comment was simply stating that it is not a part of standard's
development to make an implementer's cook-book. He was not (I think)
trying to imply that you could not write your own implementation. He was
just saying that the effort of achieving interoperability falls on the people
doing the implementation not on the people doing the standard. The bare
information is there, but the work is up to you.
As you know, the standard is not complete until several implementations
have achieved interoperability independently. But the opportunity to get in
the market stems from being one of those implementations - and there is
zero motivation for any implementer to make this task easy for all others.
One of the costs associated with the 'running code' part of IETF mistique
is that standards are written by implementers.
Unless and until that changes, you just have to learn to deal with it. :-)
You wrote:
> Indeed, you didn't answer my questions. Instead of informed readers, more
> important is to have better informed writers.
>
> BTW, I have no intention to let you design my product at all.
>
> Yangguang
>
> Yakov Rekhter wrote:
> >
> > Yangguang,
> >
> > > Yakov,
> > >
> > > Further questions in-line. Regards,
> >
> > Further responses in-line...
> >
> > > Yangguang
> > >
> > > > Couple of points:
> > > >
> > > > (1) First of all, you do run RSVP Hello between C and F.
> > >
> > > Is this specified somewhere? Or it's your proposal.
> >
> > What I mentioned in the above should be abundantly obvious to the
> > informed reader of RSVP and LSP Hierarchy specs.
> >
> > > Then, is there a scalability issue here?
> >
> > No.
> >
> > > Also, C and F could be thousands mile away (in the transport
> > > network) and the control channel bandwidth is expensive.
> >
> > GMPLS assumes that control channel is more than just 56Kbits/sec link.
> >
> > Or to put it differently, control channels used by GMPLS have more than
> > enough capacity for RSVP Hellos.
> >
> > > > (2) Since L1 is advertised as an FA into OSPF/ISIS, F should
> > > > be able to recover the Interface ID it assigns to L1 from
> > > > a combination of (a) the OSPF/ISIS link state database that
> > > > F would recover, and (b) the Forward Interface ID (the one
> > > > assigned by C).
> > >
> > > Can OSPF/ISIS happen to be on the same controller as RSVP-TE? I guess the
n it
> > > has to recover its FA info first. How?
> >
> > The answer should be abundantly obvious to the informed reader.
> >
> > And to make it crystal clear, I have no intention in designing your
> > products for you.
> >
> > > > > Let us say the node can resynchronize its neighbor if
> > > > > the neighbor restarts and requests state recovery. But
> > > > > the issue is how a node can advertise that it does not
> > > > > need recovery since all its state was preserved?
> > > >
> > > > By treating is the same way as the way the spec handles
> > > > control channel fault.
> > > >
> > >
> > > If a node can recover states from NVRAM or OS (this solution is
> > > cheaper and have been implemented). It may not implement the spec.
> > > How could a neighboring node, which implements the spec, not tear
> > > down data connections mistakenly? Similar to a backward compatibility
> > > problem, even not.
> >
> > Stating the obvious: interoperability with a node that doesn't implement
> > the spec is outside the scope of the spec.
> >
> > > > > RECOVERY LABEL does not come into picture unless the node
> > > > > that is upstream to the restarting node has already received
> > > > > a Resv.
> > > >
> > > > Wrong. Quoting 9.5.3:
> > > >
> > > > Upon detecting a restart with a neighbor that supports state
> > > > recovery, a node SHOULD refresh all Path state shared with that
> > > > neighbor.
> > > >
> > > > So, as you can hopefully see from the above, the upstream node doesn't
> > > > wait until it receives a Resv.
> > > >
> > >
> > > Then this may not meet carriers' requirement. (see IPO carriers' requirem
ent)
> > > Again, back to the telecom world (sorry about this, yet we are talking ab
out
> > > GMPLS), typically only the established pathes are preserved. Pending requ
ests
> > > may be purged/aborted. Then how?
> >
> > Note the verb is "SHOULD", not "MUST". The rest should be
> > obvious to the informed reader.
> >
> > > > > In case of PSC devices, it may be OK to remove state that
> > > > > is not resynchronized at the end of the recovery period,
> > > > > and the recovery period advertised might reflect that.
> > > > > But for LSPs in transport networks, one might want to
> > > > > have a different recovery period to avoid any LSP from
> > > > > going down because of recovery timer expiry.
> > > >
> > > > There is no requirement for a node to advertise exactly the
> > > > same Restart_Cap on all the interfaces. So, on PSC interfaces
> > > > the node could advertise that it will remove the state that
> > > > isn't syncronized at the end of the recovery period, while
> > > > on the TDM interface precisely the same node could advertise
> > > > that the LSPs would be kept even after the recovery time expires.
> > > >
> > >
> > > So, restart_cap is per interface based?
> >
> > yes.
> >
> > > Is the spec going to be enhanced/clarified?
> >
> > The current spec need not be enhanced/clarified - what I mentioned in the
> > above should be abundantly obvious to the informed reader.
> >
> > > > > The first problems seems to be there still - consider two
> > > > > adjacent nodes restarting. They both act both as the restarting
> > > > > node as well as the neighbor to the restarting node. So, once
> > > > > they learn the state from the upstream neighbor, do they use
> > > > > suggested label or the recovery label when they send the path
> > > > > message to the just restarted downstream neighbor?
> > > >
> > > > The recovery label.
> > > >
> > > > The following should be added to the existing text from the document:
> > > >
> > > > In the special case where a restarting node also has a restating
> > > > downstream neighbor, a Recovery_Label object should be used instead
> > > > of a Suggested_Label object.
> > >
> > > How does a recovering NE know that its neighbor is also recovering? it ma
y
> > > lose the instance number totally
> >
> > It's advertised in the neighbor's hellos.
> >
> > Yakov.
--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray