Hi Andrew, On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa) <andrew.st...@nokia.com> wrote: > > Hi Dhruv, > > Thanks for the reply and feedback. > > Could an implementation of PCE not simply just return error during that > situation? In diversity if too many LSPs grouped together and PCE > computationally can't support it, it returns a PCERR. So I would reason that > if bidirectionally associated and notify PCCs is necessary, but was > configured between SR and RSVP, that's also an error due to the (current) > unsupported feature set. I see this as trying to protect against day-0 > misconfig by changing the wire encoding within the protocol (which I'm not > necessarily against..). While I have doubt if it's a valid use case or > requirement in a production deployment, and it may have been acknowledged > before, but this essentially blocks associating SR LSP with RSVP LSP > bidirectionally for PCE to compute. > > Since the overall workflow doesn't change by this new type def, and if > SR<->RSVP associated is not reasonable requirement, and If consensus has > already been reached on this, and implementation already exist, I'm okay with > parking this topic. >
The SR draft does expect all LSPs to be SR for the new association type and thus easier to handle. If you use a common association type, the behavior would be dependent on the PST for the first LSP that is added to the association. We could end up in a situation where Peer 1 would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 would add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be a use for this mixed cases in future, which would require different processing to be defined. > Still hoping for feedback regarding my comments on section 5. I see that as > being more significant, since it influences the workflow and at the moment I > don't see the dependency on draft-li-pce-controlled-id-space as necessary to > achieve notifying PCCs of reverse paths. > And I was hoping that authors would take a bite :) >From what I understood PLSP-ID remains a PCC allocated ID. The point that section 5 is making is that the same LSP would be identified by two PLSP-IDs, one allocated by Ingress and another by Egress PCCs. There is no proposal for PCE-controlled PLSP-ID. So PCE-init + R bit is enough (as you state) and I am in full agreement with you that figures with PLSP-ID could be useful. Thanks! Dhruv > Thanks again, > Andrew > > > On 2020-01-21, 5:01 AM, "Dhruv Dhody" <dhruv.i...@gmail.com> wrote: > > Hi Andrew, > > Speaking as a WG contributor and snipping to - > > > > For bidirectional associating two LSPs, does PCC/PCE need an additional > way to distinguish whether it's an SR or an RSVP bidirectional association? > Would that not be implicit based on the path setup type of the LSPs which > have been associated together? In other words, do we actually need > double-sided bidirectional SR association group object defined? > draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the > same as MPLS-TE (minus the RSVP signalling of course) and the object encoding > is the same, so does yet-another object need to be defined? From a PCEP > message encoding p.o.v within an association object structure, are 2 SR LSPs > that different than associating 2 RSVP LSPs? > > > > > > > > <RG> Main difference is that in case of RSVP-TE, the egress node learns > the reverse LSP via RSVP signaling whereas in case of SR, the egress node > learns the reverse LSP via PCE. > > > > > > > > <Andrew> Yes, I realize that, however the association structure is > about informing PCE to associate two LSPs together, is it not? It’s not > related to how 2 LSPs learn each opposite reverse path. To be specific, my > comment is regarding section 3.1. To instruct PCE “make these 2 > bidirectional” is a separate task than how the LSPs learn of each other’s > reverse LSP and path in my opinion. So to inform PCE “these 2 LSPs are > bidirectional, make them so” is the same instruction irrelevant of how each > LSP learns of each others path. For SR, yes there is the added process where > PCE may need to tell the PCC the opposite path, but that decision is a > behaviour post-association being provided, which can be determined as > necessary by the LSP path setup type of the associated LSPs. So if the goal > of to instruct PCE “these 2 LSPs are bidirectional”, that instruction is > common between LSPs whether they are RSVP or SR. Essentially defining > 'Double-sided Bidirectional SR Path Association Group' is not required > (unless there’s something else in that object we foresee being specific to SR > in the future). > > > > I remember this being discussed in the mailing list, and the decision > was that there are enough of a difference between the processing of > double-sided bi-directional for RSVP-TE and SR paths to have different > association types for the ease of implementation. Implementers were > also worried that the PST of the first LSP that joins the associations > would decide the next action and could lead to issues. In case one > tried to add SR and RSVP-TE path in one association, where one peer > may add SR first and reject RSVP-TE and other pcep peer may add > RSVP-TE first and reject SR and there could be some mismatch. This was > done mainly for the ease of implementations. > > Thanks! > Dhruv > > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
