RE: Agenda updated

[Lou Berger <[e-mail]>]

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:[e-mail]]
> > Sent: Friday, November 14, 2008 4:46 PM
> > To: labn - Lou Berger; [e-mail];
> > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> > Cc: [e-mail]
> > 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: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Aria - Adrian
> > Farrel Personal
> > Sent: 07 November 2008 19:29
> > To: [e-mail]
> > 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
> >
> >