Re: [j-nsp] NETCONF vs.

[Phil Shafer]

Chuck Anderson writes:
>Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
>candidate configuration to see what changed before issuing a commit
>request so I can avoid "empty" commits after doing a "replace"
>operation on a subtree.  I see that NETCONF defines a standard
> call, and I believe  is a
>legacy/proprietary Junos call.  There is a  example in the
>documentation, but there doesn't appear to be a way to see what was
>changed in the candidate config vs. the committed config:

Yes, JUNOS supports all the older API calls side-by-side with the
standard NETCONF API.  When we were working on the NETCONF standard,
my preference was for full words, and the concensus was "we'll use
full word but 'config' is a word", which I thought was odd, but was
happy find it allowed us to use our configuration-as-a-full-word
versions in a slick backwards compatible way.

>But I can't for the life of me figure out how to pass the various
>attributes inside the  tag with Perl.  How does one
>map the attributes INSIDE a tag to the Perl API call as below?

The module needs a means of adding methods, as well as methods for
the legacy API calls.

>

I'm not sure this is really what you what.  This will return the
full configuration with "junos:changed='changed'" attributes on any
element that's changed.  You might be better served with the "compare"
attribute on the get-configuration RPC, which returns the text-based
diff-like format.  It's not usable in terms of XML content, but
will only return the changed items.  If the output is empty, then
you don't need to commit.

But that still leaves you with the same problem, how to put attributes
on the  RPC.  You need something in Device.pm like:

sub add_method
{
my %map = (
'no-args' => $NO_ARGS,
'toggle' => $TOGGLE,
'toggle-no' => $TOGGLE_NO,
'string' => $STRING,
'dom' => $DOM,
'attribute' => $ATTRIBUTE,
'url' => $URL_STRING,
'dom-string' => $DOM_STRING,
);
my ($method, %args) = @_;

my %info;

foreach my $field (keys(%args)) {
$info{$field} = $map{$args{$field}};
}
$methods{$fn} = \%info;
}

My perl's a bit rusty and I need to bug out for the day, but that's
the gist of it.  I'll proof it and get it added to Device.pm asap.
Then you can add_method('get-configuration') with the proper content.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF vs.

[Chuck Anderson]

On Wed, Sep 21, 2016 at 03:26:40PM -0400, Chuck Anderson wrote:
> This doesn't work:
> 
> $res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', 
> database => 'candidate');
> 
> because that generates this:
> 
> 
>   
> candidate
> rollback
> changed
>   
> 
> 
> when I need it to be this:
> 
> 
>changed="changed">
>   
> 

After a close reading of the Perl Net::Netconf::Device code, I've come
to the conclusion that what I want to do is impossible with that API
as written, unless I modify it to add a get_configuration method that
accepts attributes.  I will either need to switch back to the
JUNOScript Perl API or change my approach.

It seems like this would be a common operation--commit my changes if
anything was actually changed during a merge/replace operation,
rollback otherwise.  Perhaps something could be built-in that does
this.  Even from the CLI I often do "show | compare" followed by
"rollback" and "exit" if there are no actual changes after e.g. a
"replace pattern" or "load merge" operation.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF vs.

[Chuck Anderson]

No, I'm trying to have the router do the compare server-side.

On Wed, Sep 21, 2016 at 02:52:42PM -0500, Tim Jackson wrote:
> Have you just tried to just compare source=>running to source=>candidate
> from get_config?
> 
> --
> Tim
> 
> On Wed, Sep 21, 2016 at 2:26 PM, Chuck Anderson  wrote:
> 
> > Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
> > candidate configuration to see what changed before issuing a commit
> > request so I can avoid "empty" commits after doing a "replace"
> > operation on a subtree.  I see that NETCONF defines a standard
> >  call, and I believe  is a
> > legacy/proprietary Junos call.  There is a  example in the
> > documentation, but there doesn't appear to be a way to see what was
> > changed in the candidate config vs. the committed config:
> >
> > https://www.juniper.net/techpubs/en_US/junos16.1/
> > topics/task/program/netconf-perl-client-application-
> > submitting-requests.html
> >
> > The API call I want to make is documented here:
> >
> > https://www.juniper.net/documentation/en_US/junos14.1/
> > topics/reference/tag-summary/netconf-junos-xml-protocol-
> > get-configuration.html
> >
> > But I can't for the life of me figure out how to pass the various
> > attributes inside the  tag with Perl.  How does one
> > map the attributes INSIDE a tag to the Perl API call as below?
> >
> >  > database="candidate">
> >
> > This doesn't work:
> >
> > $res = $jnx->get_configuration(changed => 'changed', compare =>
> > 'rollback', database => 'candidate');
> >
> > because that generates this:
> >
> > 
> >   
> > candidate
> > rollback
> > changed
> >   
> > 
> >
> > when I need it to be this:
> >
> > 
> >> changed="changed">
> >   
> > 
> >
> > Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] NETCONF vs.

[Chuck Anderson]

Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
candidate configuration to see what changed before issuing a commit
request so I can avoid "empty" commits after doing a "replace"
operation on a subtree.  I see that NETCONF defines a standard
 call, and I believe  is a
legacy/proprietary Junos call.  There is a  example in the
documentation, but there doesn't appear to be a way to see what was
changed in the candidate config vs. the committed config:

https://www.juniper.net/techpubs/en_US/junos16.1/topics/task/program/netconf-perl-client-application-submitting-requests.html

The API call I want to make is documented here:

https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/tag-summary/netconf-junos-xml-protocol-get-configuration.html

But I can't for the life of me figure out how to pass the various
attributes inside the  tag with Perl.  How does one
map the attributes INSIDE a tag to the Perl API call as below?



This doesn't work:

$res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', 
database => 'candidate');

because that generates this:


  
candidate
rollback
changed
  


when I need it to be this:


  
  


Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] PTP design

[Wojciech Owczarek]

Hi James,

Firstly, there is no 1 microsecond requirement. MiFID II states 100
microseconds, and only for low-latency environments.

- Best design: any redundant network design. Specifically for PTP: make
sure you have more than one PTP grandmaster (GM). This is a long topic.

- Your best bet is to use multicast since this is a Finance environment.
Some equipment in this space only supports multicast PTP.

- Yes, there are scalability issues, PTP grandmasters have limited message
throughput. This comes down to x slaves (clients) maximum (assuming some
n/sec message rate). They are not routers. Speak to your (prospective)
vendor about the limitations.

- Only one multicast group, 224.0.1.129. This is an IEEE standard, not
IETF. I really suggest to get a copy of the standard. You will need it. PTP
uses two UDP ports: 319 (for all timestamped messages) and 320
(non-timestamped). PTP communicates in two directions - this is especially
important for multicast. GM sends Sync and Announce messages to slaves,
slaves send Delay Request to which GM replies with Delay Response.

- You don't have to dedicate a VLAN, but you can, and it's a good idea. As
to delivering PTP to the host, some NICs and PTP-aware switches don't
readily deal with VLAN tags for PTP, so even if your hosts use tagged
traffic, the PTP connection should probably be untagged.

- It all depends on your network load, but unless your switches are PTP
aware (like PTP Transparent Clock), you don't want to run PTP over a busy
network as it impacts packet delay variation. This takes you back to the
design - if network is not PTP aware you may want to put a parallel design
in place that only delivers timing.

To put it simply, deploying PTP is nowhere as easy as deploying NTP.
Luckily the MiFID requirement isn't that stringent, but it's best to aim
for better than 100 us, because chances are it will go lower before your
next h/w refresh (unless you refresh very often). Get learning, now.

There are some time sync related conferences every year, the next European
one is ITSF which is in Prague this year in November. There will be a
session devoted to finance / mifid timing.
http://itsf2016.executiveindustryevents.com/Event/home if you're
interested. There is also a tutorial day. Other events are WSTS and ISPCS.

Cheers,
Wojciech


On 20 September 2016 at 18:01, james list  wrote:

> Hi experts!
>
> More than a vendor related question I’m wondering to discuss or get hints
> regarding the upcoming mifid2 new PTP request (max divergence from UTC of 1
> microsecond) implementation that will be requested since Jan 2018.
>
> I’d like to setup in my DC two fully redundant PTP source, for this reason
> I’m planning to use two different antennas, coax and supplier, but here the
> first doubts:
>
> -  What is best design to provide redundancy ?
>
> -  Do I have to use multicast or unicast (like NTP) ?
>
> -  Is there any scalability issue ?
>
> -  If I use multicast, which are the multicast group used by the
> PTP vendors ? Is there any ietf assigned group ?
>
> -  Do I have to dedicate a single dedicated vlan where the server
> has to connect to get the multicast packets ?
>
> I’ve many doubts and maybe we can share some commons ideas if anybody else
> is going to setup the service…
>
>
> Thanks in advance for any feedback
>
>
> Regards
>
> James
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp




-- 
-

Wojciech Owczarek
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp