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
