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

Dhruv Dhody <dhruv.ietf@gmail.com> Wed, 22 April 2020 04:29 UTC

Return-Path: <dhruv.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 4D3413A0D76; Tue, 21 Apr 2020 21:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 3mQdAe_g3IVA; Tue, 21 Apr 2020 21:29:17 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 24D593A0D77; Tue, 21 Apr 2020 21:29:16 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id b12so941974ion.8; Tue, 21 Apr 2020 21:29:16 -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=b4XZudeo7r1gXrPdiw0gC9Tc7iMIv8+R4l16PDn7G3k=; b=ThZ936yz9SrL1STg0R0SVT7mPZ2sdXyOvSZYefk6UcwZpSVxdy0jnYWzWzWQC+sQOX 7lwvyUgqEciwAl+mj1EcNDqFxhgBd0uV8kiHOzw43HrP0FrJ32pvOl0emcEgERofPwyG bF1COBqjIy3lFXrXo9NnugqvioKzdUvXI3cQnurPD9hhgle5RtpBU2Mv/1W8m01ZZzxJ h7Lc5do5ROQjtpC6jeH5oxT087OSUl40J1FzoZOA/sphNfp2AOZehvE0EJFDeDwakSS2 MDlO2hQU7Uc5qwSs9re+zLh1/SXdrGya2/4zNjd2SpQBjxnhH677jV1OKWTU1BHyvoLp ytEA==
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=b4XZudeo7r1gXrPdiw0gC9Tc7iMIv8+R4l16PDn7G3k=; b=tbaeeujkH+I5iPQBhC3vt1mWESS8qhK+hZ+NKU8zDFnPmegJSMs0NamWy3KatOqJ/S krLfsDjVEFFbM3+GBEaVQKxBl/zyomk8E58ZgdJF/M0Odjg+M8Z9U9jsC8Mb06+ciMTI eaeludSQAHu0cp/0yNW0Fle+uiJxJIDNBBBoB1e2IzvSRofQSHZ3j/MZVvuYmEYx3m3a tAP8j4A077ffJdhnu8fmSKzw/LfZGNTpV0xysIn1QBRKN92RN397zwaYdKS1lLsZFEuM Blt8gGNoTB+n5RYC0C4PZbR70lR3XCn9Ojt/FdbFtOzSQkKlTkBHFWf8rrrvTogtyDaz ao2g==
X-Gm-Message-State: AGi0PuYSyV4X/oLdCqOqED4KtF65nk11KvNEodGUHd1rr++tx6uG07k5 +lXhtV51HuKPtUfTlc1ADGxFVb7m6BfKvqTiBuY=
X-Google-Smtp-Source: APiQypK5wBd7BZzjXZPJXiUjNCYxLZZqQWfYYG6sslH36zf9uDmHr1PboA9XanBsqjSGDFUXBe2vqsa6RDSqHJM9Hio=
X-Received: by 2002:a6b:7319:: with SMTP id e25mr18147898ioh.193.1587529756058; Tue, 21 Apr 2020 21:29:16 -0700 (PDT)
MIME-Version: 1.0
References: <CANVfNKrsBpCOgi1F8abPutz3g7CvyDGU+kJwnfD9tHxvk6orSg@mail.gmail.com> <CAB75xn7jH=U_ZyptfHjsUQw5p=g+g27gtz=bdPbAb6yGykjsDg@mail.gmail.com> <CANVfNKootEiJnvug_GnMZoT5_TZvT-4QnM39rA=a3pxmaD_PRA@mail.gmail.com> <CAB75xn4g7ja=Ej6+Dwiw2STZk9Ch7p_Ss9ht+UQ2JwPjuL7qfg@mail.gmail.com> <C43EB1B9-623F-42E7-8E2D-DDC40AB2CA28@previdi.net> <CANVfNKrzgL78MeMz9oQtZzvm2qu8F3T64oy9g+Hcd4izW9YJfA@mail.gmail.com>
In-Reply-To: <CANVfNKrzgL78MeMz9oQtZzvm2qu8F3T64oy9g+Hcd4izW9YJfA@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Wed, 22 Apr 2020 09:58:39 +0530
Message-ID: <CAB75xn5zDbgUy71WaS4Vzg_sLBDxjGs8uPgefotUpkWsj9Ad3A@mail.gmail.com>
To: Mrinmoy Das <mrinmoy.ietf@gmail.com>
Cc: stefano previdi <stefano@previdi.net>, 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>, "Chengli (Cheng Li)" <chengli13@huawei.com>, pce-chairs <pce-chairs@ietf.org>, pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/1y5-S7_CFPmZCK4BwaThjYIKELo>
X-Mailman-Approved-At: Tue, 21 Apr 2020 21:33:54 -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: Wed, 22 Apr 2020 04:29:20 -0000

Hi Mrinmoy,

On Wed, Apr 22, 2020 at 9:35 AM Mrinmoy Das <mrinmoy.ietf@gmail.com> wrote:
>
> Hi All,
>
> If we only mention 20-bit label then what will be the structure of it?
> As per generic MPLS label structure 24-bit used to look like as follows:
>
> |<--------20-bit---------->|<-3-bit->|<-1-bit->|
> |<-MPLS 20-bit label->|<- TC ->|<-  S  ->|
>
> Now if we just mention about MPLS 20-bit label, is that mean following representation:
>
> |<-4-bit->|<--------20-bit---------->|
> |<-all 0->|<-MPLS 20-bit label->|
>

No!
The format is still based on RFC 5462 and thus it would look something
like this -

       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=7          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      BT=0     |                 Reserved                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label                  | all zeros (ignore)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Even though the length=7, you will need to process the Binding Value
field based on the Binding Type (BT) which says that the format is as
per RFC 5462.

Note that the extra byte of zeros at the end is for padding as per
https://tools.ietf.org/html/rfc5440#section-7.1 and not counted in the
length.

Stay Safe!
Dhruv

PS. Request the authors to update the draft SOON based on Mrinmoy's
original email.

> Thanks & Regards,
> Mrinmoy
>
> On Wed, Mar 25, 2020 at 3:56 PM stefano previdi <stefano@previdi.net> wrote:
>>
>> Hi Dhruv,
>>
>> I agree with your proposed changes:
>>
>> 1. only mention the 20 bits label value
>> 2. fix the length to 4.
>>
>>
>> Thanks.
>> s.
>>
>>
>> > On Mar 24, 2020, at 3:14 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>> >
>> > Hi Mrinmoy,
>> >
>> > I will give authors some time to respond and confirm (and spin a new
>> > update). I have noted this in the PCE WG wiki [
>> > https://trac.ietf.org/trac/pce/wiki/WikiStart ] to make sure we could
>> > track this to closure.
>> >
>> > Thanks!
>> > Dhruv
>> >
>> > On Tue, Mar 24, 2020 at 7:11 PM Mrinmoy Das <mrinmoy.ietf@gmail.com> wrote:
>> >>
>> >> 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
>>