Hi Adrian, I have posted -10 that has this change incorporated.
Thanks! Dhruv On Fri, Feb 8, 2019 at 6:47 PM Adrian Farrel <[email protected]> wrote: > > Looks good to me. > > Thanks! > > I'll wait to see -09 posted. > > A > > -----Original Message----- > From: Dhruv Dhody <[email protected]> > Sent: 07 February 2019 04:25 > To: [email protected]; [email protected] > Cc: [email protected]; 'Dhruv Dhody' <[email protected]> > 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 > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
