Hi Martin,

It is possible that a user configures a link of a customized (user defined) 
topology providing also the path defined in underlay server defined topology. 
Said underlay path needs to be considered as intended configuration. Actual 
underlay path will be state data in this case ( personally I also do not see a 
difference between state and server provided data), which may or may not match 
the intended underlay path. The actual underlay path may also change over time 
due, for example, network failure restoration procedures affecting the underlay 
topology.
The link of the user defined topology is not invalidated in this case. User 
just has to deal with the fact that the intended configuration may not 
necessarily match the actual configuration and state data.

Cheers,
Igor

-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Alexander Clemm (alex)
Sent: Thursday, October 22, 2015 8:12 PM
To: Martin Bjorklund <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; 
[email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14)

Hi Martin,

Agree, we need to add text for this.  Good catch.  

The reality is that the integrity of the links between overlay and underlay 
will be broken.  The fact that those links will be invalidated is something 
that ultimately needs to be indicated.  

Since the interface analogy was brought up, this problem is actually faced by 
layered interfaces that are user controlled as as well.  What is the solution 
that is applied there?  (I guess it is basically left up to the application, 
correct?)

--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email protected]] 
Sent: Monday, October 19, 2015 11:04 PM

.....


What happens in your model if a user-defined network has a reference to a 
server-provided network, and the sever decides to remove its network?  I see no 
special text in your document about this case.


 

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to