Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Dimitri.Papadimitriou@alcatel.be Thu, 06 July 2006 06:01 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyMvt-0000BY-AX for ccamp-archive@ietf.org; Thu, 06 Jul 2006 02:01:49 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyMvq-0007Qz-Vf for ccamp-archive@ietf.org; Thu, 06 Jul 2006 02:01:49 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1FyMob-000KVj-PI for ccamp-data@psg.com; Thu, 06 Jul 2006 05:54:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1
Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel.be>) id 1FyMob-000KV7-0I; Thu, 06 Jul 2006 05:54:17 +0000
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k665esQV000902; Thu, 6 Jul 2006 07:40:54 +0200
In-Reply-To: <44AC636A.809@cisco.com>
To: Acee Lindem <acee@cisco.com>
Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OFDDAE9089.10A9690D-ONC12571A3.001CFEBB-C12571A3.001F3492@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Thu, 06 Jul 2006 07:40:49 +0200
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/06/2006 07:40:53, Serialize complete at 07/06/2006 07:40:53
Content-Type: text/plain; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
hi acee - thanks for commenting one or two hints below such as to clarify some point you mentioned here below Acee Lindem <acee@cisco.com> Sent by: owner-ccamp@ops.ietf.org 06/07/2006 03:12 To: ccamp@ops.ietf.org cc: Subject: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt Dimitri, Here are my comments on the subject document: General - Describe the relationship of OSPF areas to ASON RAs. Section 6.1 references OSPF area ID but the relationship is implied. [dp] point taken (i guess we did not do a sufficiently good job in RFC 4258 and in the eval doc. as still some questioning remains about information map) Section 3.2 - The length calculation is simply wrong. You really don't know how many prefixes you've got until you've parsed them. [dp] which length are you referring to ? the prefix or the sub-TLV ? Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV specifies the router-id. Why do you need the remote router-id in this sub-TLV? Could the 5.2 sub-TLV satisfy the requirement? [dp] it is not the router_id but the TE router_ID [dp] the issue is that there is no more a there is no more a 1:1 relationship between the Router_ID and the TE Router_ID in the present context Section 6.0 - You should NOT need to change OSPF flooding rules. In other words, I don't see the need to specify the following: The Opaque TE LSA re-origination is governed as follows: - If the target interface is associated to the same area as the one associated with the receiving interface, the Opaque LSA MUST NOT be re-originated out that interface. - If a match is found between the Advertising Router ID in the header of the received Opaque TE LSA and one of the Router ID belonging to the area of the target interface, the Opaque LSA MUST NOT be re-originated out that interface. - If these two conditions are not met the Opaque TE LSA MAY be re- originated. Rather you should specify rules for importing/exporting information between OSPF instances at different levels. [dp] your proposal is thus to revise these as import/export rules ? in order to prevent having specific flooding rules between levels the point was to not expand too much on the communication process (inside the entity) between level adjacent RCs but if this makes you more confortable i can revise as import/export rules Section 6.1 While an RA is completely contained within a single parent layer RA. A given RA may have multiple child RAs. Hence, the election algorithm is broken. [dp] to make it clear this is not an "election" process At a minimum, you must advertise all your child areas. Also, you MUST state that reachability is a precondition for considering a router eligible to pass information between levels. [dp] upper not lower (it is a discovery from a given to an upper parent viewpoint, where a child has a unique parent) Finally, since this is going to require advertisement of more than a single area-ID, please allocate a separate opaque LSA for ASON purposes. [dp] having clarified the above is that still needed ? Section 6.2 - Are you suggesting a single area ID or an area ID path (similar to the BGP AS path)? [dp] the former I guess this may work if you always advertise you own area ID when redistributing between areas (relying on the fact that a child area is completely contained by its parent). I'm going to think more about this encourage others to do the same. General: Have you considered aggregation? [dp] at which level - reachability can be aggregated for inst. Thanks, Acee
- Comments on draft-dimitri-ccamp-gmpls-ason-routin… Acee Lindem
- Re: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Dimitri.Papadimitriou
- Re: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Acee Lindem
- Re: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Dimitri.Papadimitriou
- RE: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Ong, Lyndon
- Re: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Acee Lindem
- RE: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Sadler, Jonathan B.
- RE: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Ong, Lyndon
- RE: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Dimitri.Papadimitriou
- RE: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Ong, Lyndon
- Re: Comments on draft-dimitri-ccamp-gmpls-ason-ro… Acee Lindem