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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 04 Apr 2019 09:44:18 -0700

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...

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 4 Apr 2019 23:37:35 +0530

Hi Mirja,

> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 11 Apr 2019 14:14:17 +0200

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 <[email-masked]> wrote:
> 
> Hi Mirja,
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 11 Apr 2019 14:21:30 +0000

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:[email-masked]] On Behalf Of Mirja Kuehlewind
> Sent: 11 April 2019 17:44
> To: Dhruv Dhody <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> 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
> 
> 
> 
> >> 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
> >> 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...
> >>
> >>
> >
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 30 Apr 2019 18:41:29 +0000

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 <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Thursday, April 11, 2019 10:22 AM
To: Mirja Kuehlewind <[email-masked]>; Dhruv Dhody <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: RE: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-stateful-pce-p2mp-12: (with COMMENT)

Hi Mirja, 

Thanks! 
Dhruv

> 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
> 
> 
> 
> >> 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.
> >>
> >>
> >> 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:
> >> -------------------------------------------------------------------
> >> --
> >> -
> >>
> >> 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
> > The need for fragmentation was found when the support for P2MP TE 
> > was introduced in RFC6006. At that time only two PCEP message were 
> > 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
> >
> >
> 
> 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=