Re: [Pce] Query regarding draft-ietf-pce-binding-label-sid-02

Mrinmoy Das <mrinmoy.ietf@gmail.com> Tue, 24 March 2020 13:41 UTC

Return-Path: <mrinmoy.ietf@gmail.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 E55713A07BA; Tue, 24 Mar 2020 06:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 9HK8YseOaAPR; Tue, 24 Mar 2020 06:41:50 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 19F1A3A0BD4; Tue, 24 Mar 2020 06:41:44 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id cf14so11515973edb.13; Tue, 24 Mar 2020 06:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZqxjBAwdvm9PfbozuBVMltdnKQBrJKvhcVG5kKczVpc=; b=fOdKk/g9t+wOaI7UorRacjoMVc+FMsLSDBekkgwA6L4FYJ0dD29Ga28k3HpAXd1LK7 YCpkglqB+JdaqVypDu+BX8oRzdq9iSPpF1nQggyCn3I7KVprF2qT33uRxIPlulCXfIWj Ev0uOlzMrV1zTpCb25dfeSCu31CEMWtW84+HBTcHDqzNkmjcy8ui1KDAG8cx80W1t478 EZAm5J2+SJ2Wsyafq0evKS21RL1BtapDFz5zi91zXmipTj43J798YWdtrj6lrTfaFu0Z bV8zt+t5aVEHO2B72I6l/al/rIIQezB1wHQ4OgxjB6Ohdqn12K8Q9co/k7aRy8d5988T Hd6Q==
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=ZqxjBAwdvm9PfbozuBVMltdnKQBrJKvhcVG5kKczVpc=; b=chfEny4UP9sQ2oc/9i3cbYL+Ge9VMALXvAO9Fxx4eJmxZFEnWUc7tQZxqi8m7RVoTn W8BKVIeODY/H2LHw8VzNyraKJlnkIRWGzEEFlR933qm5ynh9Tom5prpvi3BjTEM/iKzt lxy12CXCayiGAaCzB/N7okgkSKp40+NRN5Kb73ap2iPyA2tAqstvcsnvJyg6VDV7s5nA ThvLv1kOaOjwyPUFu8jXiq3+VwPcdEsmeJJf19mT6m3bNoYVwEvdGYPIH2t3CXGOOJDL GT7Peno9SNgfwgg5NT38S5X5mjsT7tGXAHTgKZ5o40At6lJwenqV/fDx/8P73dg2I7pH 0u0A==
X-Gm-Message-State: ANhLgQ2e1+Hksj+dtFV5mPWuHWqmLbPaU+rtM4fnRCxAaVJIpCshSare qocEo+AC3drP+uz+e3aqBSBrNKz8rdUvvsC4Ujg=
X-Google-Smtp-Source: ADFU+vuzRpiEGn2yUTVdGWlyytJT6GlsR6LQtICNdJ7P+CqZaZh/ZwFMi0iuB6LP+p8rD8D9/MPHqJ9ctwH51jacW4Q=
X-Received: by 2002:a17:906:35d5:: with SMTP id p21mr11524819ejb.281.1585057302789; Tue, 24 Mar 2020 06:41:42 -0700 (PDT)
MIME-Version: 1.0
References: <CANVfNKrsBpCOgi1F8abPutz3g7CvyDGU+kJwnfD9tHxvk6orSg@mail.gmail.com> <CAB75xn7jH=U_ZyptfHjsUQw5p=g+g27gtz=bdPbAb6yGykjsDg@mail.gmail.com>
In-Reply-To: <CAB75xn7jH=U_ZyptfHjsUQw5p=g+g27gtz=bdPbAb6yGykjsDg@mail.gmail.com>
From: Mrinmoy Das <mrinmoy.ietf@gmail.com>
Date: Tue, 24 Mar 2020 19:11:31 +0530
Message-ID: <CANVfNKootEiJnvug_GnMZoT5_TZvT-4QnM39rA=a3pxmaD_PRA@mail.gmail.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: Mahend Negi <mahend.ietf@gmail.com>, "Siva Sivabalan (msiva)" <msiva@cisco.com>, "Clarence Filsfils (cfilsfil)" <cfilsfil@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, stefano@previdi.net, "Chengli (Cheng Li)" <chengli13@huawei.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007b437505a199e977"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/EjHKHaRzuO2TmivUOhp7Gyc506g>
X-Mailman-Approved-At: Tue, 24 Mar 2020 07:09:02 -0700
Subject: Re: [Pce] Query regarding draft-ietf-pce-binding-label-sid-02
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: Tue, 24 Mar 2020 13:41:56 -0000

Hi Dhruv,

Thanks for your quick reply.

I have added PCE WG in this mail. More inline.

Thanks & Regards,
Mrinmoy

On Tue, Mar 24, 2020 at 6:00 PM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

> Hi Mrinmoy,
>
> I was suggest you to also include pce@ietf.org; WG could benefit from
> the discussion in future. More inline.
>
> On Tue, Mar 24, 2020 at 5:08 PM Mrinmoy Das <mrinmoy.ietf@gmail.com>
> wrote:
> >
> > Respected Authors and Contributors,
> >
> > Hope you all are doing well and safe in this tough times of Corona Virus
> Outbreak.
> >
> > I like to draw your attention regarding some parts of
> draft-ietf-pce-binding-label-sid-02 which I didn't able to understand
> properly.
> >
> > 1. BT = 0: The binding value is an MPLS label carried in the format
> >
> >   specified in [RFC5462] where only the label value is valid, and
> >   other fields (TC, S, and TTL) fields MUST be considered invalid.
> >   The Length MUST be set to 7.
> >
> >
> >     Previous versions of private draft uses 4 byte to store MPLS 20 Bit
> label and ignores TC, S & TTL fields.
>
> The length in the previous version was 6, which was incorrect. The TLV
> length is as per https://tools.ietf.org/html/rfc5440#section-7.1
> Which didnt make sense and your calculation below is correct!
>
> >     But in IETF draft after TLV structure redefinition, total length of
> the TLV becomes 7, i.e. BT(1 Byte)+Reserved(3 Byte)+MPLS 20bit Label(3
> Byte) = 7 Byte
>
> Yes
>
> >     So, now MPLS 20 Bit Labelwill be stored in 3 byte. Is it correct?
>
> You can consider it a case of rounding up 20 bits to 3 bytes.


> >     If this is correct then I feel the wording of the above paragraph
> needs to be more specific, meaning in 3 Byte Label there will be no space
> for TTL, so
> >     my suggestion is to make below correction:
> >
> >     BT = 0: The binding value is an MPLS label carried in the format
> >
> >   specified in [RFC5462] where only the label value is valid, and
> >   other fields (TC, S, and TTL) fields MUST be considered invalid.
> >   The Length MUST be set to 7.
> >
>
> My suggestion would be not mention any of the other fields and talk
> only of 20 bits of Label. I see other SR RFCs take similar approach.
>

Sounds Good. I'm agree with you.


> >
> > 2. In some cases, a stateful PCE can request the PCC to allocate a
> >
> >   binding value.  It may do so by sending a PCUpd message containing an
> >   empty TE-PATH-BINDING TLV, i.e., no binding value is specified
> >   (making the length field of the TLV as 2).  A PCE can also make the
> >   request PCC to allocate a binding at the time of initiation by
> >   sending a PCInitiate message with an empty TE-PATH-BINDING TLV.
> >
> >
> >   As per new Binding TLV Structure below, BT is of 1 Byte and there will
> be 3 Byte Reserved.
> >
> >          0                   1                   2                   3
> >
> >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |             Type              |             Length            |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |      BT       |                 Reserved                      |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       ~            Binding Value (variable length)                    ~
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >    Now, an empty Binding TLV should have length of BT(1 Byte) + Reserved
> (3 Byte) = 4 Byte instead of 2 Byte.
> >
> >    So, I do not understand how in the draft it is calculated as 2 Byte.
> Could you please give me some clue?
>
>
> This seems to be an error IMHO. 4 seems to be correct.
>

Okay. So what would  be your suggestion to developer who is implementing
this draft? Should it be taken as 4? If draft needs correction
when will that be published?

>
> Thanks!
> Dhruv
>
> >
> > Thanks & Regards,
> > Mrinmoy
>