Re: [Pce] WGLC for draft-ietf-pce-association-policy

Dhruv Dhody <dd@dhruvdhody.com> Mon, 21 September 2020 11:04 UTC

Return-Path: <dd@dhruvdhody.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 F23D63A0C8F for <pce@ietfa.amsl.com>; Mon, 21 Sep 2020 04:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=dhruvdhody-com.20150623.gappssmtp.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 193kMpXiWzkD for <pce@ietfa.amsl.com>; Mon, 21 Sep 2020 04:04:58 -0700 (PDT)
Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 695563A0C67 for <pce@ietf.org>; Mon, 21 Sep 2020 04:04:58 -0700 (PDT)
Received: by mail-pj1-x1041.google.com with SMTP id fa1so7280300pjb.0 for <pce@ietf.org>; Mon, 21 Sep 2020 04:04:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ez67P9CABhjUumg4+J90jsHzrYS25dCLFX0vR8EDVgk=; b=p2G2+phgDBGp/RO6LHKEqFSa3fmnS7OQHhnemd5+BFHlP5au7bR8BhBXb/qxw9Ck2Y nK8MG/A45uBCjMUKhTUM11GEv5n1XHaQ0iPqLPO7ZsFcTdMp5soP+r0F4CZwjnc2zNYi WZ0xN8piCwVfX5KUvQgubE7rJoz6xz1U8BhvyHv4Tl73cjBnnKK/t7JH8GwReroG8Yhn JxIFIjDjXDLT8t4LbYC9+kB2Ixs/rTRAHScU/KdNFcev8noEuRFezejUuF/OJyetgMOh ZIS9P5IT4rH3E2O6uP3h4ldnmEdwbFEhWv6HJCk2MXI8NLJLx+HM0ejNAnKykK4WUiVP Ikkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ez67P9CABhjUumg4+J90jsHzrYS25dCLFX0vR8EDVgk=; b=Fwa7lTFxeVv0zCMQ9qCihVYxAhOI8s5CQxdUqQnmX4paUuy7oK2aA87Em29Ev9xD+a GaENFEcbQq3QVxzGRUY8Heo6v5iZKOa4EDfb/eUrUFOTUFS9EBJvnxf94HO0+0410REA quZuY5Lqvmq/1PJ66/aadoVohpvnb6fdDc0DL12Z/ZkIQA0YelWsqdp4pJpJpnkE4M8z 23fHI02cgso1j1LSGoyOp1h4jOR98qPzf1KihpkQHshUqR1gPwKqB34aqllogMqX6ShC ZNCON22TR435e1ZZYv54w0ksdgWAEip4n78oTGInbX/m0tLEIhnE5NR+hKSbmYJn9q3o 4QDw==
X-Gm-Message-State: AOAM533SNKa+qMFfylCls0rt9adlL46s5HX77k5GL5Vi8H+Efi7FfvRG dyi95CS8/KmBcvIIxLEqrvjNUVENgmMgpFXNTy1qoQ==
X-Google-Smtp-Source: ABdhPJyMdNyE7RyJBuYXJXJjpyZblOKcUJG7/N5maG9QGlpyZXsVZpziedR873HPQkHOCK3Vu7e+TtzdBZTLEw0jQDs=
X-Received: by 2002:a17:90a:d90c:: with SMTP id c12mr23954686pjv.94.1600686297810; Mon, 21 Sep 2020 04:04:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAP7zK5YoAAwu4hshZpzQpam3urNQUHwrZLm3Urw0q6-g+PDGdQ@mail.gmail.com> <CAP7zK5bhDGq+DYU3m2Rvh4ZtVxyNB62vVTzVzD0YGwdVPkyryg@mail.gmail.com> <002501d68d58$d7d3aaa0$877affe0$@tsinghua.org.cn> <CAP7zK5bFcfBQgYJ17MNHXOJWZGLGWfwm7pd7+mc_zvZ7ZLC8+g@mail.gmail.com> <00a901d68fbd$4189d030$c49d7090$@tsinghua.org.cn>
In-Reply-To: <00a901d68fbd$4189d030$c49d7090$@tsinghua.org.cn>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Mon, 21 Sep 2020 16:34:21 +0530
Message-ID: <CAP7zK5Z3JEL1+m9itb1HsvjFpGEiSn=QLW-a6GW7WPCNoQE0_A@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: pce@ietf.org, draft-ietf-pce-association-policy@ietf.org, pce-chairs <pce-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/JgGb3XGh7xkXVm1ObnWtkNWIAC0>
Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy
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: Mon, 21 Sep 2020 11:05:00 -0000

Hi Aijun,

See inline...

On Mon, Sep 21, 2020 at 7:46 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>
> HI, Dhruv and the authors this draft:
>
> How to ensure the interoperability? The document just says:
> "Further, if one or more parameters received in the POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as unacceptable in the context of the
>    associated policy (e.g. out of range value, badly encoded value...), the PCEP speaker MUST NOT apply the received policy and SHOULD log this event."
> There will be no more detail error information can be reported via such opaque policy. How to debug the policy deployment then?
>

I agree, it would be wise to generate an error, we could reuse the
error from RFC 8697.  How about ->

   Further, if one or more
   parameters received in the POLICY-PARAMETERS-TLV received by the PCEP
   speaker are considered as unacceptable in the context of the
   associated policy (e.g. out of range value, badly encoded value...),
   the PCEP speaker MUST reject the PCEP
   message and send a PCErr message with Error-Type 26 "Association
   Error" and Error-Value 5 "Operator-configured association information
   mismatch"  [RFC8697]. PCEP speaker SHOULD log this event.


> And, if there are some examples to show what association requirements can't be accomplished by the SVEC object, and can only be done via PAG, the document may be more convincible.
>

SVEC object has an impact only on the diversity association and it was
covered in https://www.rfc-editor.org/rfc/rfc8800.html#name-relationship-to-svec.
Your suggestion to add an example is a good idea. Can the authors
consider adding something in the appendix?

Thanks!
Dhruv [ still without hats :) ]


>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> -----Original Message-----
> From: Dhruv Dhody [mailto:dd@dhruvdhody.com]
> Sent: Friday, September 18, 2020 12:40 PM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: pce@ietf.org; draft-ietf-pce-association-policy@ietf.org; pce-chairs <pce-chairs@ietf.org>
> Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy
>
> Hi Aijun,
>
> Thank you for your comments.
>
> I wanted to focus on the 3rd point. I remember this being discussed perhaps in the previous incarnation of the draft. The main motivation in PCEP is to provide a "standard" container and mechanism to associate (and encode the policy) and leave the actual policy standardization out of the scope of PCEP.
>
> Another way to look at this would be, when a policy is well-known and needs to be standardized (some may consider diversity or SR-Policy as those policies), we define a new standard association-type for it with a standard TLV. This I-D is used when we do not have a standard policy defined in PCEP but would like to use the protocol as an opaque container to associate policies to the path. What does that policy mean and how to encode/decode the policy parameters are expected to be done out-of-band via other mechanisms which are better suited for policy definitions and configurations at the PCEP speakers.  Hope this helps!
>
> Thanks!
> Dhruv (hat-less!)
>
> On Fri, Sep 18, 2020 at 6:43 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> >
> > Hi, Authors:
> >
> > I Just have a quick view of this draft, and has some points wanted to
> > be
> > clarified:
> > 1. This draft defines one new association type (policy association
> > type) that follows the procedures described in RFC8697 and attached
> > TLV? Is it right?
> > 2. According to the text described in
> > https://tools.ietf.org/html/rfc8697#section-3.2, to define one new
> > association type, the related draft should clarify its relationship
> > between the SVEC object, if any.
> > Should this draft to add such part?
> > 3. For the definition of "Policy-Parameters-TLV", the "Policy
> > Parameters" is opaque value to the PCEP peers.  The draft describes
> > the PCEP peers should know how to the encoding format of such policy
> > in advance. But from my POV, the encoding format is the main content
> > needs to be standardized. If such contents can't be standardized, what
> > benefit can we get from this standardization work? What's the reason not to standardize this?
> >
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> >
> > -----Original Message-----
> > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of
> > Dhruv Dhody
> > Sent: Thursday, September 17, 2020 5:42 PM
> > To: pce@ietf.org
> > Cc: draft-ietf-pce-association-policy@ietf.org; pce-chairs
> > <pce-chairs@ietf.org>
> > Subject: Re: [Pce] WGLC for draft-ietf-pce-association-policy
> >
> > Hi WG,
> >
> > A reminder to the WG to be more vocal. I am copying this slide from
> > the chair's WG status slide
> > [https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduc
> > tion-0
> > 1]
> >
> > > Please be Vocal
> > >
> > > o During WG Adoption and WG LC calls, the response is less.
> > >
> > > o Please be vocal on the list to help us gauge the consensus better.
> > >
> > > o The working group mailing lists are looked at by the IESG, IAB,
> > > and
> > others (internal and external to IETF) to determine
> > interest/participation level in our standards process.
> > >
> > > o Please review ideas from your peers, these are community outputs
> > > of the
> > working group as a whole.
> > >
> >
> > The WG LC for the draft in question ends on Monday 21st Sept. Please
> > respond with your explicit support (or not) for its publication.
> >
> > Thanks!
> > Dhruv & Julien
> >
> >
> >
> > On Fri, Sep 4, 2020 at 10:43 AM Dhruv Dhody <dd@dhruvdhody.com> wrote:
> > >
> > > Hi WG,
> > >
> > > This email starts a working group last call for
> > > draft-ietf-pce-association-policy [1].  Please indicate your support
> > > or concern for this draft. If you are opposed to the progression of
> > > the draft to RFC, please articulate your concern. If you support it,
> > > please indicate that you have read the latest version and it is
> > > ready for publication in your opinion. As always, review comments
> > > and nits are most welcome.
> > >
> > > The WG LC will end on 21st September 2020.
> > >
> > > Thanks,
> > > Dhruv & Julien
> > > [1]
> > > https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> >
>