Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT)

Dhruv Dhody <dhruv.dhody@huawei.com> Fri, 12 April 2019 06:06 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17C120043; Thu, 11 Apr 2019 23:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 co3wcdCXyNc0; Thu, 11 Apr 2019 23:06:21 -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 31DA012002E; Thu, 11 Apr 2019 23:06:21 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 10D4F5056623F1B46769; Fri, 12 Apr 2019 07:06:19 +0100 (IST)
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Apr 2019 07:06:18 +0100
Received: from BLREML503-MBS.china.huawei.com ([169.254.12.125]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Fri, 12 Apr 2019 11:36:11 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-pce-stateful-pce-p2mp@ietf.org" <draft-ietf-pce-stateful-pce-p2mp@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Thread-Topic: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT)
Thread-Index: AQHU7z+M60F99Nqc4U2m/TB9hOh6m6Y03ROwgAIn4wCAAQJ4cA==
Date: Fri, 12 Apr 2019 06:06:11 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8DA11BB0@BLREML503-MBS.china.huawei.com>
References: <155486089608.19649.9617345506233285248.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8DA0F235@BLREML503-MBS.china.huawei.com> <20190411195036.GU18549@kduck.mit.edu>
In-Reply-To: <20190411195036.GU18549@kduck.mit.edu>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/6CmWgogUtVMdYl1G0mCggoDZv6A>
Subject: Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-stateful-pce-p2mp-12: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 06:06:23 -0000

Hi Ben, 

I think we have converged and I have posted a new version -13. 

> > Section 6.1
> > >    When reporting the status of a P2MP TE LSP, the destinations MUST
> be
> > >    grouped in END-POINTS object based on the operational status (O
> field
> > >    in S2LS object) and leaf type (in END-POINTS).  This way, leaves of
> > >    the same type that share the same operational status are grouped
> > >    together.  [...]
> > >
> > > Does this mean that it's an error for a PCRpt message to include
> > > more than one END-POINTS object with a given value of leaf-type?  If
> > > so, it may be worth stating that explicitly.
> >
> > [[Dhruv Dhody]] No, one can have more than one END-POINTS object with
> the same leaf-type. There is no such restriction.
> 
> Maybe I am misunderstanding something, but the "are grouped together"
> implied to me that it was always the case.  Is this just an optional thing
> for efficiency, in which case "can be grouped together" might be more
> appropriate?
> 
[[Dhruv Dhody]] Agreed. 


 
> Sorry, I don't think I conveyed my point very well.  I was suggesting that
> the examples would look like:
> 
>               Common Header
>               LSP with P2MP flag set
>               END-POINTS for leaf type 1 (add)
>                 S2LS (O=DOWN)
>                 ERO list (empty)
> 
> But maybe everyone who is going to read this already knows that and it's
> not worth the bother of changing.

[[Dhruv Dhody]] I have updated the examples. 

Thanks! 
Dhruv