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

Huub van Helvoort <huubatwork@gmail.com> Sun, 26 May 2019 09:04 UTC

Return-Path: <huubatwork@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425E712014F; Sun, 26 May 2019 02:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.255
X-Spam-Level:
X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FREEMAIL_DISPTO=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYTknLVqkdPU; Sun, 26 May 2019 02:04:51 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5494512011D; Sun, 26 May 2019 02:04:49 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id p27so21660686eda.1; Sun, 26 May 2019 02:04:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZUe001h6NF5qp90C+s1htMV0zqRCfg96UxrgDIpkYOY=; b=McaBhjSZVmRHACTvkEOjpas0WXPF5EZW59cuR+DPuzb3Uy2XPI81K50GzbXOyepcth pxwCVgyVtJgjRufviiE/+Vi5YG2pkjOEfctqb77dfkraeN60kCPlzsUKrnwL5p2IrOIE H7LucJ7hzKL3Kur4J9HvqdiTO59C6GmLkUOFJ3L2cIwV+c5DHaRxwRmR0wYjPHSqt+0D vSIC1p72E33OjnKNeSA2JWHp9ATpnrjp4CbdoN3ZHgocpy5JJFVYy6BaXToppM2CdcCv JR0V/AJK2CTNyQ+nw8X/J7PRp1TjsngFPxC4EttX94Eo7ecz6r0RW6Kg6lJQrEQXi5ff q5Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZUe001h6NF5qp90C+s1htMV0zqRCfg96UxrgDIpkYOY=; b=CfgT7ZA/d1PKCH7MqiYlxH+LnZeqhzLqswUwC1SVZrVuqVbKKMAfAwwIxbWvgen3wc FDNLov31aUylMCB6d+tuzbWEaQ23nu9wHqBtg/4vOxUnDkX2/oNvwwdRPyQcXAgL+baM SazWeCXH+yuJMrzuzFm+ln+37ddlUaBHlOBEgTk3mNzvdSQd8LjAzTEqGMrAEHkzf3B6 PW4YvTynpSA0UZYfL7ypVNw+hSfJYvg6JPewmbS5Zak446tt0J3iFmI607FM8NS1EG6x 0OuraN0vMqB0dc6CH+sbayxgEbp55Qu1RElew50bBFh0ugiwhmZGd9M2hExECidqsc4z Dn6g==
X-Gm-Message-State: APjAAAUu9mHiDVnUwFR2YhRzolXWugSCg4PL4c8p0eoKblI4jmQf7iPa KBTuXdlAsNK5TBFOYuOj+hD/MCwk
X-Google-Smtp-Source: APXvYqz9k+6q9Jb5SuAK2r7cS+DZqlXhnnG29V6XwdykMoLzwRSKEbuuk6qT4gf17lrEQp4XjL7/Eg==
X-Received: by 2002:a17:906:9145:: with SMTP id y5mr47572585ejw.206.1558861487599; Sun, 26 May 2019 02:04:47 -0700 (PDT)
Received: from McAsterix.local ([2a02:a211:8e81:2e00:5c7f:ccb8:9e75:2d7e]) by smtp.gmail.com with ESMTPSA id x22sm2248469edd.59.2019.05.26.02.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 May 2019 02:04:46 -0700 (PDT)
Reply-To: huubatwork@gmail.com
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>, Tarek Saad <tsaad.net@gmail.com>
Cc: "draft-zzhang-mpls-rmr-multicast@ietf.org" <draft-zzhang-mpls-rmr-multicast@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> <be4eb733-b0a2-68d6-0442-94c5129da516@gmail.com> <CO2PR05MB2455B56BCF23C0059D4EB90DD42C0@CO2PR05MB2455.namprd05.prod.outlook.com> <beaab152-6a9f-9e0a-8cc8-6c6c6cee5584@gmail.com> <CO2PR05MB24554DED1C246AA9227C1015D42D0@CO2PR05MB2455.namprd05.prod.outlook.com> <d24bb64f-18f5-73e2-f891-46d1a86dfe49@gmail.com> <DM5PR05MB3548CE8FF009A6936E4C5535D4310@DM5PR05MB3548.namprd05.prod.outlook.com>
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <d284b7d9-c68a-a978-bec6-d778ab37a4a2@gmail.com>
Date: Sun, 26 May 2019 11:04:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <DM5PR05MB3548CE8FF009A6936E4C5535D4310@DM5PR05MB3548.namprd05.prod.outlook.com>
Content-Type: text/html; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Mz5rkYg5-dBnJdit7sTC2rmuKhw>
Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 May 2019 09:04:53 -0000

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.

 

https://datatracker.ietf.org/doc/draft-zzhang-mpls-rmr-multicast/" rel="nofollow">https://datatracker.ietf.org/doc/draft-zzhang-mpls-rmr-multicast/

 

Thanks!

Jeffrey

 

 

Juniper Internal

From: Huub van Helvoort <huubatwork@gmail.com>;
Sent: Thursday, April 11, 2019 6:51 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>;; mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
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 <huubatwork@gmail.com>;
Sent: Monday, April 8, 2019 4:08 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>;; mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
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 <huubatwork@gmail.com>;
Sent: Monday, April 8, 2019 5:58 AM
To: mpls@ietf.org
Cc: draft-zzhang-mpls-rmr-multicast@ietf.org; mpls-chairs@ietf.org
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...


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