Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01

["Adrian Farrel" <[e-mail]>]

Trying with the right address!
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, September 21, 2006 5:05 PM
Subject: Fw: Routing Directorate comments on draft-ietf-ccamp-automesh-01


> Hi,
>
> I can't recall who originated which comments. I think they came from 
> Dimitri, Acee, and me.
>
> I will copy the Directorate on my response to JP. Perhaps anyone who has 
> any further issues could follow-up direct?
>
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "JP Vasseur" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; "Ross Callon" <[e-mail]>
> Sent: Thursday, September 21, 2006 1:32 PM
> Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01
>
>
> 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.