Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

["Adrian Farrel" <[e-mail]>]

Jon, thanks.

I scanned your mail and it all looks good.

Will try to have a read of the draft as well, but time is a bit full at the
moment.

A

> -----Original Message-----
> From: Jonathan Hardwick [mailto:[e-mail]]
> Sent: 29 June 2018 18:24
> To: [e-mail]
> Cc: 'Julien Meuric'; [e-mail]
> Subject: RE: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
> 
> Hi Adrian
> 
> Sorry for the delay.  Thanks again for the carefully considered feedback.
I've
> trimmed out points below where I agreed and no comment was necessary.
> Please find answers and clarifications below.
> 
> ---
> 
> Section 3
> 
>    o  An ordered set of IP address(es) representing network nodes/links:
>       In this case, the PCC needs to convert the IP address(es) into the
>       corresponding MPLS labels by consulting its Traffic Engineering
>       Database (TED).
> 
> But I am surprised that this work is offloaded to the PCC since the PCE has
all the
> information to do this task. Why did the WG want to add this option?
> 
> And then...
> 
>    o  An ordered set of SID(s)
> 
> s/SID(s)/SIDs/
> 
> This list of SIDs would need to be converted to labels by the PCC by applying
the
> SRGB offsets. Again, why make the PCC do this?
> 
> And finally...
> 
>    o  An ordered set of both MPLS label(s) and IP address(es): In this
>       case, the PCC needs to convert the IP address(es) into the
>       corresponding SID(s) by consulting its TED.
> 
> This mixture of the previous two cases seems to compound the level of
> complexity. Can't the PCE just know it is making an SR path and supply a list
of
> MPLS labels corresponding to the SIDs?
> 
> [Jon] Having consulted the authors, the reason is that different PCE
> implementations have different approaches, which can all be accommodated
> fairly straightforwardly in the draft's format. Having said that, it seems
harsh to
> force the PCC into having to provide an NAI-resolution service for the PCE.
> Therefore, I have added a capability flag so that the PCC can indicate that it
> cannot / will not do NAI resolution. [/Jon]
> 
> ---
> 
> 5.1.2 ----> 6
> 
>    If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
>    PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is
>    absent, then the PCEP speaker MUST send a PCErr message with Error-
>    Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
>    assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
>    close the PCEP session.
> 
> Suppose an implementation receives an Open with PST=1 but doesn't
> understand (or doesn't support) that value. Is it still required to perform
this
> check? Hopefully not.
> 
> [Jon] Nope.  Have changed to
> 
>    If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
>    PST list containing PST=1, and supports that path setup type, then it
>    checks for the presence of the SR-PCE-CAPABILITY sub-TLV.  If that sub-TLV
is
>    absent, then the PCEP speaker MUST send a PCErr message with Error-
>    Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
>    assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
>    close the PCEP session.
> [/Jon]
> 
> ---
> 
> 5.3.1 (under Length) has
> 
>       As mentioned earlier, an SR-ERO
>       subobject MUST have at least SID or NAI.
> 
> This is good and does tie in with what is written in earlier sections.
> 
> However, 5.3.1 starts with
> 
>    An SR-ERO subobject consists of a 32-bit header followed by the SID
>    and the NAI associated with the SID.  The SID is a 32-bit number.
>    The size of the NAI depends on its respective type, as described in
>    the following sections.
> 
> That makes it sound like they are both mandatory, and the figure doesn't help.
> 
> A little rewording would go a long way, and you could add "(optional)"
> to the figure.
> 
> [Jon] I have modified the preamble to the following, and have added the word
> "optional" to the diagram.
> 
>    An SR-ERO subobject consists of a 32-bit header followed by the SID
>    and/or the NAI associated with the SID.  The SID is a 32-bit number.
>    The size of the NAI depends on its respective type, as described in
>    the following sections.  At least one of the SID and the NAI MUST be
>    included in the SR-ERO subobject, and both MAY be included.
> [/Jon]
> 
> ---
> 
> 5.3.1
> 
>    SID Type (ST)  indicates the type of information associated with the
>       SID contained in the object body.  When ST value is 0, SID MUST
>       NOT be null and NAI MUST be null.
> 
> Does "null" mean "all zeros" or "absent"?
> 
> See also the definition of the S and F flags.
> 
> [Jon] It means "absent" (see definition of Length field).  But this is not
particularly
> clear, so I have changed all instances of "null" to "absent". [/Jon]
> 
> ---
> 
> 5.3.1
> 
>       Other ST values are described
>       later in this document.
> 
> It would be friendly to provide a list somewhere.
> Do you need a registry?
> 
> [Jon] I have added a list and created a registry. [/Jon]
> 
> ---
> 
> 5.3.1
> 
>    Flags  is used to carry any additional information pertaining to SID.
> 
> You need to say how to set the unused bits.
> Do you need a registry?
> 
> [Jon] I have created a registry. [/Jon]
> 
> ---
> 
> 5.3.3
> 
>    If a PCC receives a stack of SR-ERO subobjects, and the number of
>    stack exceeds the maximum number of SIDs that the PCC can impose on
>    the packet, it MAY send a PCErr message with Error-Type = 10
>    ("Reception of an invalid object") and Error-Value = 3 ("Unsupported
>    number of Segment ERO subobjects").
> 
> And if it doesn't send the PCErr, what should it do?
> 
> [Jon] I think this has to be a MUST, not a MAY. [/Jon]
> 
> ---
> 
> 5.3.3
> 
>    When a PCEP speaker detects that all subobjects of ERO are not
>    identical, and if it does not handle such ERO, it MUST send a PCErr
>    message with Error-Type = 10 ("Reception of an invalid object") and
>    Error-Value = 5 ("Non-identical ERO subobjects").
> 
> "Not identical" could have so many meanings here!
> - Presumably you don't mean that all SIDs have the same value
> - You might be referring to all flags
> - You might be referring to just the M and C flags
> - You might mean that the ERO must contain all SR-ERO subobjects or
>   no SR-ERO subobjects
> 
> Please clarify and possibly rename the error value.
> 
> [Jon] It means the last of those. Renamed the error to "ERO mixes SR-ERO
> subobjects with other subobject types".
> It also means you can't mix labels, SID index values and pure NAI.  I've added
that
> check too.[/Jon]
> 
> (See also 5.4.1).
> 
> [Jon] "RRO mixes SR-RRO subobjects with other subobject types" [/Jon]
> 
> ---
> 
> 5.3.3
> 
>    When a PCEP speaker receives an SR-ERO subobject in which ST is 0,
>    SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be
>    0, F-flag MUST be 1, and the Length MUST be 8).  Otherwise, it MUST
>    consider the entire ERO object invalid and send a PCErr message with
>    Error-Type = 10 ("Reception of an invalid object") and Error-Value =
>    11 ("Malformed object").  The PCEP speaker MAY include the malformed
>    SR-ERO object in the PCErr message as well.
> 
> This text is good.
> But it makes me think: what about the ST values 1 through 5 if the NAI is
absent?
> 
> [Jon] I've generally tightened this area up and have hopefully covered all
invalid
> cases! [/Jon]
> 
> 
> > -----Original Message-----
> > From: Pce [mailto:[e-mail]] On Behalf Of Julien Meuric
> > Sent: 15 January 2018 09:38
> > To: [e-mail]
> > Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
> >
> > Dear PCE WG,
> >
> > Best wishes for this new year, full of interoperable specifications.
> > Let us begin by resuming our work in progress.
> >
> > This message starts a 2-week WG last call for
> > draft-ietf-pce-segment-routing-11. Please send your feedback on the
> > I-D to the PCE mailing list by Monday January 29.
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce