Subject: [Pce] 答复: [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

From: <[email-masked]>
Date: Mon, 2 Dec 2019 09:32:46 +0800 (CST)

Hi Dhruv and Adrian,

Thanks a lot for reviewing my draft and all your comments and suggestions are very appreciated!

I agree with you and I will update the draft and fix it as follows:

a, remove the repeat format of the existing LSP object.

b, remove the ues bit 0 to indicate the LSP-Extended-Flags TLV and other I-Ds could define this TLV as mandatory when they need to use it.

c, remove the description of update to RFC 8231 and just define it as an extension for PCEP.

d, add the description of TLV processing and backwards compatibility.

e, think about RFC5420

f, ask IANA for a new TLV type and a new registry to track the bits in the TLV.

g, define a value for the Length field in the LSP-Extended-Flags TLV.

But for the last issue, I am not sure if the length of 32 bits is good or not. If 32 bits is enough for the extensions of other I-Ds?

What is your suggestion?

Best Regards,

Quan

原始邮件

发件人：DhruvDhody <[email-masked]>
收件人：Farrel Adrian <[email-masked]>;
抄送人：熊泉00091065;Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>;Loa Andersson <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年11月28日 21:26
主 题 ：Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi Quan, Adrian, 

As a WG contributor, I agree with Adrian that just the presence of this TLV is good enough to require the processing of extended flags. Other I-Ds that define extended flags can make the TLV as mandatory for that feature. 

Also if we go this route, we do not need to make this I-D as an update to RFC 8231, it could be just be an extension and business as usual.  

Thanks! 

Dhruv

On Thu, Nov 28, 2019 at 5:48 PM Adrian Farrel <[email-masked]> wrote:

Hi Quan,

Thanks for picking up this work. You are right that we need a solution.

A couple of points about your draft…

I don’t think it is necessary or advisable to repeat the format of the existing PLSP-ID object, or to list the currently-assigned bits and meanings. Doing so creates potential conflict between two different normative documents.

I believe that processing the TLVs in the object is mandatory, so I do not believe that you need to use a bit (bit 0) in the existing flags field to indicate that the LSP-Extended-Flags TLV is present. It will be found if it is there. (I don’t feel strongly about this, and other may find the indication to be useful).

You have not given a value for the Length field in the LSP-Extended-Flags TLV. Is this because you intend that the TLV should scale if more than 32 bits are needed? If so, you should give some clues about processing. If not, you should just set the value.

You need to describe backwards compatibility. How will legacy implementations process this TLV and what will be the effect on the setting of any bits?

I think that in Singapore someone suggested comparing with the work done for RSVP-TE LSP Attributes. See RFC 5420. In that work we defined two TLVs to cover attributes that must be processed, and attributes that may be ignored. I’m not sure you need this, but think about it.

I think section 6.1 is broken. You don’t need two flags, do you?

You need to ask IANA for a new TLV type for your new TLV.

You need to ask IANA for a new registry to track the bits in your new TLV.

Cheers,

Adrian

From: Pce <[email-masked]> On Behalf Of [email-masked]
Sent: 28 November 2019 03:44
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi all,

I  have summitted the draft which proposes a new LSP-EXTENDED-FLAG TLV for LSP object to extend the length of the flag field.

Could you please give me some suggestions about the format?

Thanks,

Quan

原始邮件

发件人：[email-masked] <[email-masked]>

收件人：熊泉00091065;

日 期 ：2019年11月27日 15:54

主 题 ：New Version Notification for draft-xiong-pce-lsp-flag-00.txt

A new version of I-D, draft-xiong-pce-lsp-flag-00.txt
has been successfully submitted by Quan Xiong and posted to the
IETF repository.

Name:        draft-xiong-pce-lsp-flag
Revision:    00
Title:        LSP Object Flag field of Stateful PCE
Document date:    2019-11-26
Group:        Individual Submission
Pages:        6
URL:            https://www.ietf.org/internet-drafts/draft-xiong-pce-lsp-flag-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xiong-pce-lsp-flag/
Htmlized:       https://tools.ietf.org/html/draft-xiong-pce-lsp-flag-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag

Abstract:
   RFC8231 describes a set of extensions to PCEP to enable stateful
   control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP.
   One of the extensions is the LSP object which includes a Flag field
   and the length is 12 bits.  However, 11 bits of the Flag field has
   been assigned in RFC8231, RFC8281 and RFC8623 respectively.

   This document updates RFC8231 by defining a new LSP-EXTENDED-FLAG TLV
   for LSP object to extend the length of the flag.

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.

The IETF Secretariat

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 2 Dec 2019 10:57:46 +0530

Hi Quan,

> But for the last issue, I am not sure if the length of 32 bits is good or not. If 32 bits is enough for the extensions of other I-Ds?

I can think of one case: PCE capability flags in [1], where we defined
it as an array of units of 32-bit flags   numbered from the most
significant as bit zero, where  each bit represents one flag. In the
corresponding IANA registry [2], we maintained it as 32 bits for now,
which can be easily updated by a future document when needed.

As a WG contributor, I think it is better to be future proof even
though 32 bits seems good enough at the present.

Thanks!
Dhruv

[1] https://tools.ietf.org/html/rfc5088#section-4.5
[2] https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-14

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Dec 2019 13:21:50 -0000

Hi,

I wouldn't object to any solution.
- What Dhruv suggests
- Just 32 bits and define a new TLV if more bits are ever needed

Best,
Adrian

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 02 December 2019 05:28
To: [email-masked]
Cc: Farrel Adrian <[email-masked]>; Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi Quan,

Thanks!
Dhruv

---

From: <[email-masked]>
Date: Tue, 3 Dec 2019 14:49:05 +0800 (CST)

Hi Adrian and Dhruv,

Thanks for your suggestion!  I will consider the option as defined in RFC5088.

I will update the draft as we discussed as soon as possible.

More comments and suggestions are welcome!

Best Regards,

Quan

原始邮件

发件人：AdrianFarrel <[email-masked]>
收件人：'Dhruv Dhody' <[email-masked]>;熊泉00091065;
抄送人：'Stone, Andrew (Nokia - CA/Ottawa)' <[email-masked]>;'Loa Andersson' <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年12月02日 21:22
主 题 ：RE: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi,

Best,
Adrian

-----Original Message-----
From: Dhruv Dhody <[email-masked]> 
Sent: 02 December 2019 05:28
To: [email-masked]
Cc: Farrel Adrian <[email-masked]>; Stone, Andrew (Nokia - CA/Ottawa) <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]
Subject: Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

Hi Quan,

Thanks!
Dhruv