Hi John-

See comments below - And I will add a slide as you suggest. "A slide is worth a thousand words." :-)

Jerry

On 6/7/12 4:24 PM, John MacAuley wrote:

Guys,

Two questions:

1. Should we not include a an example where we model an originating and end "user" domain such that we need to start with a ".out" endpoint?

If the user STP is defined to be "outbound" in the topology description, then the reservation request and path finding will work fine. Path finders will need to heed the STP orientation, but this is a simple check. The STP attributes determine how the path must be oriented.

Given this scenario and the topologically specified orientation, there is obviously an SDP defined for "userdomain:A" == "firsthopnet:A" between the two domains. A connection request could specify the ingress STP two different ways: as "userdomain:A" (defined to be outbound in the user topology), or as "Firsthopnet:A" (defined as inbound in the first hop network topology). Both requests generate the same data plane path, the same ingress orientation, etc., but they [could] generate different service trees. The Connection request that references Userdomain:A as ingress would imply that the NSA for "Userdomain" must be contacted with a null segment (basically letting it know there is a connection being terminated on their doorstep.) The first real segment would be across "Firsthopnet" network.    A different connection request that references Firsthopnet:A as the ingress STP would only contact Firsthopnet NSA, and Userdomain would never be aware anthing upstream. Thus, we can implement Chin's request for user domain notification.

If however, we solve the STP path orientation by using dual STPs in the Reservation request, then we first need to have dual STP specifications for all elements of the Reservation - including the source and destination (!) (a unitary STP for source or destination in a tree segmentation could be ambiguous.) Further, the Query rollup would have to also indicate dual STPs to fully describe paths.   Since both STPs are used for all hops in this fashion, there is no way indicate whether or not the Userdomain NSA is to be contacted. Thus Chin's request is problematic.

Finally - and this really REALLY sucks about dual STP references: Reservation requests will require *both* STPs associated with an endpoint (or an ERO intermediate hop.) Thus if "Firsthopnet" network changes their STP names, all connections requests to the adjacent Userdoman:A terminus will no longer work - they can no longer reach those destination with the same STP name. !!!   This means that no one will be able to independently name their own endpoints and everyone will need to look up STPs in both networks - and same for every ERO hop!

DualSTPs/SDPs in a Reservation request to solve the path orientation issue are a Bad Idea.

2. Do we want to make this technology safe, or just sold the bi-directional point-to-point solution at the moment? Should we look at point to multi-point, etc.?

IMO, we need to solve the path ambiguity issue posed by bi-directional STPs. This is critical. If we do not solve this properly it will prevent tree segmentation altogether. But this is a separate issue from ERO specification. ERO specification becomes simple if we have resolved path orientation issue using topological attributes of the STP - the ERO becomes a simple a list of unitary STPs.

P2MP is complex because it introduces multicast/broadcast functions into the topology and connection model and adds substantial complexity to path finding. Further, there are technical issues associated with P2MP as uni-directional vs bi-directional service instances. I suggest this be a v3.0 feature.

Hope this helps!
Jerry

John.
On 2012-06-06, at 9:50 AM, Jerry Sobieski wrote:
Hi Chin-

I think your slides blend two separate issues: EROS; and Resolving loop path ambiguity of bidirectional STPs.
The path ambiguity is a artifact of loops in the inter-domain topology, not EROs.
I have added two slides to your deck (see attached) that explain my point.

We can discuss at the call
Jerry

On 6/6/12 3:34 AM, Chin Guok wrote:
Hi all,

Sorry for not getting this out sooner.

There has been some discussion in a smaller group on how to resolve the ambiguity of EROs that use bi-directional STPs. I've tried to capture the proposed solutions from the discussion and present them in the attached slide deck. I apologize to the folks in the discussion if I misrepresented your proposals, please feel free to make corrections.

Thanks.

- Chin
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg
<NSI-CS_EROs-v2 JS.pptx>_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg