Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast
Huub van Helvoort <huubatwork@gmail.com> Mon, 08 April 2019 20:07 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 C3AEA120486; Mon, 8 Apr 2019 13:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.016
X-Spam-Level:
X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_DISPTO=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 eAQS35f11w_M; Mon, 8 Apr 2019 13:07:51 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 EE11412048B; Mon, 8 Apr 2019 13:07:50 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id f19so5826151edw.12; Mon, 08 Apr 2019 13:07:50 -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=P9VtCHyYHwOhgzgOej56sHIjP5q6Mol/5ryFJ/bDWe8=; b=Ad/eVTc3mSFp8T/ew5/KDyNAqp83RHhgLBsHtSCZYFLxqh+kUfKcaINb9HD6LgnQks 6gNcNVn0r5iruqgMyn99bNmbNmcUpJrMrhNZHSGNPnSYMAqBwkWSreokRDpdKGPkGiim fxte0eIagQO8cx4aXVyzfJuLHRzyq3YsRn/nJltpyZdeaEhZvv0JOCqAUnBmLn3G+Xls SPosswlbecDtJ9+5H0C9SLvEFustskygLkyPMPNMkrZ6J0W4YFW0JRoisgUl/Sm++7fg oSL/FWH/DXDkxYqDPS2RpMokUcKEQ++cD978aMFHqcdcHO65nRRuBPh8EUndQUldVHO/ 2SNQ==
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=P9VtCHyYHwOhgzgOej56sHIjP5q6Mol/5ryFJ/bDWe8=; b=Jjal2MlO8Nm4/ePaaI70aJp4kUjIlFbKeuzCRLmnF47pcQhUOtlpCwF11hXmuva3JH 6mtq/slATOEZLuJEe4wHLfW1vI4t5hMDFQUJfUGOTozVoMIrddeCjsCGdZeufgp7pqZm 8t/Fwh5Isfy5ugxPDbwNlronGScuxIqXx4kIe/FwjjoMOzHZASeNfR3yuX+iOHzJMicc ZuBnfsreiDCxEzSac+jNgR906SSN69wkcFQDwv5mN2xJlOJfmO75GLLbPPsQTSyOaRb1 1c8O1ApUZl0PClZom+ZG7PV//kDlaEYM4vf99EEjSXbyir3nKKiJBgBlFTgOeRhrnL5h COlQ==
X-Gm-Message-State: APjAAAVnjPlELW7qsPPjaMKPc+u7RGcTE4au1YWNQ0Kn2Ric8nzBZnI6 s72EF1UWVO/IXIuUWf2Vzo/oj80H
X-Google-Smtp-Source: APXvYqziE+EOeD+XxRwQls0XLwhoIdc3qpj7xkKbQm1/3cDwYNKjO8e3jITuHzZPeMqjZkKtX/85TA==
X-Received: by 2002:a17:906:660f:: with SMTP id b15mr9775934ejp.13.1554754069139; Mon, 08 Apr 2019 13:07:49 -0700 (PDT)
Received: from McAsterix.local ([2a02:a211:8e81:2e00:b86e:29cf:5825:47f5]) by smtp.gmail.com with ESMTPSA id l44sm9148101edb.37.2019.04.08.13.07.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 13:07:48 -0700 (PDT)
Reply-To: huubatwork@gmail.com
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
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>
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <beaab152-6a9f-9e0a-8cc8-6c6c6cee5584@gmail.com>
Date: Mon, 08 Apr 2019 22:07:47 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CO2PR05MB2455B56BCF23C0059D4EB90DD42C0@CO2PR05MB2455.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/zTPJroetp9bPU5vi3jhkHF5szn4>
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: Mon, 08 Apr 2019 20:07:53 -0000
[hvh] "lots of state" - can you be more specific? is the redundancy 10% or 90% ?Hi Huub,
Thank you for your review and comments. Please see zzh> below.
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] can you explain why only one RESV message reaches the tunnel 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.
[hvh] This is clear.
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] OK. Thanks.
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] when you use the word "optimize" I expect an indication of
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.
the effect of the optimization on performance, or used resources.
Cheers, Huub.
-- ================================================================ Always remember that you are unique...just like everyone else...
- [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-mu… Huub van Helvoort
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Jeffrey (Zhaohui) Zhang
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Huub van Helvoort
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Jeffrey (Zhaohui) Zhang
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Tarek Saad
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Jeffrey (Zhaohui) Zhang
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Huub van Helvoort
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Tarek Saad
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Jeffrey (Zhaohui) Zhang
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Tarek Saad
- Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rm… Huub van Helvoort