Essentially there are three steps in setting up a dynamic LSP.
1)TE information is distributed by the IGP.
2) The source of the LSP uses the TE information supplied by the IGP to computes a path satisfying the constraints.
3) RSVP will signal the LSP along the computed path.
Steps 1 and 3 require interoperability between vendors and hence we have drafts addressing these issues.
Step 2 does not involve any interoperability issues. Vendors are free to choose their own algorithm for path computation.
Crank back may be required if the source does not have an up to date information about the TE topology. I don't know if anyone has addressed this issue yet.
Girish
-----Original Message-----
From: Greene, Jeremy [mailto:Jeremy.Greene@sonusnet.com]
Sent: Friday, June 15, 2001 9:50 AM
To: Te-Wg (E-mail)
Subject: cr computation
In the ospf/isis-te drafts, a method for distributing constraint information
is described without any discussion of path computation. Is that because:
a) It's assumed people can figure out and or want to do their own thing,
such as spf or other? Or is it intended to be covered in separate documents?
b) rsvp would be used hop-by-hop, with the next hop a function of the tspec
and advertised constraints; but if this is true, wouldn't some form of
crank-back be required?
Jeremy
btw, do others find the diff-serv/mpls/te draft set to be rather confusing?
It seems like it should be easier, if not at least (a lot) shorter, to
explain how to: a) map a dscp onto an lsp b) have the lsp indicate the
flow's dscp with and without the shim header c) have, or have not, the lsp
be a diff-serv flow based on the mapped dscp d) use the ospf/isis te lsa to
advertise phbs/dscps and e) request a phb path using rsvp (why tied to
mpls?)