[spring] Comments on draft-voyer-spring-sr-p2mp-policy-03

Xiejingrong <xiejingrong@huawei.com> Tue, 09 July 2019 09:09 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0F1203C7 for <spring@ietfa.amsl.com>; Tue, 9 Jul 2019 02:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 bZy71vqnh79V for <spring@ietfa.amsl.com>; Tue, 9 Jul 2019 02:09:03 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C3C321203BB for <spring@ietf.org>; Tue, 9 Jul 2019 02:09:02 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4F092BFA8CC4378C7B11 for <spring@ietf.org>; Tue, 9 Jul 2019 10:09:00 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 9 Jul 2019 10:08:59 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Tue, 9 Jul 2019 17:08:47 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Comments on draft-voyer-spring-sr-p2mp-policy-03
Thread-Index: AdU2LwF7Q7JE5HByT0K+NXwhnsJRlg==
Date: Tue, 09 Jul 2019 09:08:47 +0000
Message-ID: <16253F7987E4F346823E305D08F9115AAB8DC4C0@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB8DC4C0nkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/xNKwqenhU6r45tEMXBbGQHSDJiA>
Subject: [spring] Comments on draft-voyer-spring-sr-p2mp-policy-03
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 09:09:06 -0000

Hi,
I have a few comments on draft-voyer-spring-sr-p2mp-policy-03:

   A Point-to-Multipoint service delivery could be via Ingress
   Replication (aka Spray in some SR context), i.e., the root unicasts
   individual copies of traffic to each leaf.  The corresponding P2MP
   segment consists of replication segments only for the root and the
   leaves.

   A Point-to-Multipoint service delivery could also be via Downstream
   Replication (aka TreeSID in some SR context), i.e., the root and some
   downstream replication nodes replicate the traffic along the way as
   it traverses closer to the leaves.

   Notice that Spray is actually a special form of TreeSID.  Also notice
   that, the explicit path from the root or a replication node to a leaf
   or a downstream replication node can optionally be partially or
   completely specified by the controller or determined locally.
[XJR] There have been clear concepts of Ingress-Replication and P2MP already in the decades of multicast technology. Is Spray/TreeSID more clear than them?

2.  SR Replication Policy

   An SR Replication policy is a variant of an SR policy [I-D.ietf-
   spring-segment-routing-policy].  A replication policy corresponds to
   a replication segment, which defines the forwarding behavior on a
   particular node on a particular P2MP segment.
   An SR Replication Policy can be either provisioned locally or
   programmed by a controller.
   An SR Replication Policy is identified through the tuple <Node-ID,
   Root, Tree-ID>.
[XJR] I don't see where the key of a SR-policy IMO, the color is. Is it still a variant of SR-policy ?

   An SR P2MP policy can be either provisioned locally or programmed by
   a controller onto the root node of the segment, for the purpose of
   steering traffic into the segment.  A controller calculates the tree
   and program corresponding replication segments on root, leaves and
   optional replication nodes.
[XJR] There is already overmuch of P2MP-building protocols like PIM, mLDP, RSVP-TE. What's the meaning of inventing a new one?

   Traffic is steered into a SR P2MP Policy in two ways:

   o  Based on a local policy-based routing at the Root node.

   o  Based on remote classification and steering via the BSID of the SR
      P2MP Policy at the Root node.

   Traffic is then forwarded toward the leaves following the replication
   segments.
[XJR] How is the forwarding procedure? For a packet P1, one replicate to A using IPv6/SRv6/SRH encapsulation, and replicate to B using another IPv6/SRv6/SRH encapsulation ? How about the cost ? Will that be done in hardware or software ?

4.  Using Controller to build a P2MP Segment

   A P2MP segment can be built using a Path Computation Element (PCE)
   and PCE Protocol (PCEP).  This section outlines a high-level
   architecture for such an approach.

4.1.  SR P2MP Policy Creation

   A SR P2MP policy can be instantiated and maintained in a centralized
   fashion using a Path Computation Element (PCE).
[XJR] Is this relevant to SR-Policy ? things using PCE with some SID-List configuration is not SR-policy variant IMO.

4.1.1.  API
   North-bound APIs on a PCE can be used to:
   1.  Create P2MP SR policy
   2.  Delete P2MP SR policy
   3.  Update P2MP SR policy
[XJR] SR-Policy has named North-bound APIs? I did not found one in draft-ietf-idr-segment-routing-te-policy.

4.4.  Protection
4.4.1.  Local Protection
   A network link/node on the tree of a P2MP segment can be protected
   using SR policies computed by PCE.  The backup SR policies shall be
   programmed in forwarding plane in order to minimize traffic loss when
   the protected link/node fails.
[XJR] When does such protection take effect? When a link fail or before a link fail? How if some link or device is added ? re-optimization & MBB ?

4.4.2.  Path Protection
   It is possible for PCE create a disjoint backup tree for providing
   end-to-end path protection.
[XJR] Suppose A---C/D/E, use the P2MP mentioned above, how does one provide end-to-end path protection? Using what OAM method to detect failure?


[XJR] Maybe the first question is, P2MP seems not a work in SPRING. Is it? There are WGs PIM/MBONED/BIER specialized on all kinds of multicast.


Thanks
Jingrong