[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Agenda updated

I agree with Dimitri.

also, note:

   3.2.1.  Recovery Type Processing

   Recovery type processing procedures are the same as those defined in
   [RFC4872], but processing and identification occur with respect to
   segment recovery LSPs.

Lou

At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:

nick,

you mention:

"3.1 Association between LSPs in different sessions

   Segment recovery protecting LSPs may have a different endpoint
   address from the corresponding protected LSP.  The protected and
   protecting LSPs are therefore in different Sessions.  The Association
   object of type 1 (recovery) is not effective in this case, as the
   Association ID can only associate to an LSP ID within the same
   Session."

but segment recovery makes use of:

"9.1. New Association Type Assignment


   IANA has made the following assignment to the "Association Types"
   Registry (see [RFC4872]) in the "ASSOCIATION (object)" section of the
   "RSVP PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-parameters.

      Value       Type
      -----       ----
        2         Resource Sharing (R) [RFC4873]"

and states:

"Consider the following topology:

                        A---B---C---D---E---F
                                 \     /
                                  G---I

   In this topology, end-to-end protection and recovery is not possible
   for an LSP going between node A and node F, but it is possible to
   protect/recover a portion of the LSP.  Specifically, if the LSP uses
   a working path of [A,B,C,D,E,F], then a protection or restoration LSP
   can be established along the path [C,G,I,E]."

[...]

"Segment protection or restoration is signaled using a working LSP and
   one or more segment recovery LSPs.  Each segment recovery LSP is
   signaled as an independent LSP.  Specifically, the Sender_Template
   object uses the IP address of the node originating the recovery path,
   e.g., node C in the topology shown above, and the Session object
   contains the IP address of the node terminating the recovery path,
   e.g., node E shown above.  There is no specific requirement on LSP ID
   value, Tunnel ID, and Extended Tunnel ID."

so where is the issue ?

-d.

> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> Sent: Friday, November 14, 2008 4:46 PM
> To: labn - Lou Berger; IBryskin@advaoptical.com;
> PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> Cc: ccamp@ops.ietf.org
> Subject: FW: Agenda updated
>
> RFC 4873 authors,
>
> Just wanted to flag that I'm presenting a problem in segment
> recovery signaling on Monday, together with a suggested solution.
>
> Problem statement:
> http://tools.ietf.org/html/draft-rhodes-rsvp-recovery-signaling-00.
> Suggested fix:
> http://tools.ietf.org/html/draft-rhodes-ccamp-rsvp-recovery-fix-00.
>
>
> Nic
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aria - Adrian
> Farrel Personal
> Sent: 07 November 2008 19:29
> To: ccamp@ops.ietf.org
> Subject: Agenda updated
>
> I have made some updates.
>
> http://www.ietf.org/proceedings/08nov/agenda/ccamp.htm
>
> Please shout if there further issues.
>
> Thanks,
> Adrian
>
>