Re: RSVP Restart (was Re: update GMPLS signaling documents)

[Yangguang Xu <xuyg@lucent.com>]

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 then 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' requirement)
> > Again, back to the telecom world (sorry about this, yet we are talking about
> > GMPLS), typically only the established pathes are preserved. Pending requests
> > 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 may
> > lose the instance number totally
> 
> It's advertised in the neighbor's hellos.
> 
> Yakov.