[Nsi-wg] Summarization of ERO discussion

[Jerry Sobieski]

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 at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>> <NSI-CS_EROs-v2 JS.pptx>_______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20120607/a052d068/attachment.html>