Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
JP Vasseur <jvasseur@cisco.com> Thu, 21 September 2006 12:41 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNrU-0008Gx-NL for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:41:04 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNrP-0004Xl-9a for ccamp-archive@ietf.org; Thu, 21 Sep 2006 08:41:04 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1GQNj1-000KC1-EX for ccamp-data@psg.com; Thu, 21 Sep 2006 12:32:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1
Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <jvasseur@cisco.com>) id 1GQNiw-000KAh-BG for ccamp@ops.ietf.org; Thu, 21 Sep 2006 12:32:15 +0000
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2006 08:32:13 -0400
X-IronPort-AV: i="4.09,195,1157342400"; d="scan'208,217"; a="103674977:sNHT66581864"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8LCWDqY011817; Thu, 21 Sep 2006 08:32:13 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8LCWCuI004303; Thu, 21 Sep 2006 08:32:13 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:32:12 -0400
Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Sep 2006 08:32:11 -0400
In-Reply-To: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe>
References: <0ae101c6ce93$8e36fac0$89849ed9@your029b8cecfe>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3
Content-Type: multipart/alternative; boundary="Apple-Mail-36-146102614"
Message-Id: <A2912454-4C2A-439E-8053-C247B6FDA987@cisco.com>
Cc: ccamp@ops.ietf.org, Ross Callon <rcallon@juniper.net>
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
Date: Thu, 21 Sep 2006 08:32:08 -0400
To: Adrian Farrel <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 21 Sep 2006 12:32:11.0095 (UTC) FILETIME=[F5C81670:01C6DD79]
DKIM-Signature: a=rsa-sha1; q=dns; l=32785; t=1158841933; x=1159705933; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20<jvasseur@cisco.com> |Subject:Re=3A=20Routing=20Directorate=20comments=20on=20draft-ietf-ccamp-automes h-01 |To:=22Adrian=20Farrel=22=20<adrian@olddog.co.uk>; X=v=3Dcisco.com=3B=20h=3DMEBChjdj4/CIq2s4jZyCacxjCHY=3D; b=sXj5s6poseORm4S1h5YvITMwou/LKpYraejs7ohNNUIhXCNhklGdGcrodhrzcKQ4vJxkPtgd kD8SKBPcfD7rAs1u+sPkPgec9jn8k4gmeMRMQFhNZFSA89AEcESREZE6;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; );
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2df02f1a0db129c5d94869f6959903ec
Hi Adrian, On Sep 2, 2006, at 9:25 AM, Adrian Farrel wrote: > Hi, > > We held an additional last call for this draft in the IGP working > groups and received some further comments that JP has just > addressed in a new revision. > > We have also received some comments from a review in the Routing > Directorate that I am précising below. JP, authors: please look > through these and let us know your proposals for dealing with them. > Sure, in line. > Thanks, > Adrian > > === > > 1) The Tail-end name field facilitates LSP identification. Is this > a new form of LSP identification? > If it is not new, then there should be a reference to RFC3209 and a > statement of which RFC3209 fields are mapped to this IGP field. > If it is not new then there is a significant concern that a new > identification is being introduced when it is not needed. As indicated in the document the string refers to a "Tail-end" name, not an TE LSP name: thus it does not replace the session name of the SESSION-ATTRIBUTE object defined in RFC3209. > > 2) The document mentions that the number of mesh groups is limited > but potentially (depending on encoding) provides for binary > encoding for > 2^32-1 groups (although this might be constrained by OSPF's limit > of a TLV size to 2^16 bytes. > The document (and the authors) state that scaling of these > extensions is not an issue because only a small number of mesh > groups are likely to be in existence in a network, and any one > router is unlikely to participate in more than a very few. > There are two concerns: > a) Whenever we say that something in the Internet is limited, > history usually proves us wrong. And that's undoubtedly a good news :-) > Indeed, there is already a > proposal (draft-leroux-mpls-p2mp-te-autoleaf-01.txt) that uses a > similar mechanism for a problem that would have far more groups. Two comments: - Mesh groups are used to set up TE LSP meshes. If we consider let say 10 meshes comprising 100 routers each, that gives us 99,000 TE LSPs. One can easily see that the number of meshes is unlikely to explode in a foreseeable future. If it turns out to be the case, we'll have other scalability issues to fix before any potential with the IGP. - More importantly, the dynamics of joining a TE mesh is such that IGP updates are used to advertise to TE mesh group membership change (join or prune), which are indeed expected to be very unfrequent. > b) The I-D does not itself impose any reasonable limits on the > number of groups with the potential for a single router (by > misconfiguration, design, or malice) advertising a very large > number of groups. > Thus, it appears that the scaling concerns are not properly > addressed in this I-D. > Not sure to see the point here. If indeed, a large number of TE MESH GROUPs were advertised, this would not impact the other LSRs since they would not create any new TE LSPs trying to join the new TE-MESH- GROUP. In term of amount of flooded information, this should not be a concern either (handled by routing). We clarified this in the security section. > 3) The document mentions that "The TE-MESH-GROUP TLV is OPTIONAL > and must at most appear once in a OSPF Router Information LSA or > ISIS Router Capability TLV." but for addition/removal it mentions > "conversely, if the LSR leaves a mesh-group the corresponding entry > will be removed from the TE-MESH-GROUP TLV." > What are these "entries" referring to - that there is a top-level > TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions > "No sub-TLV is currently defined for the TE-mesh-group TLV") ? > > AF>> My comment on this is that the definition of the TLVs seems > unclear. > AF>> From figure 2, it appears that some additional information can be > AF>> present in the TLV after the fields listed, and (reading > between the > AF>> lines) it would appear that this additional information is a > series of > AF>> repeats of the set of fields to define multiple mesh groups. > AF>> This could usefully be clarified considerably. > You're absolutely right. The figures have been modified: (example show below): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mesh-group-number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tail-end IPv4 address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name length | Tail-end name n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) > AF>> > AF>> But it is now unclear to me whether a single router can be a > member > AF>> of IPv4 an IPv6 mesh groups. It would seem that these cannot be > AF>> mixed within a single TLV, and multiple TLVs (one IPv4 and one > AF>> IPv6) are prohibited. OK the text requires some clarification. What is prohibited is to have two IPv4 sub-TLV or two IPv6 sub-TLV but one of each is permitted. New proposed text to clarify: The TE-MESH-GROUP TLV is OPTIONAL and at most one IPv4 instance and one IPv6 instance MUST appear in a OSPF Router Information LSA or ISIS Router Capability TLV. If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs more than once within the OSPF Router Information LSA, only the first instance is processed, subsequent TLV(s) will be silently ignored. Similarly, If the ISIS TE-MESH-GROUP sub-TLV (IPv4 or IPv6) occurs more than once within the ISIS Router capability TLV, only the first instance is processed, subsequent TLV(s) will be silently ignored. > > 4) Small terminology issue in section 5.1 it says: "Note that both > operations can be performed in the context of a single refresh." > This is not a refresh. It is a trigger/update. A better term for > OSPF would be "LSA origination". > OK fixed (I used the term "Update"), thanks. > 5) Please state the applicability to OSPF v2 and or v3. Note that > the Router_Cap document covers both v2 and v3 Indeed, Thanks for the comments. The OSPFv3 aspects have been incorporated. Here is the new text: The TE-MESH-GROUP TLV is advertised within an OSPF Router Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) and within a new LSA (Router Information LSA) for OSPFv3 ([RFC2740]). ... As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the flooding scope of the Router Information LSA is determined by the LSA Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. For OSPFv2 Router Information opaque LSA: - Link-local scope: type 9; - Area-local scope: type 10; - Routing-domain scope: type 11. In this case, the flooding scope is equivalent to the Type 5 LSA flooding scope. For OSPFv3 Router Information LSA: - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 bits cleared; - Area-local scope: OSPFV3 Router Information LSA with the S1 bit set and the S2 bit cleared; - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit cleared and the S2 bit set. A router may generate multiple OSPF Router Information LSAs with different flooding scopes. The TE-MESH-GROUP TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA depending on the MPLS TE mesh group profile: - If the MPLS TE mesh-group is contained within a single area (all the LSRs of the mesh-group are contained within a single area), the TE-MESH-GROUP TLV MUST be generated within an Area-local Router Information LSA; - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- group TLV MUST be generated within a Routing-domain scope router information LSA. > > 6) The term "fairly static" at the end of section 5.1 is > meaningless without some relative context. > Presumably this relates to the number times an LSR joins or leaves > a mesh group over time. > Is it intended to be relative to the IGP refresh period? > Please clarify in an objective rather than a subjective way. > Right, this requires clarification. Here is the new text: Moreover, TE mesh-group membership should not change frequently: each time an LSR joins or leaves a new TE mesh-group. I guess that this is sufficiently explicit: it is a well-known fact that LSRs are infrequently added or removed to a TE mesh. > 7) The security section (section 8) is inadequate and will > undoubtedly be rejected by the security ADs. At the very least, the > I-D needs a paragraph (i.e. more than one or two lines) explaining > why there are no new security considerations. But what would be the > impact of adding false mesh groups to a TLV? Is there anything > (dangerous) that can be learned about the network by inspecting > mesh group TLVs? > The following section has been added: No new security issues are raised in this document. Any new security issues raised by the procedures in this document depend upon the opportunity for LSAs/LSPs to be snooped, the ease/difficulty of which has not been altered. Security considerations are covered in [RFC2328] and [RFC2740] for the base OSPF protocol and in [RFC1194] for IS-IS. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available. Note that intentional or unintentional advertisement of "fake" TE Mesh Groups by an LSR A does not have any impact on other LSRs since an LSR B would only try to signal a TE LSP torward that advertizing LSR A to join the advertized TE Mesh TE Group if and only if such TE Mesh Group is also locally configured on LSR B. + new references added. Does that address the comments ? Thanks. JP.
- Routing Directorate comments on draft-ietf-ccamp-… Adrian Farrel
- Re: Routing Directorate comments on draft-ietf-cc… JP Vasseur
- Re: Routing Directorate comments on draft-ietf-cc… Adrian Farrel
- Re: Routing Directorate comments on draft-ietf-cc… JP Vasseur