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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi,

Thanks Dhruv for the clarification. As the working group supports this approach, I support also.

In the future, we can consider Mirja's suggestion if we see this becoming more popular.

Thanks everyone-
Deborah


-----Original Message-----
From: iesg <[e-mail]> On Behalf Of Dhruv Dhody
Sent: Thursday, April 11, 2019 10:22 AM
To: Mirja Kuehlewind <[e-mail]>; Dhruv Dhody <[e-mail]>
Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>; [e-mail]
Subject: 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:[e-mail]] On Behalf Of Mirja Kuehlewind
> Sent: 11 April 2019 17:44
> To: Dhruv Dhody <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG 
> <[e-mail]>; [e-mail]
> 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 <[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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_i
> >> esg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQic
> >> vjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=hNGDwK3faYOrfp
> >> qcsR1MoICHbHOb0a9IipPfkUs-Dow&s=BjiCbGBk7qtk2Sq4GNbe4GnaEhxtJo9sHUf
> >> hjzkkTgQ&e= for more information about IESG DISCUSS and COMMENT 
> >> positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ie
> >> tf.org_doc_draft-2Dietf-2Dpce-2Dstateful-2Dpce-2Dp2mp_&d=DwIGaQ&c=L
> >> FYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0
> >> &m=hNGDwK3faYOrfpqcsR1MoICHbHOb0a9IipPfkUs-Dow&s=OkXMnQaRNLjdOcsIja
> >> ue3yEY74mas2cC_3QSF-PJp2M&e=
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> --
> >> -
> >> 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
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_pce&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTb
> N3QpjYHxsObxmPKRhiF3FnmoI0&m=hNGDwK3faYOrfpqcsR1MoICHbHOb0a9IipPfkUs-D
> ow&s=LI5tCjxkFGb8hONlR137dibI8MwAfSYWuxdDhPPZ9Gs&e=