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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Sep 2006 14:25:29 +0100

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.

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.

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. 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.
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.

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.
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.

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".

5) Please state the applicability to OSPF v2 and or v3. Note that the 
Router_Cap document covers both v2 and v3

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.

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?

---

From: JP Vasseur <[email-masked]>
Date: Thu, 21 Sep 2006 08:32:08 -0400

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?

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."
> TE-MESH-GROUP TLV with multiple sub-TLVs (but the document mentions  
> "No sub-TLV is currently defined for the TE-mesh-group TLV") ?
>

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>> 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.

> 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.

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Sep 2006 17:48:53 +0100

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. 

> 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?

>> encoding for 2^32-1 groups (although this might be constrained by
>> OSPF's limit of a TLV size to 2^16 bytes.

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?

> (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?

>concern either (handled by routing). We clarified this in the

The impact on the other LSRs is exactly flooding question. Covering that in 
the security section is fine for the misconfiguration and malice cases.

>> AF>> My comment on this is that the definition of the TLVs seems
>> AF>> unclear.
>> 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.

[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. 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"

>OK fixed (I used the term "Update"), thanks.

OK

>incorporated. Here is the new text:

[SNIP]
OK

> 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?

> 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.

> 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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 22 Sep 2006 09:22:57 -0400

Hi Adrian,

On Sep 21, 2006, at 12:48 PM, Adrian Farrel wrote:

> 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.

OK

> But here are my comments:

in line,

> 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:

Ah I see your point now. Just bad wording, it should have read "
The idea is not to use that field for LSP identification per say but  
to ease the management, troubleshooting, ...
For example, an implementation could form the session name based on  
the strings on these fields.

A Tail-end name: name of the Tail-end LSR.

+ see below

>
> 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:

Well having the name definitely helps for management,  
troubleshooting, ...

> 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).
>

OK let me try to clarify adding the following text then:

The aim of the Tail-end address field is to provide a way to quickly  
identify the tail-end LSR originating the TE-MESH-GROUP and could be  
used for various purposes such such troubleshooting, management and  
so on. It does not interfere by any mean with the TE LSP attributes  
used to identify a TE LSP.

Does that clarify ?

> 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?
>

Note that would still be very reasonable ;-)

> So clearly the scaling of MPLS-TE is not directly related to the  
> scaling of automesh.
>

Well you see my point ... since these extensions are used to set up  
TE LSPs, in the vast majority of the realistic cases you'll end up  
with scalability concerns with RSVP before seeing any IGP scalability  
issue.

> 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?

And that is true with pretty much every protocol: one could always  
come up with a scenario where a bad usage of the protocol or a broken  
implementation may be a concern. Anyway, let me try to propose some  
text to close on this:

OLD:

It is expected that the number of mesh-groups be very limited (to at  
most 10 or so).
Moreover, TE mesh-group membership should not change frequently: each  
time an LSR joins or leaves a new TE mesh-group.

NEW:
The aim of the IGP extensions proposed in this document is to ease  
the provisioning of TE meshes, the number of which is generally very  
limited (10 at most or so), and should stay of this order of  
magnitude at least in a foreseeable future. Furthermore, such TE  
meshes are not expected to change frequently and thus the TE mesh- 
group membership is likely to be very stable (each time an LSR joins  
or leaves a new TE mesh-group, which is a not a frequent). An  
implementation SHOULD support mechanisms to control the frequency at  
which an LSR joins/leaves a particular a TE mesh group.

Does that address your concern ?

> 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?
>
> The impact on the other LSRs is exactly flooding question. Covering  
> that in the security section is fine for the misconfiguration and  
> malice cases.
>

Fixed, thanks !

> I could live with this, personally. We'll see whether we get any  
> more comments.
> I think the nub will be:

Hopefully I clarified with the text above.

> :-) Very well known. In fact, my mother was commenting on it to me  
> only the other day ;-)
>

ah so she should talk to my kids then ... we can work this out ;-)))

> 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.

OK, see the proposed text, and let me know what you think, I do think  
that this is sufficient but let me know.

> OK. Let's run with that and see how much we get beaten up by the  
> Security experts.

OK, thanks.

cheers,

JP.