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

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Zhi:

draft-ietf-ccamp-gmpls-architecture-00.txt provides some of the
information you may be looking for...

Cheers,

sudheer

Zhi-Wei Lin wrote:

> Hi Yakov,
>
> Thanks for your response. Very informative. Can I ask how an uninformed
> reader get to become informed if the docs in question cannot give the
> info (and I'm assuming there are no textbooks or university courses to
> take)...?
>
> As for the response from Eric, thanks for that info. Can I also ask for
> an uninformed implementor how exactly they go about getting informed?
> Any pointers or documents that you can point to?
>
> Zhi
>
> Yakov Rekhter wrote:
>
> > Zhi-Wei,
> >
> >
> >>Just to be clear, I am definitely one of the uninformed readers since I
> >>have joined IETF not so long ago (not everyone is part of IETF when it
> >>first started unfortunately). So Yakov, if you would be so kind as to
> >>inform an uninformed reader that would be very very much appreciated.
> >>
> >
> > There are few points I'd like to make to an uninformed reader:
> >
> > 1. As was pointed the other day by Dimitri Papadimitriou,
> > GMPLS-SIG Internet Draft "is not a textbook on how to use GMPLS-SIG".
> >
> > 2. As was also pointed out in the same e-mail from Dimitri,
> > "we can not wait until everybody in this world has no question anymore
> > or a full understanding on any technical detail in order to go forward".
> >
> > 3. Finally, please read the attached e-mail from Eric Gray to your
> > collegue from Lucent.
> >
> > 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
> >
> >
> >
> >