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

"Jeffrey (Zhaohui) Zhang" <> Mon, 08 April 2019 10:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20A8E1201C1; Mon, 8 Apr 2019 03:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.328
X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c3QUHyW7YP6K; Mon, 8 Apr 2019 03:42:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F00D9120058; Mon, 8 Apr 2019 03:42:49 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x38ATNHw001690; Mon, 8 Apr 2019 03:42:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=umAGzhQggPTs+SwaifwGvgRLC2Vi6kC7XSuOqCi1kh4=; b=IahEplIXV6Cg47YK6ablUyfzSlLRgXpplE5rnv5zsz7hgSsgswoRVSMgcPlXa3XdB8B1 FQMVbRhCBaRF7ouLG3ymJNTbJ9szy99e7ja3phjdBaf9+0xmQbp+Bgvnlk9v5E/ZgF4v MG26qPT0hnX2g9+whtejoFXP0LLPG7kpb2dvRyY0QJ0ElSemdPimfpHLiuebMqH+YjD5 tDub+WP4Cbb2gGKKTkzGR3+DB+zsnS/UaB4ADkJ/p92V3QDJ9S+dN1DLqZD+sqIFgpRJ aO7D3nGf+1U9dbB9LHjMDBX0Pp0fHKkFQWBsi42ONlLZHIXYj4vRoLO5SKBK132oBSvE /g==
Received: from ( []) by with ESMTP id 2rr2qhg623-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Apr 2019 03:42:46 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Mon, 8 Apr 2019 10:42:44 +0000
Received: from ([fe80::81e2:bbe8:6851:16b2]) by ([fe80::81e2:bbe8:6851:16b2%6]) with mapi id 15.20.1792.007; Mon, 8 Apr 2019 10:42:44 +0000
From: "Jeffrey (Zhaohui) Zhang" <>
To: "" <>, "" <>
CC: "" <>, "" <>
Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast
Thread-Index: AQHU5UdoXX/k5SRry0WfLJCBg3kMV6YyGKsAgAAHF+A=
Date: Mon, 08 Apr 2019 10:42:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-reaction: no-action
msip_labels: MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Enabled=True; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_SetDate=2019-04-08T10:39:01.9086694Z; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Name=Non-Juniper; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Application=Microsoft Azure Information Protection; MSIP_Label_106ee314-308e-4f40-a474-5b984ee7b7ff_Extended_MSFT_Method=Manual; Sensitivity=Non-Juniper
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3061e5a1-dbce-431c-159a-08d6bc0eef1b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CO2PR05MB2727;
x-ms-traffictypediagnostic: CO2PR05MB2727:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(366004)(376002)(346002)(31014005)(189003)(37854004)(199004)(8936002)(81156014)(102836004)(446003)(6116002)(6246003)(790700001)(316002)(105586002)(53936002)(476003)(229853002)(7696005)(3846002)(106356001)(81166006)(6506007)(4326008)(11346002)(97736004)(2906002)(8676002)(33656002)(53546011)(9326002)(76176011)(68736007)(486006)(26005)(186003)(74316002)(478600001)(2501003)(7736002)(55016002)(71190400001)(71200400001)(14454004)(66066001)(5660300002)(6436002)(52536014)(86362001)(66574012)(6306002)(25786009)(54906003)(9686003)(256004)(14444005)(99286004)(110136005)(53946003)(54896002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2727;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3kd93FmdXRsTjI+uTcwoTHfeNhCTMe2V+FkKC6zPDt1nXEvSaFcJNZT+3b0egInOJ9qVyrgoUYnjzEly56hQNBYx7SIdvhXeOkRJavgN3ky8fRB2V7tVhvFVrA651BpLUT/esOCgfGt/HsIb9iL3BzxcKipTRz3gQbg63whzrumI1rF0CjATuUanYLIZ95k/eV+kNArdMjW8wqv4LZ/6XdAaFvHRzFL66axAOg90VFN1iYkwLFw91eNsiWauIJzmtTX7dEPy3XB1k9IBWuyWGKRJ7eM91FiYA/lb4wyeU0RCuPOpG/PUvbMpsDEWKQwHtCRpe0KZEwXseZ1WI+fnBnaddC37wKUlD0vGu1cghoU3PIIN1OZrGorbWdZAllPKW0u0w+Tho9X7KTlNirMmTdz1OzjdM3JWh3wPRrHbppM=
Content-Type: multipart/alternative; boundary="_000_CO2PR05MB2455B56BCF23C0059D4EB90DD42C0CO2PR05MB2455namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3061e5a1-dbce-431c-159a-08d6bc0eef1b
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 10:42:44.5466 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2727
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080095
Archived-At: <>
Subject: Re: [mpls] MPLS-RT review of draft-zzhang-mpls-rmr-multicast
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Apr 2019 10:42:52 -0000

Hi Huub,

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

From: Huub van Helvoort <>
Sent: Monday, April 8, 2019 5:58 AM
Subject: MPLS-RT review of draft-zzhang-mpls-rmr-multicast


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.

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

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

   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

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.

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.


Best regards, Huub.



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