Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08

Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 07 February 2019 04:25 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 F3219131054; Wed, 6 Feb 2019 20:25:19 -0800 (PST)
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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 cBpeRgzUJk1y; Wed, 6 Feb 2019 20:25:18 -0800 (PST)
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 4F779130FFB; Wed, 6 Feb 2019 20:25:18 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 868EB39A78B047298B65; Thu, 7 Feb 2019 04:25:16 +0000 (GMT)
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 7 Feb 2019 04:25:16 +0000
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.233]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0415.000; Thu, 7 Feb 2019 09:55:07 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-pce-stateful-pce-p2mp@ietf.org" <draft-ietf-pce-stateful-pce-p2mp@ietf.org>
CC: "pce@ietf.org" <pce@ietf.org>, 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Thread-Topic: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08
Thread-Index: AdS8shxwwiJJcZucR/6S2SJACBtxRABG1N/wAAbcfAAALH8DgA==
Date: Thu, 07 Feb 2019 04:25:06 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8D92CA83@BLREML503-MBX.china.huawei.com>
References: <002901d4bcb3$a1069cc0$e313d640$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8D92AEB0@BLREML503-MBX.china.huawei.com> <01bc01d4be16$fcdf7d50$f69e77f0$@olddog.co.uk>
In-Reply-To: <01bc01d4be16$fcdf7d50$f69e77f0$@olddog.co.uk>
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/b1-VhcS51L9EllvtOKqEPNWooW8>
Subject: Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08
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: Thu, 07 Feb 2019 04:25:20 -0000

Hi Adrian, 

> >> 6.1
> >>
> >> The following bit of RBNF echoes something we did in the base
> >> stateful draft and which has caused confusion / errata to be raised
> >> because it looks so wrong (actual and intended all mixed up).  Do we
> >> absolutely need to do this just to have something that looks like the
> >> base draft (which looks weird)?  If so, please give an explicit
> >> explanation in the text, otherwise we will just get the errata raised
> again.
> >>
> >>    <state-report> ::= [<SRP>]
> >>                        <LSP>
> >>                        <end-point-intended-path-pair-list>
> >>                        [<actual-attribute-list>
> >>                        <end-point-actual-path-pair-list>]
> >>                        <intended-attribute-list>
> >
> > [[Dhruv Dhody]] So far we have tried to maintain compatibility between
> > P2P
> and P2MP
> > versions of the PCEP messages. Additionally we state -
> >
> >   Note that the compatibility with the [RFC8231] definition of <state-
> >   report> is preserved.  At least one instance of <END-POINTS> MUST be
> >   present in this message for P2MP LSP.
> >
> > I have also added this now -
> >
> >   Note that the ordering of <end-point-intended-path-pair-list>,
> >   <actual-attribute-list>, <end-point-actual-path-pair-list>, and
> >   <intended-attribute-list> is done to retain compatibility with state
> >   reports for the P2P LSPs as per [RFC8231].
> 
> Your suggested text is good.
> 
> Just looking at the errata for RFC 8231
> 
> https://www.rfc-editor.org/errata/eid5492 is still "reported" and shows an
> inconsistency between the text "intended-attribute-list is optional" and
> the RBNF...
> <path>::= <intended-path>
>                 [<actual-attribute-list><actual-path>]
>                 <intended-attribute-list> That looks like a problem to me.
> But I'm not sure what the correct resolution is.
> I don't see any discussion on the list.
> If we can get that resolved, it could help us be clear here.
> Depending on the resolution, we might need a change to this draft.
> 
[[Dhruv Dhody]] I responded with a proposal to handle the errata. 
And the corresponding change is made in this I-D as well. 

> > -
> >
> > Shouldn't the description of the N bit should also mention PCReq and
> PCRep?
> >
> [[Dhruv Dhody]] I have added this text -
> 
>    The N flag is used in a PCRpt, PCUpd, or PCInitiate message to
>    indicate a P2MP TE LSP.  In case of PCReq and PCRep, the N flag in
>    the RP (Request Parameters) object ([RFC8231]) is used to indicate
>    P2MP path computation.  The N flag in the LSP object MUST also be set
>    if the N flag in the RP object is set.  If there is mis-match
>    between the N flag in the RP and the LSP object in PCReq or PCRep
>    message, the PCEP speaker MUST generate an error with error-type 10
>    ("Reception of an invalid object") and error-value TBD1 (to be
>    allocated by IANA) ("Mis-match of N flag in RP and LSP object").

[[Dhruv Dhody]] It was pointed out to me that this is applicable for all flags that are common between RP and LSP objects, so better way forward could be to refer to RP object only when both RP and LSP object exist in the PCEP messages. 

Thus I have added - 

   The flags defined in this section (N, F, E flags) are used in PCRpt,
   PCUpd, or PCInitiate message.  In case of PCReq and PCRep message,
   these flags have no meaning and thus MUST be ignored.  The
   corresponding flags in the RP (Request Parameters) object are used as
   described in [RFC8231].

Let me know if this is fine with you? 

Working Copy - https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-10.txt
Diff - https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-09&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-stateful-pce-p2mp-10.txt

Regards,
Dhruv