Subject: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast

From: Huub van Helvoort <[email-masked]>
Date: Mon, 8 Apr 2019 11:58:28 +0200

All,

I’ve been selected as an MPLS-RT reviewer for
draft-zzhang-mpls-rmr-multicast,

which is currently a candidate for MPLS WG adoption.

In the abstract is stated:

With Resilient MPLS Rings (RMR), although all existing multicast
procedures and solutions can work as is, there are optimizations that
could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
for both mLDP and RSVP-TE P2MP tunnels.

I have carefully read the draft but I could not find any
justification

for the optimisation that could be done.

I also did not find any indication how this optimisation has to be

deployed. Do all the nodes in the ring, or in the network have to

support this optimisation before it becomes effective.

I think these issues have to be documented before this draft
can

be adopted as WG draft.

Best regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 8 Apr 2019 10:42:44 +0000

Hi Huub,

Thank you for your review and comments. Please see zzh> below.

Non-Juniper
From: Huub van Helvoort <[email-masked]>
Sent: Monday, April 8, 2019 5:58 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

All,

I've been selected as an MPLS-RT reviewer for draft-zzhang-mpls-rmr-multicast,
which is currently a candidate for MPLS WG adoption.

   for both mLDP and RSVP-TE P2MP tunnels.
I have carefully read the draft but I could not find any justification
for the optimisation that could be done.

Zzh> By "justification", do you mean "need"? I thought the following text provides that:

   For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR
   discovers leaves and signals one sub-LSP for each leaf.  Even though
   the forwarding state is merged at each hop (i.e, one incoming label
   mapping to multiple outgoing entries), the control plane maintains
   individual sub-LSP state.  This leads to lots of redundant state on
   routers close to the ingress.

Zzh> Or do you mean "why" the optimization COULD be done? The key is that this is a ring, and:

   ... As the PATH message passes along the ring, the leaves
   send RESV messages, but only one RESV message reaches the tunnel
   ingress.

Zzh> If you mean "how" it is done, I thought the following describes it:

   ... With RMR, this can be optimized such
   that only a single LSP is signaled, with all the leaves listed in the
   PATH message.  As the PATH message passes along the ring, the leaves
   send RESV messages, but only one RESV message reaches the tunnel
   ingress.

   The ingress LSR may also send PATH messages in both directions, so
   that the tunnel is set up in such a way that minimum delay is
   incurred for traffic to reach all leaves.  Alternatively, the ingress
   may send PATH message only in one direction for best bandwidth
   utilization.  For example, a leaf D is three hops away from the
   ingress A in clockwise direction (A,B,C,D) and four hops away in the
   other direction (A,E,F,G,D), but G is also a leaf so it may be better
   to just send the PATH message in the anticlockwise direction.

   Each router establishes forwarding state accordingly.  Transit
   routers switches traffic towards downstream.  A transit router could
   also be a leaf router and in that case it does "drop and continue" -
   sends traffic off the ring and switches traffic downstream.

2.1.  Tunnel Protection and FRR

   Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to
   itself.  As these LSPs are self-signaled after the discovery of the
   ring, they can be used to protect P2MP LSPs on ring.  So neither mLDP
   nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node
   protection.

Zzh> The context is RMR - Resilient MPLS Ring. All routers on the ring need to support RMR and the multicast optimization for this to be effective. I can make that clear.

I think these issues have to be documented before this draft can
be adopted as WG draft.

Zzh> Besides explicitly stating that all routers on the ring need to support the RSVP-TE P2MP optimization for it to be effective, please advise further how the first issue can be better documented.

Thanks.
Jeffrey

Best regards, Huub.

--

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 8 Apr 2019 22:07:47 +0200

Hello Jeffrey,

Please see my response in-line [hvh].

Hi Huub,

Thank you for your review and
comments. Please see zzh> below.

Non-Juniper

From: Huub van Helvoort
<[email-masked]>

To: [email-masked]

Cc: [email-masked];
[email-masked]

Subject: MPLS-RT review of
draft-zzhang-mpls-rmr-multicast

All,

I’ve been selected as an MPLS-RT reviewer
for draft-zzhang-mpls-rmr-multicast,

I have carefully read the draft but I could
not find any justification

Zzh> By
“justification", do you mean “need”? I thought the
following text provides that:

For a conventionally signaled RSVP-TE P2MP
tunnel, an ingress LSR

discovers leaves and signals one sub-LSP for each
leaf.
Even though

the forwarding state is merged at each hop (i.e,
one incoming label

mapping to multiple outgoing entries), the
control plane maintains

individual sub-LSP state.  This leads to lots
of redundant state on

[hvh] "lots of state" - can you be more specific? is the redundancy
10% or 90% ?

Zzh> Or do you mean
“why” the optimization COULD be done? The key is that
this is a ring, and:

… As the PATH message passes along the ring, the
leaves

send RESV messages, but only one RESV message
reaches the tunnel

ingress.

[hvh] can you explain why only one RESV message reaches the tunnel
ingress?

Zzh> If you mean “how”
it is done, I thought the following describes it:

… With RMR, this can be optimized such

that only a single LSP is signaled, with all the
leaves listed in the

PATH message.  As
the PATH message passes along the ring, the leaves

send RESV messages, but only one RESV message
reaches the tunnel

ingress.

The ingress LSR may also send PATH messages in
both directions, so

that the tunnel is set up in such a way that
minimum delay is

incurred for traffic to reach all leaves.
Alternatively, the ingress

may send PATH message only in one direction for
best bandwidth

utilization.  For
example, a leaf D is three hops away from the

ingress A in clockwise direction (A,B,C,D) and
four hops away in the

other direction (A,E,F,G,D), but G is also a leaf
so it may be better

to just send the PATH message in the
anticlockwise direction.

Each router establishes forwarding state
accordingly.
Transit

routers switches traffic towards downstream.
A transit router could

also be a leaf router and in that case it does
"drop and continue" -

sends traffic off the ring and switches traffic
downstream.

2.1.
Tunnel Protection and FRR

Each node on a ring signals two counter-rotating
MP2P RSVP-TE LSPs to

itself.  As
these LSPs are self-signaled after the discovery of the

ring, they can be used to protect P2MP LSPs on
ring.
So neither mLDP

nor RSVP-TE has to setup a separate P2P bypass
LSPs for link and node

protection.

[hvh]  This is clear.

I also did not find any indication how this
optimisation has to be

deployed. Do all the nodes in the ring, or in the
network have to

Zzh> The context is
RMR – Resilient MPLS Ring. All routers on the ring need
to support RMR and the multicast optimization for this
to be effective. I can make that clear.

[hvh] OK. Thanks.

I think these issues have to be documented
before this draft can

be adopted as WG draft.

Zzh> Besides
explicitly stating that all routers on the ring need to
support the RSVP-TE P2MP optimization for it to be
effective, please advise further how the first issue can
be better documented.

[hvh] when you use the word "optimize" I expect an indication of

the effect of the optimization on performance, or used resources.

Cheers, Huub.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 9 Apr 2019 13:04:48 +0000

Huub,

Please see zzh2> below.

Juniper Internal
From: Huub van Helvoort <[email-masked]>
Sent: Monday, April 8, 2019 4:08 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

Hello Jeffrey,

Hi Huub,

Non-Juniper
From: Huub van Helvoort <[email-masked]><mailto:[email-masked]>
Sent: Monday, April 8, 2019 5:58 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

All,

[hvh] "lots of state" - can you be more specific? is the redundancy 10% or 90% ?

Zzh2> Depending on how many leaves you have. With traditional RSVP-TE P2MP, there is one sub-LSP to each leaf. If you have 20 leaves, the saving is 95% (I mean you only need to maintain 5% of state compared to traditional way). If you have 10 leaves, the saving is 90%. I don't think the draft needs to quantify it.

   ... As the PATH message passes along the ring, the leaves
   send RESV messages, but only one RESV message reaches the tunnel
   ingress.
[hvh] can you explain why only one RESV message reaches the tunnel ingress?

Zzh2> Because only one PATH message is sent, and the RESV state gets merged accordingly along the way.

Zzh2> I see. The optimization is on (simpler) procedures and (less) resources. I don't think we need to quantify it.
Zzh2> I will update the draft to point out that all routers on the ring needs to support the optimization - please let me know if that is enough.
Zzh2> Thanks!
Zzh2> Jeffrey

Cheers, Huub.

--

---

From: Tarek Saad <[email-masked]>
Date: Wed, 10 Apr 2019 19:23:43 +0000

Hi all,

I’ve been selected as an MPLS-RT reviewer for this draft that is undergoing WG adoption.
Below are my comments.

The document is intended to describe high-level requirements for multicast over RMR rings and document covers specifics that are not dependent on the signaling protocol used to setup the M/P2MP LSP rings.
- I still found, however, instances where it's trying to describe protocol specific signaling details
- IMO, this should be deferred to the other RMR protocol specific documents.
- Ideally, should consider incorporating this document as a section into the main RMR high-level document ID: draft-ietf-mpls-rmr. Was this considered?

>>   This leads to lots of redundant state on routers close to the ingress.
>>   With RMR, this can be optimized such
>>   that only a single LSP is signaled, with all the leaves listed in the PATH message.
[TS]: I think a single sub-LSP state still needs to be maintained, regardless if they are signaled in a single or multiple PATH messages. This is needed so a leaf can grafted or pruned without affecting existing leafs.
Note, RFC4875 already allows for signaling multiple sub-LSP(s) in a single PATH message (see rfc4875 section 5.2.2) - so not clear of the new optimizations mentioned here.

Section 2:
>> ingress A in clockwise direction (A,B,C,D) and four hops away in the....
I could not find the figure that shows those nodes? IMO, this high-level description can refrain from describing signaling protocol specific details.

>>   The PATH message does not need to list all leaves.  As long as a leaf somehow determines that it is a leaf, it can send RESV message when it receives the PATH message.
[TS]: With RSVP-TE, a P2MP node discovers it’s a leaf upon processing the PATH that contains a S2L_SUB_LSP with a matching local address. Since the PATH message is reaching the node, not clear on what is optimization in this case.

>> Once the traffic is out of the ring  LSP on R3,
[TS]: I think clearer as "Once traffic is out of the CW LSP to R3". Also, it is unclear if/how PLR(2) can distinguish whether to tunnel traffic over CW LSP to node R3 or to node R4 - i.e. case of R3 node failure?

>> Section 3: End to End Tunnels with Rings
[TS]: do you mean full mesh of tunnels between PEs? The summary I can draw from this small section is that RMR (as another form of P-tunnels) is not introducing any new requirements, right?

Regards,
Tarek

On 3/28/19, 5:19 AM, "Loa Andersson" <[email-masked]> wrote:

    Tarek, Andy, Huub and Rajiv,
    
    You have be selected as MPLS-RT reviewers for
    draft-zzhang-mpls-rmr-multicast-02.
    
    Note to authors: You have been CC'd on this email so that you can know
    that this review is going on. However, please do not review your own
    document.
    
    Reviews should comment on whether the document is coherent, is it
    useful (ie, is it likely to be actually useful in operational
    networks), and is the document technically sound?  We are interested
    in knowing whether the document is ready to be considered for WG
    adoption (ie, it doesn't have to be perfect at this point, but should be
    a good start).
    
    Reviews should be sent to the document authors, WG co-chairs and
    WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
    may be sent privately to only the WG chairs.
    
    If you have technical comments you should try to be explicit about what
    *really* need to be resolved before adopting it as a working group
    document, and what can wait until the document is a working group
    document and the working group has the revision control.
    
    Are you able to review this draft by April 12, 2019? Please respond in a
    timely fashion.

    Thanks, Loa
    (as MPLS WG chair)
    -- 

    Loa Andersson                        email: [email-masked]
    Senior MPLS Expert
    Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 11 Apr 2019 01:13:07 +0000

Hi Tarek,

Thanks for your review and comments. Please see my responses below.

Juniper Internal

> -----Original Message-----
> From: Tarek Saad <[email-masked]>
> Sent: Wednesday, April 10, 2019 3:24 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> The document is intended to describe high-level requirements for multicast
> over RMR rings and document covers specifics that are not dependent on
> the signaling protocol used to setup the M/P2MP LSP rings.

It does not describe requirements. Rather, it points out that multicast can work as is, or can be optimized.

> - IMO, this should be deferred to the other RMR protocol specific documents.

Second 2 describes at a high level how RSVP-TE P2MP tunnel can be optimized with RMR, but does refer to [I-D.zzhang-teas-rmr-rsvp-p2mp]. I could remove the majority of the text in section and simply point out that it could be optimized.

> - Ideally, should consider incorporating this document as a section into the
> main RMR high-level document ID: draft-ietf-mpls-rmr. Was this considered?

Like in many other cases, a technology may be first specified only for unicast initially and then add multicast. In this case, we don't want to delay the unicast piece.

> [TS]: I think a single sub-LSP state still needs to be maintained, regardless if
> they are signaled in a single or multiple PATH messages. This is needed so a
> leaf can grafted or pruned without affecting existing leafs.

Do you mean a "separate sub-LSP state still need to be maintained for each leaf"?
I don't think that's needed to graft/prune a leaf - just compare to how mLDP works.

> Note, RFC4875 already allows for signaling multiple sub-LSP(s) in a single
> PATH message (see rfc4875 section 5.2.2) - so not clear of the new
> optimizations mentioned here.

The optimization here is that only a single sub-LSP is needed.

> I could not find the figure that shows those nodes? IMO, this high-level
> description can refrain from describing signaling protocol specific details.

I did not include a figure, thinking that the (A,B,C,D) clockwise and (A,E,F,G,D)  anticlockwise text would be clear enough. I can either add a figure or remove most of the text as mentioned earlier.

> 
> >>   The PATH message does not need to list all leaves.  As long as a leaf
> somehow determines that it is a leaf, it can send RESV message when it
> receives the PATH message.
> [TS]: With RSVP-TE, a P2MP node discovers it’s a leaf upon processing the
> PATH that contains a S2L_SUB_LSP with a matching local address. Since the
> PATH message is reaching the node, not clear on what is optimization in this
> case.
> 

Think how mLDP works. Label mapping is sent from a leaf towards the root and a leaf knows it's leaf by other means (not through mLDP mechanisms). Want to apply the same here as an option.

> [TS]: I think clearer as "Once traffic is out of the CW LSP to R3". 

Let me quote the surrounding text here:

   In the event of a link failure between R2 and R3, R2 the Point of
   Local Repair (PLR) tunnels P2MP LSP traffic on a anti-clockwise ring
   LSP to R3 the Merge Point (MP).  Once the traffic is out of the ring
   LSP on R3, it uses the regular P2MP LSP to reach R4.  Similarly in
   the event of a node failure R3, R2 the PLR tunnels P2MP LSP traffic
   to R4 (the MP), which is also the leaf.

The ring LSP to R3 used to tunnel traffic when R2->R3 link breaks is anti-clockwise not clockwise (CW).

> Also, it is
> unclear if/how PLR(2) can distinguish whether to tunnel traffic over CW LSP
> to node R3 or to node R4 - i.e. case of R3 node failure?

A node needs to be able to determine if a failure is a link failure or node failure. Once it knows, it knows how to tunnel.
 
> [TS]: do you mean full mesh of tunnels between PEs? The summary I can
> draw from this small section is that RMR (as another form of P-tunnels) is not
> introducing any new requirements, right?

I meant that an end to end tunnel can go through an arbitrary topology, part of which is a ring or multiple rings.
RMR is not a form of tunnel. It's a special (sub-)topology.
RMR does not introduce any new requirements, though you could optimize RSVP-TE P2MP tunnel over RMR, and optimize tunnel protection for both RSVP-TE and mLDP P2MP tunnels.

Jeffrey

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 11 Apr 2019 12:51:08 +0200

Hello Jeffrey,

Please see [hvh-2] below.

Huub,

Please see zzh2> below.

Juniper Internal

From: Huub van Helvoort
<[email-masked]>

To: Jeffrey (Zhaohui) Zhang
<[email-masked]>; [email-masked]

Subject: Re: MPLS-RT review of
draft-zzhang-mpls-rmr-multicast

Hello Jeffrey,

Hi Huub,

Thank you for your
review and comments. Please see zzh> below.

Non-Juniper

From:
Huub van Helvoort
<[email-masked]>

To: [email-masked]

All,

I’ve been selected as an MPLS-RT
reviewer for draft-zzhang-mpls-rmr-multicast,

I have carefully read the draft but I
could not find any justification

Zzh> By

For a
conventionally signaled RSVP-TE P2MP tunnel, an
ingress LSR

discovers
leaves and signals one sub-LSP for each leaf.
Even though

the forwarding
state is merged at each hop (i.e, one incoming label

mapping to
multiple outgoing entries), the control plane
maintains

individual
sub-LSP state.
This leads to lots of redundant state on

routers close
to the ingress.

[hvh] "lots of state" - can you be more
specific? is the redundancy 10% or 90% ?

Zzh2> Depending on how
many leaves you have. With traditional RSVP-TE P2MP, there
is one sub-LSP to each leaf. If you have 20 leaves, the
saving is 95% (I mean you only need to maintain 5% of
state compared to traditional way). If you have 10 leaves,
the saving is 90%. I don’t think the draft needs to
quantify it.

[hvh-2] the draft should mention it because it may be a reason to
apply the

optimization or not.

[hvh-2] if a leave is deleted, added, or changed all leaves will be
notified and will

have to process the notification.

Zzh> Or do you
mean “why” the optimization COULD be done? The key
is that this is a ring, and:

… As the PATH
message passes along the ring, the leaves

send RESV
messages, but only one RESV message reaches the
tunnel

ingress.

[hvh] can you explain why only one RESV
message reaches the tunnel ingress?

Zzh2> Because only one
PATH message is sent, and the RESV state gets merged
accordingly along the way.

[hvh-2] the merging requires processing resources.

Zzh> If you
mean “how” it is done, I thought the following
describes it:

… With RMR,
this can be optimized such

that only a
single LSP is signaled, with all the leaves listed
in the

PATH message.
As the PATH message passes along the ring,
the leaves

send RESV
messages, but only one RESV message reaches the
tunnel

ingress.

The ingress
LSR may also send PATH messages in both directions,
so

that the
tunnel is set up in such a way that minimum delay is

incurred for
traffic to reach all leaves.
Alternatively, the ingress

may send PATH
message only in one direction for best bandwidth

utilization.
For example, a leaf D is three hops away from
the

ingress A in
clockwise direction (A,B,C,D) and four hops away in
the

other
direction (A,E,F,G,D), but G is also a leaf so it
may be better

to just send
the PATH message in the anticlockwise direction.

Each router
establishes forwarding state accordingly.
Transit

routers
switches traffic towards downstream.
A transit router could

also be a leaf
router and in that case it does "drop and continue"
-

sends traffic
off the ring and switches traffic downstream.

2.1.  Tunnel
Protection and FRR

Each node on a
ring signals two counter-rotating MP2P RSVP-TE LSPs
to

itself.
As these LSPs are self-signaled after the
discovery of the

ring, they can
be used to protect P2MP LSPs on ring.
So neither mLDP

nor RSVP-TE
has to setup a separate P2P bypass LSPs for link and
node

protection.

[hvh]  This is clear.

I also did not find any indication how
this optimisation has to be

support this optimisation before it becomes
effective.

Zzh> The
context is RMR – Resilient MPLS Ring. All routers on
the ring need to support RMR and the multicast
optimization for this to be effective. I can make
that clear.

[hvh] OK. Thanks.

I think these issues have to be
documented before this draft can

be adopted as WG draft.

Zzh> Besides
explicitly stating that all routers on the ring need
to support the RSVP-TE P2MP optimization for it to
be effective, please advise further how the first
issue can be better documented.

[hvh] when you use the word "optimize" I
expect an indication of

the effect of the optimization on performance, or used
resources.

Zzh2> I see. The
optimization is on (simpler) procedures and (less)
resources. I don’t think we need to quantify it.

[hvh-2] I would like to know why I should deploy this
"optimisation",

and maybe others would like to know too.

Zzh2> I will update the
draft to point out that all routers on the ring needs to
support the optimization – please let me know if that is
enough.

Zzh2> Thanks!

Zzh2> Jeffrey

Best regards, Huub.

---

From: Tarek Saad <[email-masked]>
Date: Thu, 11 Apr 2019 19:59:48 +0000

Hey Jeffrey,

See inline..

On 4/10/19, 9:13 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

    Hi Tarek,

    

    Second 2 describes at a high level how RSVP-TE P2MP tunnel can be optimized with RMR, but does refer to [I-D.zzhang-teas-rmr-rsvp-p2mp]. I could remove the majority of the text in section and simply point out that it could be optimized.
[TS]: OK, but would think you want to define those in the other draft.. otherwise, it's hard to keep the content in sync in 2 separate documents.

    Like in many other cases, a technology may be first specified only for unicast initially and then add multicast. In this case, we don't want to delay the unicast piece.
[TS]: OK, but given not introducing any new reqts and that signaling optimizations (if any) are deferred to other documents, still concerned? I'll leave it up to you/WG.

[TS]: classic P2MP RSVP-TE LSPs are ingress driven.. the provisioning/graft/prune is driven by the ingress LER (possibly triggered by overlay auto-discovery route learnt at ingress). I am not clear, in the case, how ingress can trigger the graft/prune operation on a single sub-LSP without impacting the others.

    The optimization here is that only a single sub-LSP is needed.
[TS]: still little confused. An S2L_SUB_LSP object identifies a particular S2L sub-LSP.  The  S2L_SUB_LSP object has a single destination address (the leaf).. Are you proposing configuring anycast address (per p2mp-te tree) in S2L_SUB_LSP to identify all the nodes of a ring? Please clarify.

    I did not include a figure, thinking that the (A,B,C,D) clockwise and (A,E,F,G,D)  anticlockwise text would be clear enough. I can either add a figure or remove most of the text as mentioned earlier.
[TS]: still helpful to be there.

    Think how mLDP works. Label mapping is sent from a leaf towards the root and a leaf knows it's leaf by other means (not through mLDP mechanisms). Want to apply the same here as an option.
[TS]: Yes, but one key difference between mLDP and RSVP-TE is that the latter is ingress driven while the former is prefix (e.g S,G) driven.. For classic P2MP RSVP-TE, the graft/prune is controlled by ingress. If you're planning to change this, I think it would be worth more highlighting/clarifying.

    
    
    The ring LSP to R3 used to tunnel traffic when R2->R3 link breaks is anti-clockwise not clockwise (CW).
[TS]: My bad, I read "CW" as counter clock-wise __ -- while you probably refer to it as AC (anti-clockwise). In either case, it's good to refer to it explicitly as the AC LSP to R3.

    A node needs to be able to determine if a failure is a link failure or node failure. Once it knows, it knows how to tunnel.
[TS]: yes, can imagine it's not quite straight forward to do so..

    I meant that an end to end tunnel can go through an arbitrary topology, part of which is a ring or multiple rings.
    RMR is not a form of tunnel. It's a special (sub-)topology.
    RMR does not introduce any new requirements, though you could optimize RSVP-TE P2MP tunnel over RMR, and optimize tunnel protection for both RSVP-TE and mLDP P2MP tunnels.
[TS]: good to know. I still believe if you're going to talk about (e.g.) RSVP-TE optimizartions, you're better off doing so in the RSVP-TE RMR draft. I'd expect RMR topology considerations on to P2MP or MP2MP LSP(s) to be discussed here.

Regards,
Tarek
    
    Jeffrey