Subject: FW: Agenda updated

From: Nic Neate <[email-masked]>
Date: Fri, 14 Nov 2008 15:46:25 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel Personal
Sent: 07 November 2008 19:29
To: [email-masked]
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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Sun, 16 Nov 2008 23:36:59 +0100

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.

> From: Nic Neate [mailto:[email-masked]] 
> Sent: Friday, November 14, 2008 4:46 PM
> To: labn - Lou Berger; [email-masked]; 
> PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> Cc: [email-masked]
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Aria - Adrian 
> Farrel Personal

---

From: Lou Berger <[email-masked]>
Date: Sun, 16 Nov 2008 17:45:57 -0500

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

---

From: Nic Neate <[email-masked]>
Date: Mon, 17 Nov 2008 00:32:57 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of labn - Lou Berger
Sent: 16 November 2008 22:46
To: Nic Neate
Cc: labn - Lou Berger; [email-masked]; Aria - Adrian Farrel Personal; [email-masked]; ALU - Dimitri Papadimitriou
Subject: RE: Agenda updated

I agree with Dimitri.

also, note:

Lou

At 05:36 PM 11/16/2008, PAPADIMITRIOU Dimitri wrote:
> > To: labn - Lou Berger; [email-masked]; PAPADIMITRIOU
> > Dimitri; Aria - Adrian Farrel Personal
> > Cc: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Aria - Adrian Farrel
> > Personal

---

From: Nic Neate <[email-masked]>
Date: Tue, 18 Nov 2008 14:06:34 +0000

Hi Lou,

Following up on our conversation in CCAMP.

I think you agreed that the "Resource Sharing" association type 2 is not relevant to this discussion.

You also said that the intent of the statement from 3.2.1 "processing and identification occur with respect to segment recovery LSPs" is to indicate that the procedures defined in RFC 4872 for setting the association ID to an LSP ID are not used.  Instead, a unique identifier should be chosen by the association source (as suggested in our draft).

I find this quite a stretch, and think a clarification would improve the chances of interoperability.

I'm also concerned with the reuse of association type 1 with different semantics in segment recovery to those defined for end-to-end recovery.  Consider the case where a segment recovery LSP is itself end-to-end protected.  Then there will be two type 1 association objects, and the merge node must process each differently.  How does the implementation you mentioned decide which is which?

You also dismissed the other issues raised in draft-rhodes-rsvp-recovery-signaling relating to protection of recovery LSPs and overlaping protection.  Please could you respond on the specific technical points raised in the draft?

I'd be glad to meet up and discuss this in person while we're in Minneapolis.

Thanks,

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of labn - Lou Berger
Sent: 16 November 2008 22:46
To: Nic Neate
Cc: labn - Lou Berger; [email-masked]; Aria - Adrian Farrel Personal; [email-masked]; ALU - Dimitri Papadimitriou
Subject: RE: Agenda updated

I agree with Dimitri.

also, note:

Lou

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 18 Nov 2008 15:16:02 +0100

hi nic,

my 2 cents here below: 

> Sent: Tuesday, November 18, 2008 3:07 PM
> To: labn - Lou Berger
> Cc: [email-masked]; Aria - Adrian Farrel Personal; 
> [email-masked]; PAPADIMITRIOU Dimitri
> I think you agreed that the "Resource Sharing" association 
> type 2 is not relevant to this discussion.
> 
> You also said that the intent of the statement from 3.2.1 
> "processing and identification occur with respect to segment 
> recovery LSPs" is to indicate that the procedures defined in 
> RFC 4872 for setting the association ID to an LSP ID are not 
> used.  Instead, a unique identifier should be chosen by the 
> association source (as suggested in our draft).
> 

where is the stretch ? in end-to-end the source of the tunnel is the
source of the association whereas in the segment case they are not the
same.

> I'm also concerned with the reuse of association type 1 with 
> different semantics in segment recovery to those defined for 
> end-to-end recovery.  Consider the case where a segment 
> recovery LSP is itself end-to-end protected.  

what does this actually mean ? does it refer to the case where there are
two 2 protecting segments ?

> Then there will 
> be two type 1 association objects, and the merge node must 
> process each differently.  How does the implementation you 
> mentioned decide which is which?
>
> You also dismissed the other issues raised in 
> draft-rhodes-rsvp-recovery-signaling relating to protection 
> of recovery LSPs and overlaping protection.  Please could you 
> respond on the specific technical points raised in the draft?

it is the same as the base case, if a segment recovery LSP is himself
protected partially the source of the association will not be the source
of protected recovery segment.
 
thanks,
-d.
> [mailto:[email-masked]] On Behalf Of labn - Lou Berger
> Cc: labn - Lou Berger; [email-masked]; Aria - 
> Adrian Farrel Personal; [email-masked]; ALU - Dimitri 
> Papadimitriou

---

From: Lou Berger <[email-masked]>
Date: Tue, 18 Nov 2008 11:05:16 -0600

Nic,

         See below.

At 08:06 AM 11/18/2008, Nic Neate wrote:
>recovery LSPs" is to indicate that the procedures defined in RFC 
>4872 for setting the association ID to an LSP ID are not 

As you know, in there's always opportunity for more detailed 
discussion in any document and that there will always be someone who 
doesn't understand the more detailed explanation.  It's up to the 
author's and the WG to agree that a draft is sufficient.  At the time 
the document was written, we did.

I accept that more language could be helpful to those new to segment 
recovery.  As I suggested to you, I believe the proper way to address 
this (and to ask for and to get formal clarification) is to open an Errata.

>end-to-end recovery.

How are the semantics different?

Per RFC4872:
    16.1.  Format

    The IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb with
    value = 199, C-Type = 1) has the format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Length             | Class-Num(199)|  C-Type (1)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Association Type        |       Association ID          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IPv4 Association Source                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Association Type: 16 bits

          Indicates the type of association being identified.  Note that
          this value is considered when determining association.  The
          following are values defined in this document.

             Value       Type
             -----       ----
               0         Reserved
               1         Recovery (R)

       Association ID: 16 bits

          A value assigned by the LSP head-end.  When combined with the
          Association Type and Association Source, this value uniquely
          identifies an association.

       Association Source: 4 or 16 bytes

          An IPv4 or IPv6 address, respectively, that is associated to
          the node that originated the association.

And RFC4873 says:

    Recovery type processing procedures are the same as those defined in
    [RFC4872], but processing and identification occur with respect to
    segment recovery LSPs.  Note that this means that multiple
    ASSOCIATION objects of type recovery may be present on an LSP.

>Consider the case where a segment recovery LSP is itself end-to-end 
>protected.  Then there will be two type 1 association objects, and 
>the merge node must process each differently.

yes, as is explicity stated in the RFC.

>How does the implementation you mentioned decide which is which?

What protocol question are you asking here?

If you want to see code, most folks don't make that available or 
charge a fee (I know of some sources of such code, and can provide 
this info offline if you'd like).

>draft-rhodes-rsvp-recovery-signaling relating to protection of 
>recovery LSPs and overlaping protection.

Per RFC4873:

    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.  Values for these fields
    are selected normally, including consideration for the make-before-
    break concept (as described in [RFC3209]).  Intermediate nodes follow
    standard signaling procedures when processing segment recovery LSPs.
    A segment recovery LSP may be protected itself using segment or end-
    to-end protection/restoration.  Note, in PSC environments, it may be
    desirable to construct the Sender_Template and Session objects per
    [RFC4090].

    When [RFC4090] isn't being used, the association between segment
    recovery LSPs with other LSPs is indicated using the ASSOCIATION
    object defined in [RFC4872].  The ASSOCIATION object is used to
    associate recovery LSPs with the LSP they are protecting.

>Please could you respond on the specific technical points raised in the draft?

I suggest bringing points you'd like to discuss to the 
list.  Although, I think resolution of the basic understanding of 
segment recovery is needed to move the discussion further.

Again, I suggest filing the errata...

Lou

>Cc: labn - Lou Berger; [email-masked]; Aria - Adrian 
>Farrel Personal; [email-masked]; ALU - Dimitri Papadimitriou