From nobody Thu Apr 16 02:39:55 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 074483A1310; Thu, 16 Apr 2020 02:39:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158702999397.19458.12622154672181644572@ietfa.amsl.com> Date: Thu, 16 Apr 2020 02:39:54 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-vn-association-02.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:39:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks Authors : Young Lee Haomian Zheng Daniele Ceccarelli Filename : draft-ietf-pce-vn-association-02.txt Pages : 14 Date : 2020-04-16 Abstract: This document describes how to extend Path Computation Element (PCE) Communication Protocol (PCEP) association mechanism introduced by the PCEP Association Group specification, to further associate sets of LSPs with a higher-level structure such as a virtual network (VN) requested by clients or applications. This extended association mechanism can be used to facilitate virtual network control using PCE architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-vn-association-02 https://datatracker.ietf.org/doc/html/draft-ietf-pce-vn-association-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-vn-association-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 20 03:46:38 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DD33A0B24; Mon, 20 Apr 2020 03:46:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158737959251.7440.3540230775964951484@ietfa.amsl.com> Date: Mon, 20 Apr 2020 03:46:32 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-association-policy-09.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 10:46:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element communication Protocol (PCEP) extension for associating Policies and Label Switched Paths (LSPs) Authors : Stephane Litkowski Siva Sivabalan Jeff Tantsura Jonathan Hardwick Mahendra Singh Negi Cheng Li Filename : draft-ietf-pce-association-policy-09.txt Pages : 15 Date : 2020-04-20 Abstract: This document introduces a simple mechanism to associate policies to a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-association-policy-09 https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-policy-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-policy-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 21 21:33:34 2020 Return-Path: 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 23CC63A0D10; Tue, 21 Apr 2020 21:05:14 -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 FYvDFtwz-eCQ; Tue, 21 Apr 2020 21:05:11 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 BB04E3A0D0F; Tue, 21 Apr 2020 21:05:10 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id j20so507307edj.0; Tue, 21 Apr 2020 21:05:10 -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=5oTFpiYEZTX8XpO/Yrv6tL1tjI2nkwiM2zCCCa2YTCE=; b=dGP0W9n3Rp0aLtieazi5uPvqLnZ5tS9+Bkc9YWBFZTbPPpuzw3XdHgNSJIkK47YKoP MZTSOQBeFDFEUwz5OYM0zGTfIYb0QZsMP9vckLSLUJS8FI+b8J0X8icwTRorBOrEr/W7 PZMtg5wl1izgTGhe2Z4cEVvKQ53IDMmCl9pgOXNFIs25UtX6sijfsH/hraOKsMjHTz3S 6I3Nb11hkII+m627//nuirsZa//ZfWvvbqO3DB2+fJNUjAYmsYysCSMMgcy71s8ujcFy WCQj3XXGJ996CTisSGA8Lt02p1PxrXPzma1xtn/toHAi/97ftl0N6hb7f+QpRSdnCcF/ eFdQ== 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=5oTFpiYEZTX8XpO/Yrv6tL1tjI2nkwiM2zCCCa2YTCE=; b=aNJaw4IZrJZLF7nzyUA4rtEvT6oZCD50X0IkD8LUS4otnkBjqFX5Ge/HRCf0xdD4Oz MM6yhwjuYgxPh4+C0Ikn82HaTMB2mOK/tr007eJH9gHXU1J1f1tCuyKa5JFiOxoDQrMS 0Td/ORH57DjFFzyeWTewT2TJleCAQPbix58b3gg0OJ16MDclhScfJ8ZKREhsuV0YUmqC gi3Na4L9tm0SMU7VqaIFC/fCpV7+2QBuQEWuRyQ5ntOo/BItgLxHKXcbsJzuOV9nhhGw focfAsJe6xsQMK5UQwoxmdSaIArHXlsrOcxVEuEUEOcyZpXGI5cAujp995K8bLPdRAHj pLEQ== X-Gm-Message-State: AGi0PuZKRGyP1MlG3h9QnopGhtJeuGVDbLsbf5iz7A4bWOJy8d/v8VuX Vv4+9bvPwfXX9zZXiCh2KVxayNXVQVO4/6Fufmo= X-Google-Smtp-Source: APiQypKVbHNxKpwQTUC0lnCoGIG8KZgb3HAAQV24pLU2CgZmQXTUXjmh7wSYXfYBik9p3ZD5ZU0PP9GsCDxuS2P+VD0= X-Received: by 2002:a50:bb25:: with SMTP id y34mr20954990ede.237.1587528309279; Tue, 21 Apr 2020 21:05:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mrinmoy Das Date: Wed, 22 Apr 2020 09:34:57 +0530 Message-ID: To: stefano previdi Cc: Dhruv Dhody , Mahend Negi , "Siva Sivabalan (msiva)" , "Clarence Filsfils (cfilsfil)" , Jeff Tantsura , Jonathan Hardwick , "Chengli (Cheng Li)" , pce-chairs , pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000f20c9305a3d93c42" Archived-At: X-Mailman-Approved-At: Tue, 21 Apr 2020 21:33:33 -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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 04:05:14 -0000 --000000000000f20c9305a3d93c42 Content-Type: text/plain; charset="UTF-8" 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->| Thanks & Regards, Mrinmoy On Wed, Mar 25, 2020 at 3:56 PM stefano previdi 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 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 > 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 > 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 > 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 > > --000000000000f20c9305a3d93c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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:

|&= lt;--------20-bit---------->|<-3-bit->|<-1-bit->|
= |<-MPLS 20-bit label->|<- TC ->|<-=C2=A0 S=C2=A0 ->|

Now if we just mention about MPLS 20-bit label, is tha= t mean following representation:

|<-4-bit->|= <--------20-bit---------->|
|<-all 0->|<-MPLS 20-b= it label->|

Thanks & Regards,
Mri= nmoy

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 o= f Corona Virus Outbreak.
>>>>
>>>> I like to draw your attention regarding some parts of draf= t-ietf-pce-binding-label-sid-02 which I didn't able to understand prope= rly.
>>>>
>>>> 1. BT =3D 0: The binding value is an MPLS label carried in= the format
>>>>
>>>>=C2=A0 specified in [RFC5462] where only the label value is= valid, and
>>>>=C2=A0 other fields (TC, S, and TTL) fields MUST be conside= red invalid.
>>>>=C2=A0 The Length MUST be set to 7.
>>>>
>>>>
>>>>=C2=A0 =C2=A0 Previous versions of private draft uses 4 byt= e 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!<= br> >>>
>>>>=C2=A0 =C2=A0 But in IETF draft after TLV structure redefin= ition, total length of the TLV becomes 7, i.e. BT(1 Byte)+Reserved(3 Byte)+= MPLS 20bit Label(3 Byte) =3D 7 Byte
>>>
>>> Yes
>>>
>>>>=C2=A0 =C2=A0 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.<= br> >>>
>>>
>>>>=C2=A0 =C2=A0 If this is correct then I feel the wording of= the above paragraph needs to be more specific, meaning in 3 Byte Label the= re will be no space for TTL, so
>>>>=C2=A0 =C2=A0 my suggestion is to make below correction: >>>>
>>>>=C2=A0 =C2=A0 BT =3D 0: The binding value is an MPLS label = carried in the format
>>>>
>>>>=C2=A0 specified in [RFC5462] where only the label value is= valid, and
>>>>=C2=A0 other fields (TC, S, and TTL) fields MUST be conside= red invalid.
>>>>=C2=A0 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 app= roach.
>>
>>
>> Sounds Good. I'm agree with you.
>>
>>>
>>>>
>>>> 2. In some cases, a stateful PCE can request the PCC to al= locate a
>>>>
>>>>=C2=A0 binding value.=C2=A0 It may do so by sending a PCUpd= message containing an
>>>>=C2=A0 empty TE-PATH-BINDING TLV, i.e., no binding value is= specified
>>>>=C2=A0 (making the length field of the TLV as 2).=C2=A0 A P= CE can also make the
>>>>=C2=A0 request PCC to allocate a binding at the time of ini= tiation by
>>>>=C2=A0 sending a PCInitiate message with an empty TE-PATH-B= INDING TLV.
>>>>
>>>>
>>>>=C2=A0 As per new Binding TLV Structure below, BT is of 1 B= yte and there will be 3 Byte Reserved.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Length=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 BT=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
>>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>=C2=A0 =C2=A0 =C2=A0 ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Binding Value (variable length)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~
>>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>
>>>>
>>>>=C2=A0 =C2=A0Now, an empty Binding TLV should have length o= f BT(1 Byte) + Reserved (3 Byte) =3D 4 Byte instead of 2 Byte.
>>>>
>>>>=C2=A0 =C2=A0So, 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=C2=A0 be your suggestion to developer who is i= mplementing this draft? Should it be taken as 4? If draft needs correction<= br> >> when will that be published?
>>>
>>>
>>> Thanks!
>>> Dhruv
>>>
>>>>
>>>> Thanks & Regards,
>>>> Mrinmoy

--000000000000f20c9305a3d93c42-- From nobody Tue Apr 21 21:33:55 2020 Return-Path: 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: In-Reply-To: From: Dhruv Dhody Date: Wed, 22 Apr 2020 09:58:39 +0530 Message-ID: To: Mrinmoy Das Cc: stefano previdi , Mahend Negi , "Siva Sivabalan (msiva)" , "Clarence Filsfils (cfilsfil)" , Jeff Tantsura , Jonathan Hardwick , "Chengli (Cheng Li)" , pce-chairs , pce@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 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 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 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 >> From nobody Tue Apr 21 22:48:27 2020 Return-Path: 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: In-Reply-To: From: Mrinmoy Das Date: Wed, 22 Apr 2020 10:58:21 +0530 Message-ID: To: Dhruv Dhody Cc: stefano previdi , Mahend Negi , "Siva Sivabalan (msiva)" , "Clarence Filsfils (cfilsfil)" , Jeff Tantsura , Jonathan Hardwick , "Chengli (Cheng Li)" , pce-chairs , pce@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a918105a3da67f9" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 05:28:38 -0000 --0000000000002a918105a3da67f9 Content-Type: text/plain; charset="UTF-8" Thanks a lot Dhruv for the clarification. Thanks & Regards, Mrinmoy On Wed, Apr 22, 2020 at 9:59 AM Dhruv Dhody wrote: > Hi Mrinmoy, > > On Wed, Apr 22, 2020 at 9:35 AM Mrinmoy Das > 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 > 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 > 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 > 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 > 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 > 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 > >> > --0000000000002a918105a3da67f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Dhruv for the clarification.

Thanks & Regards,
Mrinmoy

On Wed, Apr 22, 2020 at 9:5= 9 AM Dhruv Dhody <dhruv.ietf@gma= il.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 follow= s:
>
> |<--------20-bit---------->|<-3-bit->|<-1-bit->|
> |<-MPLS 20-bit label->|<- TC ->|<-=C2=A0 S=C2=A0 ->|=
>
> 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 -

=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 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
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Type= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Length=3D7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 BT=3D0=C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reserved=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Label=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | a= ll zeros (ignore)=C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+

Even though the length=3D7, 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 a= nd 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> wrot= e:
>> >
>> > Hi Mrinmoy,
>> >
>> > I will give authors some time to respond and confirm (and spi= n a new
>> > update). I have noted this in the PCE WG wiki [
>> > https://trac.ietf.org/trac/pce/wiki/WikiS= tart ] 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&g= t; 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.c= om> wrote:
>> >>>>
>> >>>> Respected Authors and Contributors,
>> >>>>
>> >>>> Hope you all are doing well and safe in this toug= h times of Corona Virus Outbreak.
>> >>>>
>> >>>> I like to draw your attention regarding some part= s of draft-ietf-pce-binding-label-sid-02 which I didn't able to underst= and properly.
>> >>>>
>> >>>> 1. BT =3D 0: The binding value is an MPLS label c= arried in the format
>> >>>>
>> >>>>=C2=A0 specified in [RFC5462] where only the label= value is valid, and
>> >>>>=C2=A0 other fields (TC, S, and TTL) fields MUST b= e considered invalid.
>> >>>>=C2=A0 The Length MUST be set to 7.
>> >>>>
>> >>>>
>> >>>>=C2=A0 =C2=A0 Previous versions of private draft u= ses 4 byte to store MPLS 20 Bit label and ignores TC, S & TTL fields. >> >>>
>> >>> The length in the previous version was 6, which was i= ncorrect. 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!
>> >>>
>> >>>>=C2=A0 =C2=A0 But in IETF draft after TLV structur= e redefinition, total length of the TLV becomes 7, i.e. BT(1 Byte)+Reserved= (3 Byte)+MPLS 20bit Label(3 Byte) =3D 7 Byte
>> >>>
>> >>> Yes
>> >>>
>> >>>>=C2=A0 =C2=A0 So, now MPLS 20 Bit Labelwill be sto= red in 3 byte. Is it correct?
>> >>>
>> >>> You can consider it a case of rounding up 20 bits to = 3 bytes.
>> >>>
>> >>>
>> >>>>=C2=A0 =C2=A0 If this is correct then I feel the w= ording of the above paragraph needs to be more specific, meaning in 3 Byte = Label there will be no space for TTL, so
>> >>>>=C2=A0 =C2=A0 my suggestion is to make below corre= ction:
>> >>>>
>> >>>>=C2=A0 =C2=A0 BT =3D 0: The binding value is an MP= LS label carried in the format
>> >>>>
>> >>>>=C2=A0 specified in [RFC5462] where only the label= value is valid, and
>> >>>>=C2=A0 other fields (TC, S, and TTL) fields MUST b= e considered invalid.
>> >>>>=C2=A0 The Length MUST be set to 7.
>> >>>>
>> >>>
>> >>> My suggestion would be not mention any of the other f= ields and talk
>> >>> only of 20 bits of Label. I see other SR RFCs take si= milar approach.
>> >>
>> >>
>> >> Sounds Good. I'm agree with you.
>> >>
>> >>>
>> >>>>
>> >>>> 2. In some cases, a stateful PCE can request the = PCC to allocate a
>> >>>>
>> >>>>=C2=A0 binding value.=C2=A0 It may do so by sendin= g a PCUpd message containing an
>> >>>>=C2=A0 empty TE-PATH-BINDING TLV, i.e., no binding= value is specified
>> >>>>=C2=A0 (making the length field of the TLV as 2).= =C2=A0 A PCE can also make the
>> >>>>=C2=A0 request PCC to allocate a binding at the ti= me of initiation by
>> >>>>=C2=A0 sending a PCInitiate message with an empty = TE-PATH-BINDING TLV.
>> >>>>
>> >>>>
>> >>>>=C2=A0 As per new Binding TLV Structure below, BT = is of 1 Byte and there will be 3 Byte Reserved.
>> >>>>
>> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
>> >>>>
>> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A00 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
>> >>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Length=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
>> >>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 BT=C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
>> >>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>=C2=A0 =C2=A0 =C2=A0 ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Binding Value (variable length)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~
>> >>>>=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >>>>
>> >>>>
>> >>>>=C2=A0 =C2=A0Now, an empty Binding TLV should have= length of BT(1 Byte) + Reserved (3 Byte) =3D 4 Byte instead of 2 Byte.
>> >>>>
>> >>>>=C2=A0 =C2=A0So, I do not understand how in the dr= aft 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=C2=A0 be your suggestion to developer= who is implementing this draft? Should it be taken as 4? If draft needs co= rrection
>> >> when will that be published?
>> >>>
>> >>>
>> >>> Thanks!
>> >>> Dhruv
>> >>>
>> >>>>
>> >>>> Thanks & Regards,
>> >>>> Mrinmoy
>>
--0000000000002a918105a3da67f9-- From nobody Wed Apr 22 10:08:29 2020 Return-Path: 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 A61363A0D63; Wed, 22 Apr 2020 10:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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] 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 P7i69LB0BvOI; Wed, 22 Apr 2020 10:08:18 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 580113A078A; Wed, 22 Apr 2020 10:08:18 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id 19so3171655ioz.10; Wed, 22 Apr 2020 10:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=kkSRo/T5Pe45L7O4epargVfMeEe7Pn6KKTk9jF/XC54=; b=J4hIG+V8MZD3k37hKxX5ufKX0ZI7SXPW+Hc+9SDolfx0THwPhmk8Et/rBY/ECA0xSO 1QJMC3xgNALQfIyImcWGW1h+pQM17PwUHRl5gOww8sNTXMRTjYL/Jjp7CA/nTSR6K3Zf Ayh9kgbVIYjlRmSQWs4rn02aemyx/ZI9VrjfnDYFv3rIKhhxQvwHtIIxJT6Zxqal0AWZ 8awKgSb65rV+wbF4/Y0+ZO/1LM8JzpB3nfs43TL2qIXSVBLkDPvrQgK025gxbsS5oOEB SKKRXJUDSWE9HadFSgLOIk9XWQ3iQMvdz+9ftvyxJPR2x0U9JwO5+gA9+AcuXiA/L8v9 RXGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=kkSRo/T5Pe45L7O4epargVfMeEe7Pn6KKTk9jF/XC54=; b=uQdniKPgLRSh6sFOG3XJoOnS2qTuNTY1gwZ7W8o0/XpdowOfJeXF69Vif5J97GmAc2 I4rAoolcGdFis7CliSwmE5kwJMpIxdJrP/wG59JcrQSikQaYHpZY8gCCLYLWe9neeNOS djgriK6TeMi7lGwGtlweB+BfYeeyocjjhljPMlPhsCj8LFow9Ocq4ZJ3TNxR1lN6h8Qk b6QF0DCvyc4VLqBdq1Xc5MWQnryO3i8oa7D16NqsXQUxFO6SDlMUhTYMqfOomvUEc1hw i7mdc9AGacXHbVKBavEfHjtSQwjfhK7VrkP1P/DEqKuVY8V3QpQH4gvBBsoDqzeUkm0i g7Rg== X-Gm-Message-State: AGi0PuZ2uSn1iPsiYHzQIa12p0FzOthIFQYu70mhZP4rB/0eyE7r++5u B6DXIE4d5Ae8Z6P46JTQSJIIBxyGFx/NiTWRtd530IAyH7I= X-Google-Smtp-Source: APiQypJWJnMap9SECxF2V+kgo3GvXQl7pQGSNvrnefqXfQUmQ0Hpul3XCYPWgPC77qu0njKrpHRJ1oQ950YKFUYCU0U= X-Received: by 2002:a6b:8b05:: with SMTP id n5mr26728478iod.68.1587575297033; Wed, 22 Apr 2020 10:08:17 -0700 (PDT) MIME-Version: 1.0 From: Dhruv Dhody Date: Wed, 22 Apr 2020 22:37:41 +0530 Message-ID: To: pce@ietf.org Cc: pce-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Pce] Early code point allocation for draft-ietf-pce-association-policy X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:08:20 -0000 Hi WG, We have received a request from the authors of draft-ietf-pce-association-policy for an early code point allocation. 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 the reasons. If the chairs hear no objections by next Friday, May 1st, we will kick off the early allocation request. Best regards and stay safe, Dhruv & Julien From nobody Thu Apr 23 23:44:48 2020 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BB93A0D43; Thu, 23 Apr 2020 23:44:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: pce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: pce@ietf.org Message-ID: <158771068458.25957.14859203500561264052@ietfa.amsl.com> Date: Thu, 23 Apr 2020 23:44:44 -0700 Archived-At: Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-13.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.29 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 06:44:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks Authors : Young Lee Haomian Zheng Oscar Gonzalez de Dios Victor Lopez Zafar Ali Filename : draft-ietf-pce-pcep-stateful-pce-gmpls-13.txt Pages : 19 Date : 2020-04-23 Abstract: The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-13 https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/