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

[Mirja Kuehlewind <[e-mail]>]

Hi Dhruv,

Sorry for my late reply. So your reply actually concerns me a bit. Initially you said you've put it in object because there was no expectation that is may be needed by other objects. Now you have a second object and you defined it again object-specifically because you say it’s too much overhead to define a generic mechanisms for just one more. Will you say the same thing again with the next object that needs fragmentation? Maybe it’s the right time now to add this more generically to common header. I mean it should be a very short, straight-forward draft. What’s the argument for not just doing it now?

mirja



> On 4. Apr 2019, at 20:07, Dhruv Dhody <[e-mail]> wrote:
> 
> 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
> 
>