RE: Agenda updated

[Nic Neate <[e-mail]>]

Hi Lou, Dimitri,

I agree that association type 2, "Resource Sharing", allows LSPs in different session to be associated.

However, RFC 4873 defines its use as being for make-before-break of segment recovery LSPs, not for associating the recovery LSP with the protected LSP.  See section 3.2.2:

3.2.2.  Resource Sharing Association Type Processing

   The ASSOCIATION object with an Association Type with the value
   Resource Sharing is used to enable resource sharing during make-
   before-break.  Resource sharing during make-before-break is defined
   in [RFC3209].  The defined support only works with LSPs that share
   the same LSP egress.  With the introduction of segment recovery LSPs,
   it is now possible for an LSP endpoint to change during make-before-
   break.

Association type 1, from RFC 4873, is still used to associate the segment recovery LSP with the protected LSP.  Hence the problem described in our draft.

Nic

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of labn - Lou Berger
Sent: 16 November 2008 22:46
To: Nic Neate
Cc: labn - Lou Berger; [e-mail]; Aria - Adrian Farrel Personal; [e-mail]; ALU - Dimitri Papadimitriou
Subject: 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:[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
> >
> >