Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT)

[Dhruv Dhody <[e-mail]>]

Hi Mirja,

On Thu, Apr 4, 2019 at 10:14 PM Mirja Kühlewind via Datatracker
<[e-mail]> wrote:
>
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-pce-stateful-pce-p2mp-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Just a quick clarification question on fragmentation: I'm wondering if it is
> really necessary to define a fragmentation mechanism/bit for each object
> separately (e.g also RFC8306) or if it would be more appropriate to allocate
> one bit in the common header? Just asking as I'm really not an expert here...
>
>

The need for fragmentation was found when the support for P2MP TE was
introduced in RFC6006. At that time only two PCEP message were
susceptible to fragmentation (PCReq & PCRep) and the choice was made
to add a flag in a RP object. The choice made at that time was that
the other messages should not be fragmented.

Later PCEP added more messages to support stateful operation. And with
this I-D we extend support to P2MP LSP where fragmentation handling
was required (we added the flag in the LSP object).

You are correct! We could have used the PCEP common message header and
said that the flag is applicable for the subset of messages. But the
design choice here was to keep consistent with technique already in
place. Fragmentation flag in 2 objects isn't all that bad.

Thanks for your review!
Dhruv