[Pce] 答复: cursory review of draft-xiong-pce-lsp-flag

[[e-mail]]

Hi Dhruv,







Thanks for your quick reply and suggestion!


The  LSP-EXTENDED-FLAG TLV is not mandatory and I will modify and move the error handing to the draft-peng-pce-entropy-label which needs to use the flag.  I will update the drafts as you suggest as soon as possible!






Thanks,


Quan







原始邮件



发件人：DhruvDhody <[e-mail]>
收件人：熊泉00091065;
抄送人：Loa Andersson <[e-mail]>;[e-mail] <[e-mail]>;pce-chairs <[e-mail]>;[e-mail] <[e-mail]>;
日 期 ：2020年07月30日 13:47
主 题 ：Re: cursory review of draft-xiong-pce-lsp-flag


Hi Quan,

On Thu, Jul 30, 2020 at 8:00 AM <[e-mail]> wrote:
>
>
> Hi Dhruv and Loa,
>
>
> Thanks for your review and detailed discussion!
>
> For the IANA text, I will update that as you suggest.
>
>
> In my view, we need to clarify the LSP-EXTENDED-FLAG TLV is mandatory or not firstly. Then consider the error handling.
>
> There are two cases.
>
> First case, for the implementations which just use the Flag field of  LSP Object from  bit 1 to bit 11, it has no need to carry LSP-EXTENDED-FLAG TLV and not mandatory.
>
> Second case, for the implementations which will use the flag of LSP-EXTENDED-FLAG TLV, It is mandatory.  When LSP-EXTENDED-FLAG TLV is missing, the error handling should be taken into consideration.
>

>From the point of view of this I-D there are no flags defined in the
LSP-EXTENDED-FLAG TLV yet.

Also, Loa rightly pointed out that any text would be incomplete as an
implementation that just receives an LSP object without the
LSP-EXTENDED-FLAG TLV would not know if it is the first "valid" or the
second "error" case in your text above just by the fact that the TLV
is missing. The error would be noticed in conjunction with some other
encoding required by the extension.

So my suggestion would be to move the error handling to the first
document that defines the flag in LSP-EXTENDED-FLAG TLV. We have
documents that need to use it right away so this should not be a
problem, just some coordination.

Thanks!
Dhruv

>
> I suggest to make clarification in the draft about the implementations
>
> or use the bit 0 of Flag field in LSP Object to indicate the existing of the LSP-EXTENDED-FLAG TLV?
>
> Could you tell me what is your suggestion?
>
>
> Thanks,
>
> Quan
>
>
>
>
> 原始邮件
> 发件人：DhruvDhody <[e-mail]>
> 收件人：Loa Andersson <[e-mail]>;
> 抄送人：[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> 日 期 ：2020年07月29日 19:15
> 主 题 ：Re: cursory review of draft-xiong-pce-lsp-flag
> Hi Loa,
>
> On Wed, Jul 29, 2020 at 4:13 PM Loa Andersson <[e-mail]> wrote:
> >
> > Dhruv,
> >
> > Inline please.
> >
> > On 29/07/2020 17:01, Dhruv Dhody wrote:
> > > Hi Loa,
> > >
> > >> Comment:
> > >>
> > >> 5.2.  PCEP-Error Object
> > >>
> > >>      IANA is requested to register the following error types and error
> > >>      values within the "PCEP-ERROR Object Error Types and Values"
> > >>      subregistry of the "Path Computation Element Protocol (PCEP) Numbers"
> > >>      registry:
> > >>
> > >>             +--------------+-------------------------------------+
> > >>             |  Error-Type  |  Meaning                            |
> > >>             +--------------+-------------------------------------+
> > >>             |  6           |  Mandatory Object missing           |
> > >>             |              |  Error-value                        |
> > >>             |              | TBD2: LSP-EXTENDED-FLAG TLV missing |
> > >>             +--------------+-------------------------------------+
> > >>
> > >>                                     Table 2
> > >>
> > >> Both the RTG DIR rules and IANA rules strongly advice against putting
> > >> fixed numeric  values into allocation from existing registries. The
> > >> reason is obvious, in the time from you put the value in your document
> > >> until iet is ready for IESG review (which includes IANA review) someone
> > >> else might have been assigned tht value. This has happened and have
> > >> caused serious problems.
> > >>
> > >> 6 in table 2 hould be replaced with TBA (to be assigned).
> > >>
> > >> Note: If you really want the value 6, we should go for an early
> > >> allocation as soon as we have the wg document.
> > >>
> > >
> > > [Dhruv] The value 6 is for Error-Type already allocated by RFC 5440.
> > > This I-D is asking for a new Error-Value which is  TBD2. A reference
> > > column in the IANA table would have helped here.
> >
> > hmmmm - okey, but no, we are asking IANA to register a new error-value,
> > but not a new error type. The text says:
> >
> >    "IANA is requested to register the following error types and error
> >      values ..."
> >
>
> This text is incorrect then and should be fixed.
>
> > But then the table is very unclear, at a minimum it should look
> > something like this:
> >
> >    +-------------+----------------------------+-------------------------+
> >    |  Error-Type | Meaning                    | Error-value             |
> >    +-------------+----------------------------+-------------------------+
> >    |  6          | Mandatory Object missing   | 0: Unassigned           |
> >    |             |                            | 1-15 Assigned           |
> >    |             |                            | TBD2: LSP-EXTENDED-FLAG |
> >    |             |                            |       TLV missing       |
> >    +-------------+----------------------------+-------------------------+
> >
> >                                       Table 2
> >
> Yes. I suggest Quan to look at -
> https://www.rfc-editor.org/rfc/rfc8800.html#section-7.5 as a good
> reference from a recent published RFC.
>
> >
> > >
> > >> Question:
> > >>
> > >> In section 4 you say:
> > >>
> > >>      The LSP-EXTENDED-FLAG TLV MUST be defined as mandatory when a router
> > >>      supporting the LSP Object and needs to use the extended flag field.
> > >>
> > >> I don't really parse; are you saying that if it is present it should be
> > >> treated as mandatory?
> > >>
> > >> If that is what you are saying, what does it change?
> > >>
> > >
> > > [Dhruv]: I read it as a requirement for a future extension that would
> > > define a flag in the LSP-EXTENDED-FLAG TLV.
> > >
> > > If that is true, I would suggest not using normative MUST. How about -
> > >
> > > A future extension that defines a flag in the LSP-EXTENDED-FLAG TLV
> > > could mark this TLV as mandatory to be carried the LSP Object.
> >
> > I have been reading a bit more, but this is still unclear to me, if I
> > understand it will still be valid to send without the extended TLV
> > (if you don't need the flags).
>
> Yes! Maybe we should not use the word "mandatory" then!
>
> As it is "mandatory" in the context of using a new feature defined in
> a future extension -- so to use the new feature, an implementation
> MUST include the LSP-EXTENDED-FLAG TLV and MUST set a particular flag.
> The so-called "mandatory" would be only in the scope of the protocol
> extension and not required when the feature is not used.
>
> > How are you deciding if the extended TLV
> > missing?
> >
>
> This could be because of the presence of some other object/TLVs needed
> by the same extension but without the LSP-EXTENDED-FLAG TLV in the LSP
> object.
> Perhaps the right thing to do would be to move the error handling to
> the first document that uses the LSP-EXTENDED-FLAG TLV instead of this
> document.
>
> Thanks!
> Dhruv
>
> >
> > /Loa
> > >
> > > Thanks!
> > > Dhruv
> > >
> > >> /Loa
> > >>
> > >>
> > >> --
> > >>
> > >> Loa Andersson                        email: [e-mail]
> > >> Senior MPLS Expert                          [e-mail]
> > >> Bronze Dragon Consulting             phone: [phone]
> >
> > --
> >
> > Loa Andersson                        email: [e-mail]
> > Senior MPLS Expert                          [e-mail]
> > Bronze Dragon Consulting             phone: [phone]
>
>