Subject: [Pce] AD action please : [Technical Errata Reported] RFC5521 (3750)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 23 Oct 2013 14:19:38 +0100

Hi Stewart,

Could you please action this Errata Report as follows:

1. Update the new text to read
    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.

2. Mark the report as Verified.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian
> Farrel
> Sent: 16 October 2013 15:56
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Pce] [Technical Errata Reported] RFC5521 (3750)
> 
> 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-masked]>
> >
> > 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-masked]
> https://www.ietf.org/mailman/listinfo/pce