RE: Agenda updated
Lou Berger <lberger@labn.net> Tue, 18 November 2008 16:11 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4D63A6A30 for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 18 Nov 2008 08:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.687
X-Spam-Level:
X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz10ezMUTJHk for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 18 Nov 2008 08:11:13 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8513C3A6808 for <ccamp-archive@ietf.org>; Tue, 18 Nov 2008 08:11:12 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1L2T5R-000PX7-EE for ccamp-data@psg.com; Tue, 18 Nov 2008 16:05:57 +0000
Received: from [69.89.18.151] (helo=outbound-mail-31.bluehost.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <lberger@labn.net>) id 1L2T5F-000PWL-Hb for ccamp@ops.ietf.org; Tue, 18 Nov 2008 16:05:54 +0000
Received: (qmail 537 invoked by uid 0); 18 Nov 2008 16:05:38 -0000
Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy2.bluehost.com with SMTP; 18 Nov 2008 16:05:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=eyudLN17gDzm7hAuW9EItqjXdS7+IyoZbUY1DRR7kw+N+oNWWoMlYM/+VLWO0OtxExURZlUNVEJ4a6sRjjJAiNwWq479v2v6TK2Rvwa1ftasPH2JBPVYR27eawmwx6Us;
Received: from box474.bluehost.com ([74.220.219.74] helo=LC2.labn.net) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from <lberger@labn.net>) id 1L2T4p-0002Bh-0I; Tue, 18 Nov 2008 09:05:19 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 18 Nov 2008 11:05:16 -0600
To: Nic Neate <Nic.Neate@dataconnection.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: Agenda updated
Cc: Lou Berger <lberger@labn.net>, "IBryskin@advaoptical.com" <IBryskin@advaoptical.com>, Aria - Adrian Farrel Personal <adrian@olddog.co.uk>, "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>, ALU - Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel-lucent.be>
In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.da tcon.co.uk>
References: <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A401662@ENFIMBOX1.ad.datcon.co.uk> <00275A5B436CA441900CB10936742A38015CD737@FRVELSMBS22.ad2.ad.alcatel.com> <E1L1qNx-000HNr-3l@psg.com> <11DE3EEC54A8A44EAD99D8C0D3FD72075C6A465549@ENFIMBOX1.ad.datcon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net}
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Message-Id: <E1L2T5R-000PX7-EE@psg.com>
Nic, See below. At 08:06 AM 11/18/2008, Nic Neate wrote: >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. 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. >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. 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: 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. 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). >You also dismissed the other issues raised in >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 >I'd be glad to meet up and discuss this in person while we're in Minneapolis. > >Thanks, > >Nic > > >-----Original Message----- >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >Behalf Of labn - Lou Berger >Sent: 16 November 2008 22:46 >To: Nic Neate >Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian >Farrel Personal; ccamp@ops.ietf.org; 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: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 > > > > > >
- Agenda updated Adrian Farrel
- Agenda updated Adrian Farrel
- FW: Agenda updated Nic Neate
- RE: Agenda updated PAPADIMITRIOU Dimitri
- RE: Agenda updated Lou Berger
- RE: Agenda updated Nic Neate
- RE: Agenda updated Nic Neate
- RE: Agenda updated PAPADIMITRIOU Dimitri
- RE: Agenda updated Lou Berger