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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 11 April 2019 01:13 UTC

Return-Path: <zzhang@juniper.net>
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 63D6312046B; Wed, 10 Apr 2019 18:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Level:
X-Spam-Status: No, score=-1.338 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 ZXSLpTYNhyqF; Wed, 10 Apr 2019 18:13:15 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAE012068C; Wed, 10 Apr 2019 18:13:15 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3B19wdl002587; Wed, 10 Apr 2019 18:13:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=EE0CDNWx/ExMtyxjmT/6805UjwsD5ZnTwiJHHokS+zw=; b=W3wdDvGAn7SdMAwU3Dyv4MHOtdqJtU+v9MdI0q7xOgD18ePDK7vtXJEs1zezkUq6rtTp +oZy9qxZG/b9t11PiuBj1uB75UMKocttLshsTRvEjCk/bkLQ7Mnd4KiYKz/EIi6BNz5q bAyrKUWfyNZmPHnroYQ5wMfHkFnRrJeYGaZdqDoxJ2HUo0NTFkpT2ATDDKMVhxIeGKcq lVmzrWUOVVnqoUpchWcv7aSHL+hVfyTYywUqbnxdbO6sxamUjTGrCFHHiRcbLLkRbKhd ASxBzCB8u9JpZg36bjkMQN8fITPUqELgIbR9jIzgG8asBqvVNOrO7buLMRD5+6dJHgHr IA==
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2053.outbound.protection.outlook.com [104.47.45.53]) by mx0b-00273201.pphosted.com with ESMTP id 2rsssb04yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 18:13:11 -0700
Received: from CO2PR05MB2455.namprd05.prod.outlook.com (10.166.95.137) by CO2PR05MB2662.namprd05.prod.outlook.com (10.166.95.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Thu, 11 Apr 2019 01:13:08 +0000
Received: from CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2]) by CO2PR05MB2455.namprd05.prod.outlook.com ([fe80::81e2:bbe8:6851:16b2%6]) with mapi id 15.20.1792.007; Thu, 11 Apr 2019 01:13:07 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Tarek Saad <tsaad.net@gmail.com>, "draft-zzhang-mpls-rmr-multicast@ietf.org" <draft-zzhang-mpls-rmr-multicast@ietf.org>
CC: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS-RT review of draft-zzhang-mpls-rmr-multicast
Thread-Index: AQHU5UdoXX/k5SRry0WfLJCBg3kMV6Y120KAgABZTKA=
Content-Class:
Date: Thu, 11 Apr 2019 01:13:07 +0000
Message-ID: <CO2PR05MB24552540455EBB21243F1DE6D42F0@CO2PR05MB2455.namprd05.prod.outlook.com>
References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu> <BN8PR06MB6289476C688CFDA26F5FF7BEFC2E0@BN8PR06MB6289.namprd06.prod.outlook.com>
In-Reply-To: <BN8PR06MB6289476C688CFDA26F5FF7BEFC2E0@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.1.100.23
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=zzhang@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-04-11T01:13:04.0296200Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Internal; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic; Sensitivity=Juniper Internal
x-originating-ip: [117.38.13.71]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c2cb894b-8306-446a-b6d2-08d6be1adb76
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:CO2PR05MB2662;
x-ms-traffictypediagnostic: CO2PR05MB2662:
x-microsoft-antispam-prvs: <CO2PR05MB26624824ED4D7035754F8146D42F0@CO2PR05MB2662.namprd05.prod.outlook.com>
x-forefront-prvs: 00046D390F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(376002)(366004)(396003)(199004)(37854004)(189003)(53754006)(13464003)(2906002)(476003)(6246003)(53936002)(5660300002)(54906003)(53546011)(33656002)(14444005)(256004)(99286004)(7696005)(102836004)(110136005)(6506007)(86362001)(55016002)(9686003)(478600001)(76176011)(6116002)(3846002)(68736007)(14454004)(6436002)(97736004)(106356001)(105586002)(25786009)(7736002)(186003)(4326008)(305945005)(74316002)(2501003)(316002)(11346002)(8676002)(446003)(66066001)(26005)(8936002)(71200400001)(52536014)(81156014)(81166006)(486006)(229853002)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2662; H:CO2PR05MB2455.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: dZDP8cPsWPFVCcohtj/eqehpcEyelQVsuefGLIvgrqhFD3aM2QQUK9McJTGijdU1Cviqs7DgyXFGsmUdDHZXFTl5QzKG0m9CbJxYvdL7F+Fvd7eXRQBLMGddubjW4yEX6W7NAGjVm1OI5uF9CpcaM6a+cCGOtjGnY7Ila9u7LturTGI1DKHyVfXRNlpnk15bpGN0D67OQuYIb2hs+6Egn1y4sRYaZ+dFYm4GLQkn2Or7qLwrugRiZEzPU6cTHzEzdsOjZu0IIP8n6ka1AOZrUPDvmTZoF6qBzW/868RibEFm18y9Ehe6mE/sAGM9zgUm3orsfyW6me+6IzKyiTbu0/SUicRN3rywvyGNfRaHVbjRfQO/Htl/DX01ZZ/44/B0JbcDMx1llrHMBU5vrcOYGso7zNd+yYiAYlgwDh8A+AM=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: c2cb894b-8306-446a-b6d2-08d6be1adb76
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 01:13:07.8800 (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: CO2PR05MB2662
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_01:, , 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-1904110006
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/TxZd0QpALijKpGpQydVE8CcxuXc>
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: Thu, 11 Apr 2019 01:13:18 -0000

Hi Tarek,

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


Juniper Internal

> -----Original Message-----
> From: Tarek Saad <tsaad.net@gmail.com>;
> Sent: Wednesday, April 10, 2019 3:24 PM
> To: draft-zzhang-mpls-rmr-multicast@ietf.org
> Cc: mpls-chairs@ietf.org; mpls@ietf.org
> Subject: Re: MPLS-RT review of draft-zzhang-mpls-rmr-multicast
> 
> 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.

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

> - 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.

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.

> 
> >>   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.

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.

> 
> 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.

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.

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

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.
 
> >> 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?

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
> 
> Regards,
> Tarek
> 
> 
> On 3/28/19, 5:19 AM, "Loa Andersson" <loa@pi.nu>; 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: loa@pi.nu
>     Senior MPLS Expert
>     Bronze Dragon Consulting             phone: +46 739 81 21 64
>