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

Mrinmoy Das <mrinmoy.ietf@gmail.com> Wed, 22 April 2020 05:28 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 AAB763A0F08; Tue, 21 Apr 2020 22:28:37 -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 SXWp7TtWo_Uu; Tue, 21 Apr 2020 22:28:34 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 3C18F3A0F06; Tue, 21 Apr 2020 22:28:34 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id s10so573547edy.9; Tue, 21 Apr 2020 22:28:34 -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=HD+CKQ6YD3alzsTm85MKzr2NY5qzZ5Ah0p/7YeTriag=; b=FhdR8uIH+s7VB8owEMkxzegNtQdcehBHlVmiGFiuwF7QYYTcro2Fu4rnXszW9AqSI8 1GOMUmhSK6XtUuiRb6+WYS6PtM5DRxC6z+O7EFJ0UtjBhvvhuWR6hqu5tUPIzZOoLYxX nDQ4FeRJba1OxTKqOEjoXZ41pYE+WjkvgW1dIPAHKt/oAeP39F5fQGwJqnB93wOXtLUN b/SitW+AFNaw3loIQOjQmu+fN16c/I4gWsGnCDALfmMny8/GkZ+UC7H5RDYkIq1kcMHl aTFJiXYk3Dl5kTFTqIy9LzuiWf1oO1SgI5TJR6CYzZQvICg7dIL9RIcVzzorVgIsd8nG TWyg==
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=HD+CKQ6YD3alzsTm85MKzr2NY5qzZ5Ah0p/7YeTriag=; b=RR3ze5Cojs6ya6bx0Xfb/XBOLtcK1LliVZaldtsbzYqFlnWYNXPjhfcTDccAr/maUS Ht7ygPbtAHBVwbarsg7++eSkqFfc7ao+nnTicpxKQzwVkECBCnbDC7i1A1aRl5CjFvZq 0RzFQ8C7uOI9eFTPGrnOsPNRHAICC32jiW/INaMj6LXsffnaORpJIk2pBsi/0hW0FNoT pnUBlNwmHPTJU1cJNBRi2mzNWy67Bdz+m7JpfomXBN7AfhFUaH1+WMTtecdzbZWJiKqV SCMayw+fYhenoRAk8kcRO9ZbgS7xZeOQCGFS4+nzrdt3s0DLgNgod+PyZVpznG4kqjP1 /KEg==
X-Gm-Message-State: AGi0PuYwZn7E7yZmagoBtORECUgBsYssCkSeSAnJ/EmHb6mgMLwlJmPi p/GDDSniR1QS+zKxYJ05WjjUOC8NkbCdx1kwyIs=
X-Google-Smtp-Source: APiQypLP/Aua/ec3Osu8GQ2XOrGmAIiqnJjNUdt86e5XZgv8zyKsNxHi/iqnp7yBbBVfqRzXiynLZYoqsnRNh3tz4/Q=
X-Received: by 2002:aa7:cdd9:: with SMTP id h25mr514819edw.17.1587533312593; Tue, 21 Apr 2020 22:28:32 -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> <CAB75xn5zDbgUy71WaS4Vzg_sLBDxjGs8uPgefotUpkWsj9Ad3A@mail.gmail.com>
In-Reply-To: <CAB75xn5zDbgUy71WaS4Vzg_sLBDxjGs8uPgefotUpkWsj9Ad3A@mail.gmail.com>
From: Mrinmoy Das <mrinmoy.ietf@gmail.com>
Date: Wed, 22 Apr 2020 10:58:21 +0530
Message-ID: <CANVfNKpph=4C8gxB_4KRYoFE=VrQRMnA0ezmD=rd_YdGJWwohA@mail.gmail.com>
To: Dhruv Dhody <dhruv.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: multipart/alternative; boundary="0000000000002a918105a3da67f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/PiTQ2p7-5WHraQuurV1SKjduWKY>
X-Mailman-Approved-At: Tue, 21 Apr 2020 22:48:26 -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 05:28:38 -0000

Thanks a lot Dhruv for the clarification.

Thanks & Regards,
Mrinmoy

On Wed, Apr 22, 2020 at 9:59 AM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:

> 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
> >>
>