Subject: Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 1 Jul 2015 14:46:29 +0000

Hi Liu, co-authors,
following Xian’s comments ,

I would have some comments on the proposed update, even if difficult before to have a definite text update:

1)      One of the basic usage of a te-topology model is to permit a controller (e.g. using a PCE) to make path computation. I see your topology model is based on nodes and links, he permits hierarchy of topology but I cannot see any node/leaf for termination/adaptation point. In case of multi-layer path computation it would be essential to understand where there are “change” in the layer (as MRN for example does with IACD concept) . I noticed you have defined server trail, but I do not see any topological component representing point of adaptation . You have underlay-trail-src and underlay-trail-des for reference to server trail but no specific attributes are indicated here like BW available and so on.

2)      Being a hierarchical data store, Yang does not support explicitly recursion but the model seems to obtain this by the usage of leafref , practically using a flat list of objects, where the objects are linked into a hierarchy using references, this happen for e.g. for topology recursion . Is it correct my understanding? Do you see any limitation on this usage?

3)      Xian already pointing out the scheduling presence, but I also have remark on the presence since a lot of comments during Dallas meeting underlined the premature presence of scheduling part of the model.

4)      About the topology-model draft-ietf-i2rs-yang-network-topo-01<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>, I noticed in a parallel discussion the explicit mention of the need to add Traffic Engineering. Is that in the process to encompass in a single draft with this Teas draft?

Thanks

Sergio

From: Teas [mailto:[email-masked]] On Behalf Of Xufeng Liu
Sent: mercoledì 1 luglio 2015 05:36
To: Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00

Hi Xian,

Thanks for the comments. Please check the replies below in-line.

Best,

- Xufeng

From: Zhangxian (Xian) [mailto:[email-masked]]
Sent: Friday, June 26, 2015 5:32 AM
To: Xufeng Liu
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Updating draft-ietf-teas-yang-te-topo-00

Hi, Xufeng and the authors,

Thank you for getting us updated.

I haven’t got time to read in details; just by skimming through the tree,  I have the following questions:

1)       During last IETF presentation, Pavan mentioned the model will try to use the generic topology model. Is this going to happen in this version?  If not, what is your plan?
[Xufeng] The integration with the i2rs generic topology model is currently working in progress. We will report the status during IETF93.

2)       A topology is now identified via a triplet ( provider-id, client-id, te-topology-id). I fail to see client-id as an universal attribute. For example, if I am the provider and I have one or topology, so how do I fill in the client-id field?
[Xufeng] In that case, the client-id will be 0. Similar to  the Global_ID described in RFC6370, 0 means that the client-id is not specified.

3)       I thought schedule will go away in a newer version, but instead it is made as a feature. I can live with this option, but why does a topology has a detailed timing information, while in the meantime its links and nodes have the same amount of information? Isn’t the existence of a topology depends on that of the nodes and links?
[Xufeng] The schedule is still here because there has been no proper home for it. Topology, node, and link all have such a scheduling option so that each entity can be scheduled independently. There could be such a case when some links are removed but the topology remains.

4)       underlay-path and underlay-backup-path both have a list of path elements. I think the first is working, is it? if so, could you rename the first as underlay-working-path? Alternatively, it would be better to put the two together and add a working/backup flag?
[Xufeng] We have renamed them to underlay-primary-path and underlay-backup-path.

Will get a more detailed review once the text is updated together with the code.

Cheers,
Xian

From: Teas [mailto:[email-masked]] On Behalf Of Xufeng Liu
Sent: 2015年6月23日 4:23
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] Updating draft-ietf-teas-yang-te-topo-00

Hi Folks,

The next version of the TE-Topology model draft will be submitted next week. In the meantime, please review the latest version of the model uploaded on github and let us know if there are any questions/comments. We expect to make one more update before submitting the draft.

https://github.com/ietf-mpls-yang/te/blob/master/ietf-te-topology.yang
https://github.com/ietf-mpls-yang/te/blob/master/ietf-te-topology_tree.txt

Regards,
- Xufeng (on behalf of the authors)

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 1 Jul 2015 15:16:00 +0000

Hi Sergio,
Thanks for the feedback. Please, see my answers in-line.

Cheers,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Wednesday, July 01, 2015 10:46 AM
To: Xufeng Liu
Cc: Zhangxian (Xian); BELOTTI, SERGIO (SERGIO); [email-masked]
Subject: Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00

Hi Liu, co-authors,

1)      One of the basic usage of a te-topology model is to permit a controller (e.g. using a PCE) to make path computation. I see your topology model is based on nodes and links, he permits hierarchy of topology but I cannot see any node/leaf for termination/adaptation point. In case of multi-layer path computation it would be essential to understand where there are “change” in the layer (as MRN for example does with IACD concept) . I noticed you have defined server trail, but I do not see any topological component representing point of adaptation . You have underlay-trail-src and underlay-trail-des for reference to server trail but no specific attributes are indicated here like BW available and so on.
IB>> Agree, it is important to know, when performing a path computation, the adaptation capabilities of the links at the path termination points. We need to add the IACD semantics to the link attributes. Good catch.

2)      Being a hierarchical data store, Yang does not support explicitly recursion but the model seems to obtain this by the usage of leafref , practically using a flat list of objects, where the objects are linked into a hierarchy using references, this happen for e.g. for topology recursion . Is it correct my understanding? Do you see any limitation on this usage?
IB>> Yes, we capture the topology hierarchies via leafrefs to respective underlay topologies of each of nodes and links, and so do, as I understand,  the I2RSS network topology models. No, I don’t see any limitations. Can you elaborate on this?

3)      Xian already pointing out the scheduling presence, but I also have remark on the presence since a lot of comments during Dallas meeting underlined the premature presence of scheduling part of the model.
IB>> This will go away as soon as we find a home for this IMO very useful concept.

4)      About the topology-model draft-ietf-i2rs-yang-network-topo-01<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>, I noticed in a parallel discussion the explicit mention of the need to add Traffic Engineering. Is that in the process to encompass in a single draft with this Teas draft?
IB>> We are working with I2RS to incorporate this model under their umbrella.
We also assume that the TEAS TE topology model could be used outside of I2RS as well, for example, in the ACTN context.

Thanks

Sergio

Hi Xian,

Best,

- Xufeng

Cheers,
Xian

Hi Folks,

Regards,

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 1 Jul 2015 15:33:38 +0000

Hi Igor,
thanks a lot for your prompt reply.

You can see my cents below in line .
Hope to see you in Prague.

Cheers
Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  IP Routing&Transport
via Trento 30 Vimercate (MB) - Italy
phone +39 (039) 6863033

From: Igor Bryskin [mailto:[email-masked]]
Sent: mercoledì 1 luglio 2015 17:16
To: BELOTTI, SERGIO (SERGIO); Xufeng Liu
Cc: Zhangxian (Xian); [email-masked]
Subject: RE: Updating draft-ietf-teas-yang-te-topo-00

Hi Sergio,

Cheers,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Wednesday, July 01, 2015 10:46 AM
To: Xufeng Liu
Cc: Zhangxian (Xian); BELOTTI, SERGIO (SERGIO); [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00

Hi Liu, co-authors,

2)      Being a hierarchical data store, Yang does not support explicitly recursion but the model seems to obtain this by the usage of leafref , practically using a flat list of objects, where the objects are linked into a hierarchy using references, this happen for e.g. for topology recursion . Is it correct my understanding? Do you see any limitation on this usage?
IB>> Yes, we capture the topology hierarchies via leafrefs to respective underlay topologies of each of nodes and links, and so do, as I understand,  the I2RSS network topology models. No, I don’t see any limitations. Can you elaborate on this?
SB> No, I’m not saying there is limitation on that. My question is whether you see other method/approach to obtain recursion than this. No assumption of limitation. :)

4)      About the topology-model draft-ietf-i2rs-yang-network-topo-01<https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>, I noticed in a parallel discussion the explicit mention of the need to add Traffic Engineering. Is that in the process to encompass in a single draft with this Teas draft?
IB>> We are working with I2RS to incorporate this model under their umbrella.
We also assume that the TEAS TE topology model could be used outside of I2RS as well, for example, in the ACTN context.
SB> Yes sure, this could be a right context.

Thanks

Sergio

Hi Xian,

Best,

- Xufeng

Cheers,
Xian

Hi Folks,

Regards,

---

From: Olivier Dugeon <[email-masked]>
Date: Mon, 6 Jul 2015 19:19:38 +0200

Hello All,

I read carefully the proposed yang model and to complement the remarks 
from Sergio, I didn't found how to describe inter-domain links.

In hierarchical PCE (RFC 6805) as well as for Backward Recursive Path 
Computation (RFC5441), it is mandatory to know the entry and exit points 
(i.e. ASBR node with inter-domain links) of the different ASs. I 
understand that it is possible to describe a node with links that point 
to another domain, but, I didn't found how to precise the AS number of 
the topology and remote AS that are connected to this topology. Such TE 
link could be describe in OSPF following RFC5392 and in ISIS following 
RFC5316. Indeed, PCE (BRPC or Hierarchical) during the path computation 
need to determine in the topology how to reach the next domain, and 
verify resource availability on inter-domain links once selected.

Is it possible to describe such inter-domain links with the current 
model ? if yes, please can you explain? If no, do you intend to add 
complement to the model ? Of course, I could help for that.

Regards,

Olivier

Le 01/07/2015 17:33, BELOTTI, SERGIO (SERGIO) a écrit :
> *Belotti Sergio - System Architect*
>
> *ALCATEL-LUCENT  IP Routing&Transport*
>
> *From:*Igor Bryskin [mailto:[email-masked]]
> *Sent:* mercoledì 1 luglio 2015 17:16
> *To:* BELOTTI, SERGIO (SERGIO); Xufeng Liu
> *Cc:* Zhangxian (Xian); [email-masked]
> *Subject:* RE: Updating draft-ietf-teas-yang-te-topo-00
>
> Hi Sergio,
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *BELOTTI, 
> SERGIO (SERGIO)
> *Sent:* Wednesday, July 01, 2015 10:46 AM
> *To:* Xufeng Liu
> *Cc:* Zhangxian (Xian); BELOTTI, SERGIO (SERGIO); [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00
>
> Hi Liu, co-authors,
>
> 1)One of the basic usage of a te-topology model is to permit a 
> controller (e.g. using a PCE) to make path computation. I see your 
> topology model is based on nodes and links, he permits hierarchy of 
> topology but I cannot see any node/leaf for termination/adaptation 
> point. In case of multi-layer path computation it would be essential 
> to understand where there are “change” in the layer (as MRN for 
> example does with IACD concept) . I noticed you have defined server 
> trail, but I do not see any topological component representing point 
> of adaptation . You have underlay-trail-src and underlay-trail-des for 
> reference to server trail but no specific attributes are indicated 
> here like BW available and so on.
>
> IB>> Agree, it is important to know, when performing a path 
> computation, the adaptation capabilities of the links at the path 
> termination points. We need to add the IACD semantics to the link 
> attributes. Good catch.
>
> 2)Being a hierarchical data store, Yang does not support explicitly 
> recursion but the model seems to obtain this by the usage of leafref , 
> practically using a flat list of objects, where the objects are linked 
> into a hierarchy using references, this happen for e.g. for topology 
> recursion . Is it correct my understanding? Do you see any limitation 
> on this usage?
>
> IB>> Yes, we capture the topology hierarchies via leafrefs to 
> respective underlay topologies of each of nodes and links, and so do, 
> as I understand,  the I2RSS network topology models. No, I don’t see 
> any limitations. Can you elaborate on this?
>
> SB> No, I’m not saying there is limitation on that. My question is 
> whether you see other method/approach to obtain recursion than this. 
> No assumption of limitation. J
>
> 3)Xian already pointing out the scheduling presence, but I also have 
> remark on the presence since a lot of comments during Dallas meeting 
> underlined the premature presence of scheduling part of the model.
>
> 4)About the topology-model draft-ietf-i2rs-yang-network-topo-01 
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>, 
> I noticed in a parallel discussion the explicit mention of the need to 
> add Traffic Engineering. Is that in the process to encompass in a 
> single draft with this Teas draft?
>
> We also assume that the TEAS TE topology model could be used outside 
> of I2RS as well, for example, in the ACTN context.
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Xufeng Liu
> *Sent:* mercoledì 1 luglio 2015 05:36
> *To:* Zhangxian (Xian)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Teas] Updating draft-ietf-teas-yang-te-topo-00
>
> Hi Xian,
>
> *From:*Zhangxian (Xian) [mailto:[email-masked]]
> *Sent:* Friday, June 26, 2015 5:32 AM
> *To:* Xufeng Liu
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Updating draft-ietf-teas-yang-te-topo-00
>
> 1)During last IETF presentation, Pavan mentioned the model will try to 
> use the generic topology model. Is this going to happen in this 
> version?  If not, what is your plan?
>
> */[Xufeng] The integration with the i2rs generic topology model is 
> currently working in progress. We will report the status during IETF93./*
>
> 2)A topology is now identified via a triplet ( provider-id, client-id, 
> te-topology-id). I fail to see client-id as an universal attribute. 
> For example, if I am the provider and I have one or topology, so how 
> do I fill in the client-id field?
>
> */[Xufeng] In that case, the client-id will be 0. Similar to  the 
> Global_ID described in RFC6370, 0 means that the client-id is not 
> specified./*
>
> 3)I thought schedule will go away in a newer version, but instead it 
> is made as a feature. I can live with this option, but why does a 
> topology has a detailed timing information, while in the meantime its 
> links and nodes have the same amount of information? Isn’t the 
> existence of a topology depends on that of the nodes and links?
>
> */[Xufeng] The schedule is still here because there has been no proper 
> home for it. Topology, node, and link all have such a scheduling 
> option so that each entity can be scheduled independently. There could 
> be such a case when some links are removed but the topology remains./*
>
> 4)underlay-path and underlay-backup-path both have a list of path 
> elements. I think the first is working, is it? if so, could you rename 
> the first as underlay-working-path? Alternatively, it would be better 
> to put the two together and add a working/backup flag?
>
> */[Xufeng] We have renamed them to underlay-primary-path and 
> underlay-backup-path./*
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Xufeng Liu
> *Sent:* 2015年6月23日4:23
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Teas] Updating draft-ietf-teas-yang-te-topo-00
>
> Hi Folks,
>
> The next version of the TE-Topology model draft will be submitted next 
> week. In the meantime, please review the latest version of the model 
> uploaded on github and let us know if there are any 
> questions/comments. We expect to make one more update before 
> submitting the draft.
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 7 Jul 2015 15:15:22 -0400

Olivier, Hi!

Thanks for bringing this up.

The set of TE link attributes modeled so far does not include the
attributes discussed in RFC5392/RFC5316. We should be able to address that
in the next revision of the model. Please feel free to send in the model
snippets for this.

Regards,
-Pavan

On Mon, Jul 6, 2015 at 1:19 PM, Olivier Dugeon <[email-masked]>
wrote:

> understand that it is possible to describe a node with links that point to
> another domain, but, I didn't found how to precise the AS number of the
> topology and remote AS that are connected to this topology. Such TE link
> could be describe in OSPF following RFC5392 and in ISIS following
> RFC5316. Indeed, PCE (BRPC or Hierarchical) during the path computation need
> to determine in the topology how to reach the next domain, and verify
> resource availability on inter-domain links once selected.
>
> Is it possible to describe such inter-domain links with the current model
> ? if yes, please can you explain ? If no, do you intend to add complement
> to the model ? Of course, I could help for that.
>
> Regards,
>
> Olivier
>
> *From:* Igor Bryskin [mailto:[email-masked]
> <[email-masked]>]
> *From:* Teas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *BELOTTI, SERGIO (SERGIO)
> 1)      One of the basic usage of a te-topology model is to permit a
> controller (e.g. using a PCE) to make path computation. I see your topology
> model is based on nodes and links, he permits hierarchy of topology but I
> cannot see any node/leaf for termination/adaptation point. In case of
> multi-layer path computation it would be essential to understand where
> there are “change” in the layer (as MRN for example does with IACD concept)
> . I noticed you have defined server trail, but I do not see any topological
> component representing point of adaptation . You have underlay-trail-src
> and underlay-trail-des for reference to server trail but no specific
> attributes are indicated here like BW available and so on.
>
> IB>> Agree, it is important to know, when performing a path computation,
> the adaptation capabilities of the links at the path termination points. We
> need to add the IACD semantics to the link attributes. Good catch.
>
>
>
> 2)      Being a hierarchical data store, Yang does not support explicitly
> practically using a flat list of objects, where the objects are linked into
> a hierarchy using references, this happen for e.g. for topology recursion .
> Is it correct my understanding? Do you see any limitation on this usage?
>
> IB>> Yes, we capture the topology hierarchies via leafrefs to respective
> underlay topologies of each of nodes and links, and so do, as I understand,
>  the I2RSS network topology models. No, I don’t see any limitations. Can
> you elaborate on this?
>
> SB> No, I’m not saying there is limitation on that. My question is whether
> you see other method/approach to obtain recursion than this. No assumption
> of limitation. J
>
>
>
> 3)      Xian already pointing out the scheduling presence, but I also
> have remark on the presence since a lot of comments during Dallas meeting
> 4)      About the topology-model draft-ietf-i2rs-yang-network-topo-01
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/>, I
> noticed in a parallel discussion the explicit mention of the need to add
> Traffic Engineering. Is that in the process to encompass in a single draft
> with this Teas draft?
>
> We also assume that the TEAS TE topology model could be used outside of
> I2RS as well, for example, in the ACTN context.
>
> *From:* Teas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Xufeng Liu
> *Cc:* [email-masked]
> *From:* Zhangxian (Xian) [mailto:[email-masked]
> <[email-masked]>]
> *Cc:* [email-masked]
> 1)       During last IETF presentation, Pavan mentioned the model will
> try to use the generic topology model. Is this going to happen in this
> *[Xufeng] The integration with the i2rs generic topology model is
> currently working in progress. We will report the status during IETF93.*
>
>
>
> 2)       A topology is now identified via a triplet ( provider-id,
> client-id, te-topology-id). I fail to see client-id as an universal
> attribute. For example, if I am the provider and I have one or topology, so
> how do I fill in the client-id field?
>
> *[Xufeng] In that case, the client-id will be 0. Similar to  the Global_ID
> described in RFC6370, 0 means that the client-id is not specified.*
>
>
>
> 3)       I thought schedule will go away in a newer version, but instead
> it is made as a feature. I can live with this option, but why does a
> topology has a detailed timing information, while in the meantime its links
> and nodes have the same amount of information? Isn’t the existence of a
> topology depends on that of the nodes and links?
>
> *[Xufeng] The schedule is still here because there has been no proper home
> for it. Topology, node, and link all have such a scheduling option so that
> each entity can be scheduled independently. There could be such a case when
> some links are removed but the topology remains.*
>
>
>
> 4)       underlay-path and underlay-backup-path both have a list of path
> elements. I think the first is working, is it? if so, could you rename the
> first as underlay-working-path? Alternatively, it would be better to put
> the two together and add a working/backup flag?
>
> *[Xufeng] We have renamed them to underlay-primary-path and
> underlay-backup-path.*
>
>
>
> *From:* Teas [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Xufeng Liu
> *Sent:* 2015年6月23日 4:23
> *To:* [email-masked]
> uploaded on github and let us know if there are any questions/comments. We
> expect to make one more update before submitting the draft.
>
>
>
> Teas mailing [email-masked]://www.ietf.org/mailman/listinfo/teas
>
>
>

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 10 Jul 2015 09:27:55 +0200

Hello Pavan,

Well, before sending some text, I think we need to clarify a point. To 
support inter-domain link inthe TE yang model, Ithink that we just need 
to add local and remote Autonomous System (AS) identifier. If remote AS 
identifier is clearly attach to remote link, and thus new entry (e.g. 
'remote-as-id') should be added to the link description, there is two 
options for the local AS identifier:

1/ Add a new entry (e.g. 'local-as-id') at the same level as the 
'area-id' entry. This allows to describe several AS within the same TE 
model, but, I'm afraid that it will duplicate the same value, each time 
you describe an area if you describe only one AS.

2/ Add a new entry (e.g. 'local-as-id') at the top level of the model. 
This is sufficient to describe the AS that belongs to the topology, but 
it will be impossible to describe several AS in the same model.

So, the question we need to answer is: do we need to describe several AS 
topology in the same TE model or do we consider that a TE model belongs 
to one AS only.

Regards

Olivier

Le 07/07/2015 21:15, Vishnu Pavan Beeram a écrit :
> attributes discussed in RFC5392/RFC5316. We should be able to address 
> that in the next revision of the model. Please feel free to send in 
> the model snippets for this.
>
> Regards,
> -Pavan
>
>
> On Mon, Jul 6, 2015 at 1:19 PM, Olivier Dugeon 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello All,
>
>     I read carefully the proposed yang model and to complement the
>     remarks from Sergio, I didn't found how to describe inter-domain
>     links.
>
>     In hierarchical PCE (RFC 6805) as well as for Backward Recursive
>     Path Computation (RFC5441), it is mandatory to know the entry and
>     exit points (i.e. ASBR node with inter-domain links) of the
>     different ASs. I understand that it is possible to describe a node
>     with links that point to another domain, but, I didn't found how
>     to precise the AS number of the topology and remote AS that are
>     connected to this topology. Such TE link could be describe in OSPF
>     following RFC5392 and in ISIS following RFC5316. Indeed, PCE (BRPC
>     or Hierarchical) during the path computation need to determine in
>     the topology how to reach the next domain, and verify resource
>     availability on inter-domain links once selected.
>
>     Is it possible to describe such inter-domain links with the
>     current model ? if yes, please can you explain? If no, do you
>     intend to add complement to the model ? Of course, I could help
>     for that.
>
>     Regards,
>
>     Olivier
>
>>     phone +39 (039) 6863033 <tel:%2B39%20%28039%29%206863033>
>>
>>     *Cc:* Zhangxian (Xian); [email-masked] <mailto:[email-masked]>
>>     *From:*Teas [mailto:[email-masked]] *On Behalf Of
>>     *BELOTTI, SERGIO (SERGIO)
>>     I would have some comments on the proposed update, even if
>>     difficult before to have a definite text update:
>>
>>     controller (e.g. using a PCE) to make path computation. I see
>>     your topology model is based on nodes and links, he permits
>>     hierarchy of topology but I cannot see any node/leaf for
>>     termination/adaptation point. In case of multi-layer path
>>     computation it would be essential to understand where there are
>>     “change” in the layer (as MRN for example does with IACD concept)
>>     . I noticed you have defined server trail, but I do not see any
>>     topological component representing point of adaptation . You have
>>     underlay-trail-src and underlay-trail-des for reference to server
>>     trail but no specific attributes are indicated here like BW
>>     available and so on.
>>
>>     2)Being a hierarchical data store, Yang does not support
>>     explicitly recursion but the model seems to obtain this by the
>>     usage of leafref , practically using a flat list of objects,
>>     where the objects are linked into a hierarchy using references,
>>     this happen for e.g. for topology recursion . Is it correct my
>>     understanding? Do you see any limitation on this usage?
>>
>>     respective underlay topologies of each of nodes and links, and so
>>     do, as I understand,  the I2RSS network topology models. No, I
>>     don’t see any limitations. Can you elaborate on this?
>>
>>     SB> No, I’m not saying there is limitation on that. My question
>>     is whether you see other method/approach to obtain recursion than
>>     this. No assumption of limitation. J
>>
>>     3)Xian already pointing out the scheduling presence, but I also
>>     have remark on the presence since a lot of comments during Dallas
>>     meeting underlined the premature presence of scheduling part of
>>     the model.
>>
>>     I noticed in a parallel discussion the explicit mention of the
>>     need to add Traffic Engineering. Is that in the process to
>>     encompass in a single draft with this Teas draft?
>>
>>     We also assume that the TEAS TE topology model could be used
>>     outside of I2RS as well, for example, in the ACTN context.
>>
>>     I haven’t got time to read in details; just by skimming through
>>     the tree,  I have the following questions:
>>
>>     1)During last IETF presentation, Pavan mentioned the model will
>>     try to use the generic topology model. Is this going to happen in
>>     this version? If not, what is your plan?
>>
>>     */[Xufeng] The integration with the i2rs generic topology model
>>     is currently working in progress. We will report the status
>>     during IETF93./*
>>
>>     2)A topology is now identified via a triplet ( provider-id,
>>     client-id, te-topology-id). I fail to see client-id as an
>>     universal attribute. For example, if I am the provider and I have
>>     one or topology, so how do I fill in the client-id field?
>>
>>     3)I thought schedule will go away in a newer version, but instead
>>     it is made as a feature. I can live with this option, but why
>>     does a topology has a detailed timing information, while in the
>>     meantime its links and nodes have the same amount of information?
>>     Isn’t the existence of a topology depends on that of the nodes
>>     and links?
>>
>>     */[Xufeng] The schedule is still here because there has been no
>>     proper home for it. Topology, node, and link all have such a
>>     scheduling option so that each entity can be scheduled
>>     independently. There could be such a case when some links are
>>     removed but the topology remains./*
>>
>>     elements. I think the first is working, is it? if so, could you
>>     rename the first as underlay-working-path? Alternatively, it
>>     would be better to put the two together and add a working/backup
>>     flag?
>>
>>     The next version of the TE-Topology model draft will be submitted
>>     next week. In the meantime, please review the latest version of
>>     the model uploaded on github and let us know if there are any
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>