Hi Dana, Rather than discuss this through the Errata System, I would like to have an email exchange on the PCE list.
You reported (http://www.rfc-editor.org/errata_search.php?rfc=5521&eid=3750) ... > -------------------------------------- > Type: Technical > Reported by: Dana Kutenicsova <[email protected]> > > Section: 3.1.1 > > Original Text > ------------- > The format and definition of PKS when it appears as an XRO subobject > are as defined in [RFC5520], except for the definition of the L bit. > The L bit of the PKS subobject in the XRO MUST be ignored. > > Corrected Text > -------------- > > > Notes > ----- > The section does not describe the value of the X bit in PKS subobjects. In RSVP-TE [RFC4874] the L-bit is present in the XRO subobjects and in the EXRS. In PCEP the L-bit applies only in the EXRS. In the XRO subobjects it is annoyingly called the X-bit. In RFC 4874 the XRO L-bit is described as 0 indicates that the attribute specified MUST be excluded. 1 indicates that the attribute specified SHOULD be avoided. In RFC 5521 the XRO X-bit is described as The X-bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the resource. That is pretty much the same semantic even though the name is changed. RFC 5520 describes the PKS and its use in an ERO. Thus the L-bit follows from the ERO subobject definition in RFC 5440 (section 7.9) which points to RSVP-TE for the definition of subobjects. In RFC 3209 we find (section 4.3.3)... The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route. ...so it is no surprise to see that RFC 5520 says... The L bit SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route. Now, in section 3.1.1 of RFC 5221, as you quote, we have... The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. The L bit of the PKS subobject in the XRO MUST be ignored. So, I think there are two issues: 1. The text should say that the L-bit is replaced by the X-bit which is used as described in Section 2.1.1. 2. The last sentence should be struck out. That would mean: OLD The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. The L bit of the PKS subobject in the XRO MUST be ignored. NEW The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except that the L bit described in [RFC5220] is replaced with the X bit as discussed in Section 2.1.1 of this document. END If you agree with this resolution we will consult Stewart about verifying the Erratum. (We need Stewart to do this as I am a co-author on the RFC.) Thanks, Adrian _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
