This is an interesting suggestion. Taking this a little further rises the question how this would be represented. One option would be the introduction of another flag indicating the "validation policy" that should be applied. Or, perhaps preferrably, introducing a separate state (can be in a separate subtree) to indicate the current integrity state with regards to layering relationships, where any changes in the underlay that have not been properly tracked in configured layering relationships would be tracked/flagged. --- Alex
-----Original Message----- From: Igor Bryskin [mailto:[email protected]] Sent: Friday, October 23, 2015 1:51 PM To: Gert Grammel <[email protected]> Cc: Alexander Clemm (alex) <[email protected]>; Martin Bjorklund <[email protected]>; [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) Gert, You are right. When the user configures an abstract link specifying the underlay topology path, the user essentially provides a set of inclusion constraints for the trail supporting the link. Although it is not reflected yet in the TE-TOPO model, it should be possible to specify whether it is acceptable or not to deviate from said constraints on the trail setup and/or during its lifetime (e.g. in case of restoration). One server side implementation you and I are aware of has this capability already. Kind regards, Igor -----Original Message----- From: Gert Grammel [mailto:[email protected]] Sent: Friday, October 23, 2015 4:16 PM To: Igor Bryskin <[email protected]> Cc: Alexander Clemm (alex) <[email protected]>; Martin Bjorklund <[email protected]>; [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 Igor, It would be advisable to let the client decide whether a different underlay shall invalidate the intended config. Best Gert Sent from my Apple ][ > On 23 Oct 2015, at 15:00, Igor Bryskin <[email protected]> wrote: > > 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
