Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

2017-10-11 Thread Xufeng Liu 
Hi Rob,

 

Thanks for the proposal. I think that the subtree does help, to a certain 
extend. The approach is worth mentioning to the implementers, though the 
remaining XPath is still complicated and could be worse for a more complex 
model. The good thing about the approach is that this is what we already have 
today. I agree with Tom on that NETCONF should have a better solution, but that 
may require protocol changes and need to cover more generic cases as Per 
described.

 

Thanks,

- Xufeng

 

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, October 11, 2017 6:49 AM
To: t.petch ; Igor Bryskin ; 
netc...@ietf.org; netmod@ietf.org
Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by leafref

 

I've also been thinking about this problem a bit more :-)

The XPath solution works, but the expression isn't particularly nice to write, 
and I suspect that implementations may struggle to implement it efficiently (if 
they support XPath filtering at all).

A nicer solution here might be to allow the XPath filters to be combined with a 
subtree filter along the lines of a more advanced type of "Attribute Match 
Expression" sec 6.2.2 of rfc6241.

E.g. rather than this XPath filter:

/te:te/te:tunnels/te:tunnel[te:name='foo'] |
/te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]
 

Here is example of what a subtree filter combined with an XPath filter could 
potentially look like (which of course isn't valid NETCONF/YANG today):


  


  

  



Any opinions on whether this would be beneficial or is this just reinventing 
the wheel?

Thanks,
Rob



On 11/10/2017 10:41, t.petch wrote:

Igor
 
Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.
 
I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).
 
The DNS approach works very well, in fact I do not think we would
survive without it.
 
Tom Petch
 
- Original Message -
From: "Igor Bryskin"   
Sent: Tuesday, October 10, 2017 2:35 PM
 
Hi Rob,
 
This helps a lot. What you wrote will work.
 
The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.
 
Thanks a lot,
Igor
 
c
 
From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netc...@ietf.org 
 ,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref
 
Hi Igor,
 
On 09/10/2017 23:11, Igor Bryskin wrote:

Hi Per,
 
This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes

has two key leafref lists:

1) each member of the 1st list points to a "connection" supporting the

te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.

2) each member of the 2nd list points to a supporting "te-tunnel" -

the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.

 
The question: how the client can retrieve via a single request all

attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):
 
   /te/tunnels/tunnel[name='foo'] |
 
/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]
 
E.g. in English, this should equate to something like:
 
Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.
 

 
Likewise, how the client can ask for full data of the te-tunnel and

all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something

Re: [netmod] ietf-routing or ietf-routing-2? module naming convention for NMDA transition. Re: upcoming adoptions

2017-10-11 Thread Kent Watsen 
I agree - let's keep the module name and mark the nodes obsolete.

Kent // any hat



Robert Wilton  wrote:
> 
> 
> On 09/10/2017 22:06, Benoit Claise wrote:
> > On 10/6/2017 6:01 PM, Robert Wilton wrote:
> >>
> >>
> >> On 06/10/2017 16:32, Martin Bjorklund wrote:
> >>> Benoit Claise  wrote:
>  Dear all,
> 
>  [including the routing and multicast YANG design teams]
>  Can we please finalize the discussion regarding ietf-routing versus
>  ietf-routing-2, sooner than later.
> 
>  I care about the NMDA transition strategy.
> 
>  Here are all the ietf-routing dependent YANG modules (those modules
>  that depend on ietf-routing)
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw=PEvVi2dNF5_gICJ7X97iuctNaAyUV5Pgnsr2LiDLFEA=
>  So many YANG modules.
> 
>  Look at the difference for ietf-routing-2:
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Drouting-2D2-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw=ISgVe_scuCOokfsF8C62oeiGhfTWMjlAXiS7bnS4cpc=
>  Some dependent modules are compliant with ietf-routing-2, the
>  multicast YANG modules, but these are the only ones.
> 
>  Changing the module name from ietf-routing to ietf-routing-2 implies
>  that the we have to warn all draft authors of ietf-routing YANG
>  dependent modules:
>  Â Â Â Â  1. to make sure they are aware of ietf-routing-2 (publishing a
>  RFC8022bis mentioning in the module description that this module is
>  not compatible with the NMDA architecture, and providing a pointer to
>  ietf-routing-2 ... is not an automatic way... so barely useful)
>  Â Â Â Â  2. to ask them to change their import to ietf-routing-2
>  Hopefully, in the routing case, it's mainly the IETF.
>  I'm glad that we didn't change the ietf-interfaces to
>  ietf-interfaces-2, we would have to deal with cross
>  SDO/consortia/opensource project issues
>  Note:
> 
>  Â Â Â  we're in a transition phase today, while we implement the
>  Â Â Â  soon-to-be-published draft-clacla-netmod-model-catalog-02
>  Â Â Â  Because of this, the SDO/consortia/opensource dependent YANG
>  modules
>  Â Â Â  will only appear in the Impact Analysis tomorrow at
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_impact-5Fanalysis.php-3Fmodules-5B-5D-3Dietf-2Dinterfaces-26recurse-3D0-26rfcs-3D1-26show-5Fsubm-3D1-26show-5Fdir-3Ddependents=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw=V7trpGHuvRSOwmb0ppL7GoztsKSUJI3yWJ-jxeSHTXs=
>  Â Â Â  In the mean time, you can see all these dependent modules
>  Â Â Â  Ex:
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-3Dietf-2Dinterfaces=DwIFAw=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=kX_P_vaiOkWNohKKL0HP88U-glXsmhlyjgWw7rxg1bw=euRn2n-i8nQZX5Y-ZieREslwccv7DJBS6L8jlNBA3TM=
>  Â Â Â Â  Â Â Â  Â Â Â  => click on "dependents"
>  Â Â Â  Those dependent modules is a new feature of
>  Â Â Â  draft-clacla-netmod-model-catalog-02
> 
> 
>  I'm wondering if this NMDA transition hurdle doesn't make a good
>  justification to keep the same module name!
>  We could debate whether ietf-routing is implemented or not, but the
>  point is moot: we don't know what we don't know.
> >>> Agreed.  I think there are no real reasons for keeping the module name
> >>> and deprecate the old defintiions.  Yes, it adds some noise to the
> >>> module but the fact is that we do deprecate all these defintions, and
> >>> I think we should not hide that.
> >> This is also my preferred option.
> >>
> >> I would like to just deprecate these nodes now, and then (for the
> >> routing module that is unlikely to have been widely implement) update
> >> it again in a 1-2 years time to remove the deprecated nodes (we can
> >> warn now that they will get removed).
> > According to Acee, there is one ietf-routing implementation (based on
> > an old draft version). If the point is that we don't want ietf-routing
> > implementations to implement "deprecated" leaves, can we "obsolete"
> > them now.
> > RFC 7950:
> >
> > 7.21.2. The "status" Statement
> >
> > The "status" statement

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

2017-10-11 Thread Robert Wilton 

I've also been thinking about this problem a bit more :-)

The XPath solution works, but the expression isn't particularly nice to 
write, and I suspect that implementations may struggle to implement it 
efficiently (if they support XPath filtering at all).


A nicer solution here might be to allow the XPath filters to be combined 
with a subtree filter along the lines of a more advanced type of 
"Attribute Match Expression" sec 6.2.2 of rfc6241.


E.g. rather than this XPath filter:

/te:te/te:tunnels/te:tunnel[te:name='foo'] |
/te:te/te:connections/te:connection[te:name=/te:te/te:tunnels/te:tunnel[te:name='foo']/te:connections/te:connection/te:name]

Here is example of what a subtree filter combined with an XPath filter 
could potentially look like (which of course isn't valid NETCONF/YANG 
today):



  


  

  



Any opinions on whether this would be beneficial or is this just 
reinventing the wheel?


Thanks,
Rob


On 11/10/2017 10:41, t.petch wrote:

Igor

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.

I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).

The DNS approach works very well, in fact I do not think we would
survive without it.

Tom Petch

- Original Message -
From: "Igor Bryskin" 
Sent: Tuesday, October 10, 2017 2:35 PM

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netc...@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:

Hi Per,

This is a good news, but, please, help us out.
Consider, we have a node - "te-tunnel" - which among other attributes

has two key leafref lists:

1) each member of the 1st list points to a "connection" supporting the

te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.

2) each member of the 2nd list points to a supporting "te-tunnel" -

the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.

The question: how the client can retrieve via a single request all

attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

/te/tunnels/tunnel[name='foo'] |

/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.


Likewise, how the client can ask for full data of the te-tunnel and

all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:

/te/tunnels/tunnel[name='foo'] |

/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
s/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob



I really appreciate your help,

Igor


-Original Message-
From: Per Hedeland [mailto:p...@tail-f.com]
Sent: Monday, October 09, 2017 5:21 PM
To: Igor Bryskin
Cc: m...@tail-f.com; xufeng.liu.i...@gmail.com; netc...@ietf.org;

netmod@ietf.org

Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by

leafref

Just to be clear: what we're suggesting is that you can use the
already-existing standard NETCONF XPath capability to achieve the

desired

Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

2017-10-11 Thread t.petch 
Igor

Thinking laterally, this is a problem that DNS encountered a few decades
ago and solved, by allowing the server to include additional information
not specifically requested that the server can see is going to be needed
for the next step, so if the client asks only about a CNAME, then the
server can provide the relevant IP address as well.

I suspect that the current rules for Netconf do not allow the server to
send anything not explicitly requested, which is a shame (IMO).

The DNS approach works very well, in fact I do not think we would
survive without it.

Tom Petch

- Original Message -
From: "Igor Bryskin" 
Sent: Tuesday, October 10, 2017 2:35 PM

Hi Rob,

This helps a lot. What you wrote will work.

The only difference is that if we would have the "joimt with" clause as
we proposed, the server would be able to tailor the te-tunnel
presentation to the client's requirements, e.g. substituting the
connection pointers with connection bodies, while, according to your
suggestion, the server will provide the te-tunnel body as is, and then
augment it with the cobbection information, thus, leaving
for the client to "shuffle " the received data. But I do agree, this
would be a minor inconvinience for the client, the important thing is
that the client will get all the data in one piece.

Thanks a lot,
Igor

c

From:Robert Wilton
To:Igor Bryskin,
Cc:Per Hedeland,netmod@ietf.org,netc...@ietf.org,
Date:2017-10-10 06:41:04
Subject:Re: [netmod] [Netconf] Retrieving Information Pointed by leafref

Hi Igor,

On 09/10/2017 23:11, Igor Bryskin wrote:
> Hi Per,
>
> This is a good news, but, please, help us out.
> Consider, we have a node - "te-tunnel" - which among other attributes
has two key leafref lists:
> 1) each member of the 1st list points to a "connection" supporting the
te-tunnel. All connections supporting all te-tunnels are stored in a
single list of connections.
> 2) each member of the 2nd list points to a supporting "te-tunnel" -
the te-tunnel in question depends on. All te=tunnels including the
te-tunnel in question, are stored in a single list of te-tunnels.
>
> The question: how the client can retrieve via a single request all
attributes of the te-tunnel in question along with all parameters of all
connections supporting the te-tunnel, but with just pointers to
supporting te-tunnels (so that the interested client can use the
pointers to retrieve full data via subsequent separate requests) ?
I think that it might be something like this (for tunnel name foo):

   /te/tunnels/tunnel[name='foo'] |

/te/connections/connection[name=/te/tunnels/tunnel[name='foo']/connectio
ns/connection/name]

E.g. in English, this should equate to something like:

Return all information for tunnel foo AND ALSO
Return all information for all connections where the connection name
matches one of the connections listed in tunnel foo.

>
> Likewise, how the client can ask for full data of the te-tunnel and
all supporting te-tunnels and just pointers for supporting connections?
If my xpath above is right, then this would be something roughly like
this:

   /te/tunnels/tunnel[name='foo'] |

/te/tunnels/tunnel[name=/te/tunnels/tunnel[name='foo']/supporting-tunnel
s/supporting-tunnel/name]


I'm an XPath novice, so the expressions might be wrong.

https://www.freeformatter.com/xpath-tester.html might be useful. E.g. if
you can construct a simple XML instance tree of your data, you could
validate whether the XPath expression works.

I hope that this is of some help,
Rob


>
> I really appreciate your help,
>
> Igor
>
>
> -Original Message-
> From: Per Hedeland [mailto:p...@tail-f.com]
> Sent: Monday, October 09, 2017 5:21 PM
> To: Igor Bryskin
> Cc: m...@tail-f.com; xufeng.liu.i...@gmail.com; netc...@ietf.org;
netmod@ietf.org
> Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>
> Just to be clear: what we're suggesting is that you can use the
> already-existing standard NETCONF XPath capability to achieve the
desired
> result - see https://tools.ietf.org/html/rfc6241#section-8.9
>
> --Per
>
> On 2017-10-09 21:52, Igor Bryskin wrote:
>> I agree. For example, a leafref may point not to a singls entity, but
to a list of entities, and the client might want to expand all of them
into the joint get response.
>>
>> Igor
>>
>> *From:*Per Hedeland
>> *To:*Martin Bjorklund,
>> *Cc:*Igor
Bryskin,xufeng.liu.i...@gmail.com,netc...@ietf.org,netmod@ietf.org,
>> *Date:*2017-10-09 15:12:22
>> *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by
leafref
>>
>> On 2017-10-09 19:13, Martin Bjorklund wrote:
>>> Igor Bryskin  wrote:
 Hi Per,

 Basically, what we need is a way for a client to request something
 like this:

 get  joint with 
>>> ... which is what Per's expression does!  Note that "|" in XPath
means
>>> "union".
>>>
>>> But as Per explained, it only works in some cases (when the