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

Hi Mirja, 

The fragmentation is for the PCEP message and not each object. RFC6006 (and RFC8306) implemented this with a flag in the RP object (which is a MUST object in two messages that are susceptible to fragmentation). In this document we add flag in the LSP object (which is a MUST object in all the 3 messages that are susceptible to fragmentation).  

So, PCEP has 13 messages, of which 5 are susceptible to fragmentation, and this is handled by flag in 2 objects. Even if we came up with new messages (and there are none proposed as of now), I don’t see us adding this flag in more objects anytime in the near future.

I will wait for shepherd/AD guidance on this. 

Thanks! 
Dhruv

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Mirja Kuehlewind
> Sent: 11 April 2019 17:44
> To: Dhruv Dhody <dhruv.ietf@gmail.com>
> Cc: draft-ietf-pce-stateful-pce-p2mp@ietf.org; pce@ietf.org; The IESG
> <iesg@ietf.org>; pce-chairs@ietf.org
> Subject: Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-
> stateful-pce-p2mp-12: (with COMMENT)
> 
> 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 <dhruv.ietf@gmail.com> wrote:
> >
> > Hi Mirja,
> >
> > On Thu, Apr 4, 2019 at 10:14 PM Mirja Kühlewind via Datatracker
> > <noreply@ietf.org> 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
> >
> >
> 
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce