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

["Jonathan Lang" <[e-mail]>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[e-mail] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Adrian,
  Thanks for your comments.  See inline for responses.

Thanks,
Jonathan

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, March 16, 2003 8:22 AM
> To: [e-mail]; Yakov Rekhter
> Cc: [e-mail]; Sudheer Dharanikota (E-mail); John Drake; 
> [e-mail]; [e-mail]; 'Dimitri 
> Papadimitriou'; 'Bala Rajagopalan'; [e-mail]
> Subject: draft-lang-ccamp-gmpls-recovery-e2e-signaling-00.txt
> 
> 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 .
Basically we wanted to allow the "LSP Flags" and "Link Flags" to be
extensible (I'm not sure we've thought of all the creative
protection/restoration schemes just yet...).

> 
> 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.
The Primary Path Route Object (PPRO - there is a typo in the draft)
contains information about the Primary Path.  This information could be
obtained from the RRO or the ERO of the Primary Path depending on the
information.  Currently, this object may contain IPv4, IPv6, label, and
unnumbered interfaces.  (SRLGs can be obtained from the IGP database
using the link/node information.)  We can add Autonomous System number
if that is useful.

> 
> 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.
We read the Lee draft, but it was more restrictive than we wanted this
to be.  We don't want the PPRO to be an "Exclude Route".  Rather, it is
a local policy issue how to use the PPRO.

> 
> 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.
Thanks.  We'll add a proper acknowledgement section to the next version.