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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 7 May 2019 18:51:06 +0000

Hi Huub, Tarek,

Based on your comments, I removed the text about RSVP-TE P2MP tunnel optimization and simply refer to the other document. Hope this will address your concerns.

https://datatracker.ietf.org/doc/draft-zzhang-mpls-rmr-multicast/

Thanks!
Jeffrey

Juniper Internal
From: Huub van Helvoort <[email-masked]>
Sent: Thursday, April 11, 2019 6:51 AM
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,

Please see [hvh-2] below.

Huub,

Please see zzh2> below.

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

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]><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,

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.

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.
[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
deployed. Do all the nodes in the ring, or in the network have to
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.

--

================================================================

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

---

From: Tarek Saad <[email-masked]>
Date: Mon, 13 May 2019 14:41:49 +0000

Thanks Jeffrey for making the changes which address my previous comments.

Regards,
Tarek

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tuesday, May 7, 2019 at 2:51 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Tarek Saad <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: MPLS-RT review of draft-zzhang-mpls-rmr-multicast

Hi Huub, Tarek,

Thanks!
Jeffrey

Juniper Internal

Hello Jeffrey,

Huub,

Please see zzh2> below.

Juniper Internal

Hello Jeffrey,

Hi Huub,

Non-Juniper

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.

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

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.

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

 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.

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.

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: Huub van Helvoort <[email-masked]>
Date: Sun, 26 May 2019 11:04:45 +0200

Please excuse me for the delay.

After re-reviewing the draft I think it
is ready for WG adaption.

Best regards, Huub.

======

On 07/05/2019 20:51, Jeffrey (Zhaohui)
Zhang wrote:

Hi Huub, Tarek,

Based on your comments, I
removed the text about RSVP-TE P2MP tunnel optimization and
simply refer to the other document. Hope this will address
your concerns.

Thanks!

Jeffrey

Juniper Internal

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

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,

Huub,

Please see zzh2>
below.

Juniper
Internal

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

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,

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,

which is currently a candidate for MPLS WG
adoption.

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

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

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

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

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

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.

--