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

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

Also this one.
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "JP Vasseur" <[e-mail]>
Cc: <[e-mail]>; "Ross Callon" <[e-mail]>; 
<[e-mail]>
Sent: Thursday, September 21, 2006 5:48 PM
Subject: Re: Routing Directorate comments on draft-ietf-ccamp-automesh-01


> Hi JP,
>
> Thanks for addressing the comments. I have forwarded these to the Routing 
> Directorate and copied them on this email to let them respond if they 
> want. But here are my comments:
>
>>> 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.
>
> Hmmm, yes it is not an LSP name, but recall that the LSP is identified by 
> a combination of Session and Sender Template, and that the Session 
> includes the destination IP address. In Section 3.2 I see:
>   - A Tail-end name: string used to ease the TE-LSP naming.
> and in Section 4.1:
>   - A Tail-end name: a variable length field used to facilitate the TE
>   LSP identification.
>
> These definitions seem to imply that the tail-end name is used as an 
> identifier for the LSP. The question that will be asked is: How does this 
> identification of an LSP differ from the conventional identification of 
> the LSP?  Given that you also have:
>   - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
>   tail-end TE LSP address by other LSRs belonging to the same mesh-
>   group
> it appears that the tail-name is superfluous information.
>
> So, perhaps the name is present for diagnostic purposes? Perhaps it is 
> there to ease OAM? But it does not seem to play any role in the protocol 
> procedures as it is not explicitly mentioned later in the I-D (e.g. 
> Section 5).
>
> How would a node behave if it received a mesh group advertisement that 
> indicated a tail-end address that did not appear to match its record of 
> the tail-end name?
>
>>> 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.
>
> What about 100 meshes comprising 10 routers each?
> I make that only 9,000 TE LSPs.
>
> So clearly the scaling of MPLS-TE is not directly related to the scaling 
> of automesh.
>
> What this comes down to is your statement about how automesh will be used. 
> I think we can all accept that this is the problem space that you intend 
> to deploy in, and that is great. But the original point from the Routing 
> Directorate was that there is nothing in the I-D that imposes this 
> restriction. So how can we say that the protocol extensions will scale?
>
>> - 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.
>
> Again, the concern raised is that the problem space you intend to deploy 
> in is, indeed, limited in this way. All good. But how can we say whether 
> the protocol extensions will be used differently in the future? What 
> controls are there over constructing a mesh where joins and prunes are 
> frequent?
>
>>> 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.
>
> The impact on the other LSRs is exactly flooding question. Covering that 
> in the security section is fine for the misconfiguration and malice cases.
>
>>> 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
>>> AF>> unclear.
>>> AF>> From figure 2, it appears that some additional information can be
>>> AF>> present in the TLV after the fields listed, and (reading
>>> AF>> between the lines) it would appear that this additional
>>> AF>> information is a series of repeats of the set of fields to
>>> AF>> define multiple mesh groups.
>>> AF>> This could usefully be clarified considerably.
>>
>>
>> You're absolutely right. The figures have been modified:
>>
>> (example show below):
>
> [SNIP]
> Looks good to me.
>
>>> AF>> But it is now unclear to me whether a single router can be a
>>> AF>> member of IPv4 an IPv6 mesh groups. It would seem that
>>> AF>> these cannot be mixed within a single TLV, and multiple
>>> AF>> TLVs (one IPv4 and one 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.
>
> OK. That's fine.
> I think you want to make a couple of changes:
> - "at most one instance MUST appear" is ambiguous since it will
>  be confused with "an instance MUST appear". I suggest you
>  reword as "MUST NOT include more than one of each of"
> - "If the OSPF TE-MESH-GROUP TLV (IPv4 or IPv6) occurs
>  more than once" should really be phrased as "If the either the
>  IPv4 or IPv6 OSPF TE-MESH-GROUP TLV occurs more
>  than once".  Ditto for the IS-IS sub-TLV.
> - Two instances of "will be silently ignored" should read "SHOULD
>  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.
>
> OK
>
>>> 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:
>
> [SNIP]
> OK
>
>>> 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 could live with this, personally. We'll see whether we get any more 
> comments.
> I think the nub will be:
> 1. whether your "should not" can be "SHOULD NOT"
> 2. what does "frequently mean"?
> 3. what is there in this I-D to say that an LSR does not join/leave a
>   TE mesh-group very often?
>
>> I guess that this is sufficiently explicit: it is a well-known fact
>> that LSRs are infrequently added or removed to a TE mesh.
>
> :-) Very well known. In fact, my mother was commenting on it to me only 
> the other day ;-)
>
> Consider the case where PE membership of an automesh is dependent on 
> whether there are C-nodes subscribed to some service.
>
> Perhaps this well known fact could be noted in the Introduction to this 
> I-D which is AFAIK the only IETF document on the subject of automesh.
>
>>> 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:
>
> [SNIP]
> OK. Let's run with that and see how much we get beaten up by the Security 
> experts.
>
> Cheers,
> Adrian