Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Dhruv Dhody <dd@dhruvdhody.com> Wed, 31 March 2021 18:39 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 5760D3A3135 for <pce@ietfa.amsl.com>; Wed, 31 Mar 2021 11:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q7e5pl1B7d9O for <pce@ietfa.amsl.com>; Wed, 31 Mar 2021 11:39:26 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 9D4D23A3133 for <pce@ietf.org>; Wed, 31 Mar 2021 11:39:25 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id a12so6309036pfc.7 for <pce@ietf.org>; Wed, 31 Mar 2021 11:39:25 -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; bh=IsHWBPpsJij5/V0vabeeWcUDrTAvCWMvqTqFMXYzeqs=; b=BPkeFbtxKRVzJMqB3YdeGfitiLbUDbEXlQNcO0EPzK9k4GFhj8bWX2IRogT6ItY3cn uqjjiyOcQjiVjcOwIQhdzpPeqUFxSXMN+r33q1F5jRu3XW5MqHP54lC10uEsLfaWmHb/ nvTFO24+KpvU3u6i02RL4JAyFjnp4JokuFtxZr1FmSVzKGoCHjHvM/H//heoS0eG/bZC aloFpVXfWyn/OJl/wV5uShnPOn68xcoKWq3KOK56tF9b53J7S47+l0sLUabT4Gk4QxO1 2RiFuSMdXpT4T8LZZfVwfE3yksy6uudeap9DUEwnoT7sHfJ4/mdBo1WGqnNBsietdz7v bUtA==
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; bh=IsHWBPpsJij5/V0vabeeWcUDrTAvCWMvqTqFMXYzeqs=; b=rHCOFPLieNAMaC2XhiIP5inS6Tf8AuYdvDDktItBlpozOtuP+0S7+4YO4eZ/XBzFH8 Y6cri6Agpst7pm0MYEOeWz9gTvOR12A1iF3k1BqPH2/5lkkoDq+uQqZZnArmu9ziVg4j P8lHiFBdo0SCostelSthNiEm/WwzuXhmkFAkxj/U2Bx1jqqWFFPjrX/xbTM7NPrlvWBx O4PnYkd9ros/lG4NNxeUKAG3sLrA6JZdzp/2LFeoDoEV6wEtJ4u1seher2n93o5aZbXP qDqhk9edhfzK94/6TeU/X+9++WxaNVlwESd4lRgE5clM98IpbkPKa0KBTZkQoxKOPlo4 bnaw==
X-Gm-Message-State: AOAM533x0b0muXEeiJ0elF3xRWtN064by8247KLY56Vql43wp6HknGLW /7HplhrVkenIq20Ej6QK0HVlzUv/OMWIfOC4OgvSqjpnS3Vbr/WT
X-Google-Smtp-Source: ABdhPJxI0JICW8OnPWCAqz6+29ZuRU7LBLV3FlnATjg7FiD3NLCH4qVOw7QG56izQI/19fyjL0L9YP7guFgzHbmYhoA=
X-Received: by 2002:a62:1ad5:0:b029:1fa:c667:2776 with SMTP id a204-20020a621ad50000b02901fac6672776mr4242155pfa.6.1617215964447; Wed, 31 Mar 2021 11:39:24 -0700 (PDT)
MIME-Version: 1.0
References: <7010_1616065722_605334BA_7010_19_1_3f1d8d24-af98-f962-95ea-0e6ec46b738c@orange.com> <010f01d71ecf$72b9c600$582d5200$@tsinghua.org.cn> <0bf31f96c9e44597b8634e0f1efdac12@huawei.com> <12637_1617213626_6064B8BA_12637_79_1_0ab201c2-238c-4df6-b271-4b6d105381ec@OPEXCNORM64.corporate.adroot.infra.ftgroup>
In-Reply-To: <12637_1617213626_6064B8BA_12637_79_1_0ab201c2-238c-4df6-b271-4b6d105381ec@OPEXCNORM64.corporate.adroot.infra.ftgroup>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 1 Apr 2021 00:08:48 +0530
Message-ID: <CAP7zK5Zay4KUoPY679rOZWXFyRxRJFBEgJuJfEUMfebDNvk7Zg@mail.gmail.com>
To: olivier.dugeon@orange.com
Cc: "Chengli (Cheng Li)" <c.l@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "julien.meuric@orange.com" <julien.meuric@orange.com>, "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000162b7305bed96fe2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/73W6VfvZl4Mn1JFSJJADoHmQreU>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
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: Wed, 31 Mar 2021 18:39:31 -0000

Hi Olivier,

On Wed, Mar 31, 2021 at 11:30 PM <olivier.dugeon@orange.com> wrote:

> Hi Cheng, Aijun,
>
> I think that the 'R' bit to clearly indicate that BSID is removed
> is mandatory. In fact, in case of multiple BSID, it will become clearly
> a nightmare from an implementation point of view to manage the removal.
>
> Let me take a simple example:
>
> Assume a PCE would setup some BSID into a PCC. It first send a PcInitiate
> message with an empty TE-PATH-BINDING TLV to request a BSID. PCC send a
> PcRpt
> message with a BSID=1 (simple value). Then, the PCE would a second BSID.
> So, it
> sends a PcUpdate message with a TE-PATH-BINDING TLV and the first BSID=1
> and a
> second empty TE-PATH-BINDING TLV to get the second one. PCC sends back a
> PcRpt
> message with the 2 TE-PATH-BINDING BSID=1 and BSDI=2. We repeat the last
> operation
> to collect a third BSID=3. Now the PCE would remove the BSID=2. It must
> send a
> PcUpdate message with TE-PATH-BINDING BSID=1, TE-PATH-BINDING BSID=3 and an
> empty TE-PATH-BINDING.
>
> So, how the PCC could determine that this last emptyTE-PATH-BINDING
> corresponds
> to a deletion and not a creation ?
>
>
Looking at the working copy[1]/diff[2] that Cheng posted, the empty
TE-PATH-BINDING TLV is used to request allocation only (and not to withdraw
old values). So in the example above to remove BSID=2, the PCUpd message
with TE-PATH-BINDING BSID=1 & TE-PATH-BINDING BSID=3 are sent.

Adrian provided some cleaner text that has been incorporated for this now.
Does the updated text resolve this?

Thanks!
Dhruv (as a WG participant)

[1]
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt
[2]
https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-07.txt&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-08.txt


> There is a large risk of ambiguity in particular if the PCE does not send
> the TE-PATH-BINDING TLVs in the right order, if PCE and PCC become
> de-synchronize
> on the number of BSID ...
>
> Thus, I think that a 'R' bit for deletion is mandatory.
>
> Regards
>
> Olivier
>
> Le 26/03/2021 à 03:46, Chengli (Cheng Li) a écrit :
> > Hi Aijun,
> >
> > Many thanks for your comments! Please see my reply inline. The diff is
> attached.
> >
> > Respect,
> > Cheng
> >
> >
> >
> > -----Original Message-----
> > From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn]
> > Sent: Monday, March 22, 2021 11:57 AM
> > To: julien.meuric@orange.com; pce@ietf.org
> > Cc: draft-ietf-pce-binding-label-sid@ietf.org
> > Subject: RE: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
> >
> > Hi,
> >
> > 1. The concept of PCC requests the allocating of BSID for a LSP is
> clear, but the scenario that PCE allocate the BSID is not convincible.
> >   PCE can request the PCC to allocate the BSID for one LSP. It should
> not allocate the value directly.
> >
> >
> > [Cheng]Section 8 is optionally used when PCE is in control of label
> space (PCECC) and would not be used for vanilla stateful PCE.
> >
> > 2. What's the reason to include the BT=3, that is "SRv6 Endpoint
> Behavior and SID Structure"? It is one general information and not close
> connection to the normal usage of BSID.
> > [Cheng] This is an alignment with other SIDs. In order to support
> backward compatibility, we want to remain BT2, and introduce a new BT for
> support SID structure. It can be used for future use case.
> >
> >
> > 3. Will it be more clear to define one new bit(R bit) within the Flag
> field of "TE-PATH-BINDING TLV" to indicate clearly the remove of BSID
> allocation to a LSP? Instead of the implicit method that depending on the
> presence of TE-PATH-BINDING TLV as described in current draft?
> > [Cheng] It is possible. But there are existing implementations that
> would get impacted.
> >
> >
> > 4. For BT=0, the length is set to 7. How to skip the padding trailing
> zeros to a 4-octet boundary when parsing?
> > [Cheng] We have updated the description of BT=0 as per Adrian's comment.
> Length=7 and handling of padding is as per RFC5440:
> >
> >    The Length field defines the length of the value portion in bytes.
> >    The TLV is padded to 4-bytes alignment; padding is not included in
> >    the Length field (so a 3-byte value would have a length of 3, but the
> >    total size of the TLV would be 8 bytes).
> >
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> > -----Original Message-----
> > From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of
> julien.meuric@orange.com
> > Sent: Thursday, March 18, 2021 7:09 PM
> > To: pce@ietf.org
> > Cc: draft-ietf-pce-binding-label-sid@ietf.org
> > Subject: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and
> Code Point Allocation)
> >
> > Hi all,
> >
> > This message initiates a 2-week PCE WG Last Call for
> draft-ietf-pce-binding-label-sid-07. Please review and share your feedback,
> whatever it is, using the PCE mailing list. This WGLC will end on Thursday
> April 1st (no kidding).
> >
> >
> > Moreover, we have received a request from the authors for a code point
> allocation to support interoperability testing.
> >
> > RFC 7120 requires to meet the following criteria to proceed:
> >
> > b. The format, semantics, processing, and other rules related to
> handling the protocol entities defined by the code points (henceforth called
> > "specifications") must be adequately described in an Internet-Draft.
> > c. The specifications of these code points must be stable; i.e., if
> there is a change, implementations based on the earlier and later
> specifications must be seamlessly interoperable.
> >
> > If anyone believes that the draft does not meet these criteria, or
> believes that early allocation is not appropriate for any other reason,
> please send an email to the PCE mailing list explaining why. If the chairs
> hear no objections by Thursday, March 25th, we will kick off the "early"
> allocation request.
> >
> > Thanks,
> >
> > Dhruv & Julien
> >
> >
> >
> ____________________________________________________________________________
> > _____________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> >
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> --
> Orange logo <http://www.orange.com>
>
>
>
> Olivier Dugeon
> Orange Expert, Future Networks
> Open Source Referent
> Orange/IMT/OLN/WTC/IEE/iTeQ
>
>
>
> fixe : +33 2 96 07 28 80
> mobile : +33 6 82 90 37 85
> olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>