draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt

["Adrian Farrel" <[e-mail]>]

Hi Recovery Team,

I'm sure you considered it, but could you explain why you did not pack the
fields of the Protection Object so that they fit within the size and structure
of the existing Protection Object. This would have the considerable advantage of
being backwards compatible with existing implementations .

There seems to be some confusion as to whether the PRRO is an explicit path or a
recorded route. The abbreviation seems to suggest a recorded route and that fits
with my understanding of how secondary LSP setup might be kept diverse from the
primary path. But the text describes using the explicit route of the primary
LSP - since this may include loose hops or unspecific abstract nodes, it is not
sufficiently specific.

I think in this kind of diversity situation you need to be able to express
unnumbered links, numbered links, nodes, labels, SRLGs and even (possibly) AS
numbers. You don't seem to have all of these covered.

When considering how to set up a diverse path I would like you to look at
draft-lee-ccamp-rsvp-te-exclude-route-02.txt which already contains a mechanism
to specify exclusions.

Thanks,
Adrian

PS I notice that chunks of the text hold a striking resemblance to text I wrote
for draft-lang-ccamp-recovery-00/01. That's all to the good, but credit would be
nice.