Re: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08

[Dhruv Dhody <[e-mail]>]

Hi Adrian,

I have posted -10 that has this change incorporated.

Thanks!
Dhruv

On Fri, Feb 8, 2019 at 6:47 PM Adrian Farrel <[e-mail]> wrote:
>
> Looks good to me.
>
> Thanks!
>
> I'll wait to see -09 posted.
>
> A
>
> -----Original Message-----
> From: Dhruv Dhody <[e-mail]>
> Sent: 07 February 2019 04:25
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; 'Dhruv Dhody' <[e-mail]>
> Subject: RE: [Pce] Shepherd review of draft-ietf-pce-stateful-pce-p2mp-08
>
> Hi Adrian,
>
> > >> 6.1
> > >>
> > >> The following bit of RBNF echoes something we did in the base
> > >> stateful draft and which has caused confusion / errata to be raised
> > >> because it looks so wrong (actual and intended all mixed up).  Do we
> > >> absolutely need to do this just to have something that looks like the
> > >> base draft (which looks weird)?  If so, please give an explicit
> > >> explanation in the text, otherwise we will just get the errata raised
> > again.
> > >>
> > >>    <state-report> ::= [<SRP>]
> > >>                        <LSP>
> > >>                        <end-point-intended-path-pair-list>
> > >>                        [<actual-attribute-list>
> > >>                        <end-point-actual-path-pair-list>]
> > >>                        <intended-attribute-list>
> > >
> > > [[Dhruv Dhody]] So far we have tried to maintain compatibility between
> > > P2P
> > and P2MP
> > > versions of the PCEP messages. Additionally we state -
> > >
> > >   Note that the compatibility with the [RFC8231] definition of <state-
> > >   report> is preserved.  At least one instance of <END-POINTS> MUST be
> > >   present in this message for P2MP LSP.
> > >
> > > I have also added this now -
> > >
> > >   Note that the ordering of <end-point-intended-path-pair-list>,
> > >   <actual-attribute-list>, <end-point-actual-path-pair-list>, and
> > >   <intended-attribute-list> is done to retain compatibility with state
> > >   reports for the P2P LSPs as per [RFC8231].
> >
> > Your suggested text is good.
> >
> > Just looking at the errata for RFC 8231
> >
> > https://www.rfc-editor.org/errata/eid5492 is still "reported" and shows an
> > inconsistency between the text "intended-attribute-list is optional" and
> > the RBNF...
> > <path>::= <intended-path>
> >                 [<actual-attribute-list><actual-path>]
> >                 <intended-attribute-list> That looks like a problem to me.
> > But I'm not sure what the correct resolution is.
> > I don't see any discussion on the list.
> > If we can get that resolved, it could help us be clear here.
> > Depending on the resolution, we might need a change to this draft.
> >
> [[Dhruv Dhody]] I responded with a proposal to handle the errata.
> And the corresponding change is made in this I-D as well.
>
> > > -
> > >
> > > Shouldn't the description of the N bit should also mention PCReq and
> > PCRep?
> > >
> > [[Dhruv Dhody]] I have added this text -
> >
> >    The N flag is used in a PCRpt, PCUpd, or PCInitiate message to
> >    indicate a P2MP TE LSP.  In case of PCReq and PCRep, the N flag in
> >    the RP (Request Parameters) object ([RFC8231]) is used to indicate
> >    P2MP path computation.  The N flag in the LSP object MUST also be set
> >    if the N flag in the RP object is set.  If there is mis-match
> >    between the N flag in the RP and the LSP object in PCReq or PCRep
> >    message, the PCEP speaker MUST generate an error with error-type 10
> >    ("Reception of an invalid object") and error-value TBD1 (to be
> >    allocated by IANA) ("Mis-match of N flag in RP and LSP object").
>
> [[Dhruv Dhody]] It was pointed out to me that this is applicable for all
> flags that are common between RP and LSP objects, so better way forward
> could be to refer to RP object only when both RP and LSP object exist in the
> PCEP messages.
>
> Thus I have added -
>
>    The flags defined in this section (N, F, E flags) are used in PCRpt,
>    PCUpd, or PCInitiate message.  In case of PCReq and PCRep message,
>    these flags have no meaning and thus MUST be ignored.  The
>    corresponding flags in the RP (Request Parameters) object are used as
>    described in [RFC8231].
>
> Let me know if this is fine with you?
>
> Working Copy -
> https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-p
> ce-stateful-pce-p2mp-10.txt
> Diff -
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-pce-p2mp-09&url2
> =https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-
> pce-stateful-pce-p2mp-10.txt
>
> Regards,
> Dhruv
>