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:[email protected]] > Sent: 29 June 2018 18:24 > To: [email protected] > Cc: 'Julien Meuric'; [email protected] > 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:[email protected]] On Behalf Of Julien Meuric > > Sent: 15 January 2018 09:38 > > To: [email protected] > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
