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

Tarek Saad <tsaad.net@gmail.com> Wed, 10 April 2019 19:23 UTC

Return-Path: <tsaad.net@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 157361201CB; Wed, 10 Apr 2019 12:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DzRyaTeB5MWK; Wed, 10 Apr 2019 12:23:46 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 F0CD6120103; Wed, 10 Apr 2019 12:23:45 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id y5so1946889qkc.11; Wed, 10 Apr 2019 12:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=ngCrT48X3AvCw0xtZ0qbSZ3vbfSmI1ZzQ4OoIS0oYoE=; b=hM51UTkwts9YIaZSYBLmxzmxutJyArUkijejmBCEugitnQ1njRy3xATDMjfqMtmAoV /r3x72tRjC+cApHKT6h3ndoOPEBVOdKNwI2KNLpJ7OrOdyGdsytg6o9vFBlHHwYMfadg a8hnfF2PXtSNZNKTcK8vZvymWuXS6LxO0ftNR6KDhiuXv9UEWHE9N4RlQ5KmPva899TV laho5t/xcapEeUoDIWyW82aSelRTrfU5wjyMFTY63JMWWOAl4hQE9nWkLkyNGzguOeG+ OJA2DyA1h9bOEWPf1nds0VbGQADZLrAtQvYsnNkTSOzoShq2DI1ZcIk6wKojoOOzpJYO +z3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=ngCrT48X3AvCw0xtZ0qbSZ3vbfSmI1ZzQ4OoIS0oYoE=; b=gd2aKlCtsFamHRh6GvVJLxFtP54gqCZlG+2iHRfhjjd8XCzYUhQdGLKRwrTOCi3znW tj2q2r+HQBTbphVjRcbT2JIRyYTF62oOyXcIKpa2btiuVqHHtbSFn1uiE8DE6chruWD9 XSHg8HAsC5BkSfoWdY7TQSSi/EUx76G3dJIvh5u8pgt6fK4eTG9A6Z5rh3kaRzszl58a iMv1YB7nUqyKKcMEqV5S5d9LDi8niu08sHy2SCxQXvfh4+L1HphFMEj55GEWKi0eF/06 WAYkQpeZdRslEMEq0zfNduBVPfvZN7ToUb/GgeJfFRsqWd0ykH45Xz8e+XsCxkZ+oha9 yxWQ==
X-Gm-Message-State: APjAAAUQMOuLDGMgCLo26k4jrZ/6emfmnP1G//7UjEGngWoPC1+jobPn +gKXyn+wYi5cDcFoNDuCU6Aa9HSN
X-Google-Smtp-Source: APXvYqx8FivCWRMrSxTktDVWisu8LRb+wi8cV1vE8bPprhehhsdQtbADW0dgKQm5QqunJupPofI5Og==
X-Received: by 2002:ae9:e012:: with SMTP id m18mr1973251qkk.267.1554924224827; Wed, 10 Apr 2019 12:23:44 -0700 (PDT)
Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id t30sm6952836qkm.25.2019.04.10.12.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 12:23:44 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "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: ATVjYWU3vXyEqIW2kXE8E4lNxAjcHb8Y4wda
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 10 Apr 2019 19:23:43 +0000
Message-ID: <BN8PR06MB6289476C688CFDA26F5FF7BEFC2E0@BN8PR06MB6289.namprd06.prod.outlook.com>
References: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu>
In-Reply-To: <0df832d7-8389-e9dd-95aa-46d8c8d06da5@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/p03Q0aXkkVzRERGkpqFo4jiBt3E>
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: Wed, 10 Apr 2019 19:23:48 -0000

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.
- 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.
- Ideally, should consider incorporating this document as a section into the main RMR high-level document ID: draft-ietf-mpls-rmr. Was this considered?

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

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.

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

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

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

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