Re: [netmod] "A YANG Data Model for Routing Management" Modifications

[Martin Bjorklund]

"Acee Lindem (acee)"  wrote:
> Hi Lada, 
> If we can’t get YANG to do what we need, can we just support a choice with
> a special value of “unspecified” for the interface and address?

Yes, you can make these keys be unions of interface-ref and an enum
'unspecified', and an ip-address and enum 'unspecified'.

> Additionally, we’d need a constraint that enforces the fact that both
> interface and address cannot be “unspecified”.

   must 'key1 != "unspecified" or key2 != "unspecified"';


/martin



> 
> Thanks,
> Acee 
> 
> On 5/30/16, 8:51 AM, "Ladislav Lhotka"  wrote:
> 
> >"Yingzhen Qu (yiqu)"  writes:
> >
> >> Hi Lada,
> >>
> >> The ³multi-next-hop² is using the combination of interface and address
> >>as
> >> the list key. I know key can¹t be empty, but for next hop it¹s possible
> >> that only either interface or address is used. I¹ve been trying to
> >>figure
> >> out a better way to present this, any suggestion?
> >
> >Optional list keys were proposed for YANG 1.1:
> >
> >https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
> >
> >The reason that the issue Y09 was eventually rejected was that many
> >people thought it was a relatively far-reaching change. This means we
> >are left with the same options as in YANG 1.0, none of them being very
> >pretty:
> >
> >- Add a dummy opaque key, e.g.
> >
> >  list next-hop-entries {
> >key id;
> >leaf id {
> >  type uint16;
> >}
> >unique interface address;
> >...
> >  }
> >
> >- Use special value, such as empty string, to indicate that either
> >  interface or address isn't present. But since inet:ipv[46]-address
> >  cannot be empty, we would need to define the type of "address" as a
> >  union of empty string and inet:ipv[46]-address.
> >
> >Lada
> >
> >>
> >> If there is anything I can help with the modification, please let me
> >>know.
> >>
> >> Thanks,
> >> Yingzhen
> >>
> >> On 5/27/16, 4:14 AM, "Acee Lindem (acee)"  wrote:
> >>
> >>>Hi Lada, 
> >>>
> >>>On 5/27/16, 5:42 AM, "Ladislav Lhotka"  wrote:
> >>>
> Hi Acee,
> 
> I have a couple of questions:
> 
> 1. I changed "routing-protocol" -> "control-plane-protocol" (this is
>    already in GitHub). As for identities, I introduced a new base
>    identity "control-plane-protocol", and derived "routing-protocol"
>    from it. So the idea is that routing protocols will still use
>    "routing-protocol" as their base. Is it OK?
> >>>
> >>>Yes - as long as there is a single list. I¹ll pull the source today.
> >>>
> 
> 2. We could define identities for route types but I am still not
>    convinced that route-type should be added to ietf-routing because
>    then we can't limit the set of types for each protocol, so that, for
>    example, OSPF routes could carry IS-IS Level [12] routes.
> >>>
> >>>Do you mean that OSPF would install the wrong type of route? I would see
> >>>this as a bug but not something the model itself should enforce.
> >>>
> >>>Note that OSPF can ³carry² any type of route if it is imported into OSPF
> >>>and advertised as an AS External route.
> >>>
> 
> 3. The "multi-next-hop" case in rib-extend-01 uses interface and
> address
>    as keys. This means that for every next-hop *both* parameters have
> to
>    be given. Is it really intended?
> >>>
> >>>No - either or both must be specified but both are not required. I¹ll
> >>>leave this to you YANG experts.
> >>>
> >>>Thanks,
> >>>Acee
> >>>
> >>>
> >>>
> 
> Thanks, Lada
> 
> "Acee Lindem (acee)"  writes:
> 
> > Hi Lada, 
> >
> >
> > On 5/23/16, 8:30 AM, "Ladislav Lhotka"  wrote:
> >
> >>"Acee Lindem (acee)"  writes:
> >>
> >>> Hi Lada, 
> >>>
> >>> I thought I go through the impetus for the changes I discussed in
> >>>my
> >>>last
> >>> E-mail. I believe we should make these changes and then freeze the
> >>> specification other than possible modifications based on the
> >>>consensus
> >>>for
> >>> the NETMOD operational state direction.
> >>
> >>I agree.
> >>
> >>>
> >>> The request to merge draft
> >>> https://www.ietf.org/id/draft-acee-rtgwg-yang-rib-extend-01.txt is
> >>>based
> >>> on the comments we received in the RTG WG meeting at IETF 95. The
> >>> consensus in the room was that the proposed next-hop additions were
> >>>pretty
> >>> standard in a networking device supporting routing. We were careful
> >>>not
> >>>to
> >>> include any MPLS or other tunneling technologies. If you feel that
> >>>some
> >>>of
> >>> these are not applicable to hosts, we could make them features.
> >>
> >>I don't think that many home routers support these features either
> >>(except ECMP). I still think they should be added as augments, and,
> 

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt

[Clyde Wildes (cwildes)]

Jason,

With regards to adding log-input-transports: please see RFC 5424 – The Syslog 
Protocol, sections 3 and 4 where relay and collector functions are discussed. 
In order to support the relay and/or collector function, log-input-transports 
is required and I believe it is best to support the entire RFC 5424 protocol.

I produced the following table to help with the analysis of what features might 
be included. Please provide updates to the table to help with the analysis.

Feature Alcatel  Brocade  Ciena  Cisco IOS/XE  Cisco IOS/XR 
 Cisco NXOS  Juniper JunOS  Linux Rsyslog  Comments
log-input-transports
  x
log-action console xx x  x  
 xx   x 
log-action buffer  x  x  x
log-action filex  x  x  
 xx   x
log-action remote   x   x x  x  
 xx   x
log-action terminal   x  x  
 xx
log-action session x
  x
feature buffer-limit-bytes   ?  x  x
feature file-limit-size   x  x  
  x
feature file-limit-duration   x 
  x
feature 
 terminal-facility-device-logging
feature 
 session-facility-user-logging x
  x
feature select-sev-compare x  x 
  x
feature select-match   x  x 
  x   x
feature structured-data 
  x   x Required because of RFC 5424
feature signed-messages 
  x Required because of RFC 5848

Alcatel - 
https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/9300710702_V1_7750%20SR%20(SERVICE%20ROUTER).pdf
Ciena - https://www.commoncriteriaportal.org/files/epfiles/st_vid10460-st.pdf
Cisco IOS/XE - 
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/command/esm-cr-book/esm-cr-a1.html
Cisco IOS/XR - 
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/system_monitoring/command/reference/b-sysmon-cr-asr9k/b-sysmon-cr-asr9k_chapter_0100.html
Cisco NXOS - 
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/system-management/command/reference/n7k_sm_cmd_ref/sm_cmd_l.html#pgfId-1014686
Brocade - 
http://www.brocade.com/content/html/en/command-reference-guide/nos-700-commandref/GUID-2297E4CA-76DC-43E5-9164-AC1AC9D3F4E7.html
Juniper JunOS - 
http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/syslog-edit-system.htm;
Linux Rsyslog - http://www.rsyslog.com/doc/v8-stable/   


Thanks,

Clyde


On 5/27/16, 12:30 PM, "Sterne, Jason (Nokia - CA)"  
wrote:

>Hi Clyde,
>
>I was a bit surprised to see the receiver/server side config in here 
>(log-input-transports).  That seems to be a somewhat significant change in 
>scope.  I thought the focus of this was more on the generation & distribution. 
> Do many implementations have functionality that maps to this 
>log-input-transports ?   In any case the pyang tree has log-input-transports 
>but it doesn't seem to be down in the actual model itself.  But I'd be 
>inclined to just remove this from the model.  Maybe Mahesh has some thoughts 
>here (I didn't see a posting about this in the mailing list).
>
>I agree there are multiple implementations of console, buffer and session 
>logs.  But maybe 'terminal' should be removed or an if-feature ?  I'm not sure 
>that one is so widespread (not in JUNOS, not in SR OS).
>
>Buffer-limit-messages and having multiple log buffers are both supported by 
>Nokia SR OS. I would think that both of those would have support in other 
>logging implementations as well.  I'm not sure if Tom P. was really concluding 
>that there are no implementations of these in his email.  Do we have multiple 
>examples of implementations that limit log buffers using bytes ?
>
>Buffer-limit-messages would be easy to do as an augmentation but making the 
>log-buffer a list is probably something we should just do from the start.  
>That is also consistent with all the other types of actions (except console of 

Re: [netmod] "A YANG Data Model for Routing Management" Modifications

[Yingzhen Qu (yiqu)]

Since “multi-next-hop” is a list and we need a key for a list, even choice
doesn’t work here. I’m thinking maybe we can use “0.0.0.0” for empty ip
address and “NULL” for empty interface, but it doesn’t look pretty anyway.
Especially the interface should be a reference, and it can’t be “NULL”.

Thanks,
Yingzhen

On 5/31/16, 1:29 PM, "Acee Lindem (acee)"  wrote:

>Hi Lada, 
>If we can’t get YANG to do what we need, can we just support a choice with
>a special value of “unspecified” for the interface and address?
>Additionally, we’d need a constraint that enforces the fact that both
>interface and address cannot be “unspecified”.
>
>Thanks,
>Acee 
>
>On 5/30/16, 8:51 AM, "Ladislav Lhotka"  wrote:
>
>>"Yingzhen Qu (yiqu)"  writes:
>>
>>> Hi Lada,
>>>
>>> The ³multi-next-hop² is using the combination of interface and address
>>>as
>>> the list key. I know key can¹t be empty, but for next hop it¹s possible
>>> that only either interface or address is used. I¹ve been trying to
>>>figure
>>> out a better way to present this, any suggestion?
>>
>>Optional list keys were proposed for YANG 1.1:
>>
>>https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
>>
>>The reason that the issue Y09 was eventually rejected was that many
>>people thought it was a relatively far-reaching change. This means we
>>are left with the same options as in YANG 1.0, none of them being very
>>pretty:
>>
>>- Add a dummy opaque key, e.g.
>>
>>  list next-hop-entries {
>>key id;
>>leaf id {
>>  type uint16;
>>}
>>unique interface address;
>>...
>>  }
>>
>>- Use special value, such as empty string, to indicate that either
>>  interface or address isn't present. But since inet:ipv[46]-address
>>  cannot be empty, we would need to define the type of "address" as a
>>  union of empty string and inet:ipv[46]-address.
>>
>>Lada
>>
>>>
>>> If there is anything I can help with the modification, please let me
>>>know.
>>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On 5/27/16, 4:14 AM, "Acee Lindem (acee)"  wrote:
>>>
Hi Lada, 

On 5/27/16, 5:42 AM, "Ladislav Lhotka"  wrote:

>Hi Acee,
>
>I have a couple of questions:
>
>1. I changed "routing-protocol" -> "control-plane-protocol" (this is
>   already in GitHub). As for identities, I introduced a new base
>   identity "control-plane-protocol", and derived "routing-protocol"
>   from it. So the idea is that routing protocols will still use
>   "routing-protocol" as their base. Is it OK?

Yes - as long as there is a single list. I¹ll pull the source today.

>
>2. We could define identities for route types but I am still not
>   convinced that route-type should be added to ietf-routing because
>   then we can't limit the set of types for each protocol, so that,
>for
>   example, OSPF routes could carry IS-IS Level [12] routes.

Do you mean that OSPF would install the wrong type of route? I would
see
this as a bug but not something the model itself should enforce.

Note that OSPF can ³carry² any type of route if it is imported into
OSPF
and advertised as an AS External route.

>
>3. The "multi-next-hop" case in rib-extend-01 uses interface and
>address
>   as keys. This means that for every next-hop *both* parameters have
>to
>   be given. Is it really intended?

No - either or both must be specified but both are not required. I¹ll
leave this to you YANG experts.

Thanks,
Acee



>
>Thanks, Lada
>
>"Acee Lindem (acee)"  writes:
>
>> Hi Lada, 
>>
>>
>> On 5/23/16, 8:30 AM, "Ladislav Lhotka"  wrote:
>>
>>>"Acee Lindem (acee)"  writes:
>>>
 Hi Lada, 

 I thought I go through the impetus for the changes I discussed in
my
last
 E-mail. I believe we should make these changes and then freeze the
 specification other than possible modifications based on the
consensus
for
 the NETMOD operational state direction.
>>>
>>>I agree.
>>>

 The request to merge draft
 https://www.ietf.org/id/draft-acee-rtgwg-yang-rib-extend-01.txt is
based
 on the comments we received in the RTG WG meeting at IETF 95. The
 consensus in the room was that the proposed next-hop additions
were
pretty
 standard in a networking device supporting routing. We were
careful
not
to
 include any MPLS or other tunneling technologies. If you feel that
some
of
 these are not applicable to hosts, we could make them features.
>>>
>>>I don't think that many home routers support these features either
>>>(except ECMP). I still think they should be added 

Re: [netmod] "A YANG Data Model for Routing Management" Modifications

[Acee Lindem (acee)]

Hi Lada, 
If we can’t get YANG to do what we need, can we just support a choice with
a special value of “unspecified” for the interface and address?
Additionally, we’d need a constraint that enforces the fact that both
interface and address cannot be “unspecified”.

Thanks,
Acee 

On 5/30/16, 8:51 AM, "Ladislav Lhotka"  wrote:

>"Yingzhen Qu (yiqu)"  writes:
>
>> Hi Lada,
>>
>> The ³multi-next-hop² is using the combination of interface and address
>>as
>> the list key. I know key can¹t be empty, but for next hop it¹s possible
>> that only either interface or address is used. I¹ve been trying to
>>figure
>> out a better way to present this, any suggestion?
>
>Optional list keys were proposed for YANG 1.1:
>
>https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
>
>The reason that the issue Y09 was eventually rejected was that many
>people thought it was a relatively far-reaching change. This means we
>are left with the same options as in YANG 1.0, none of them being very
>pretty:
>
>- Add a dummy opaque key, e.g.
>
>  list next-hop-entries {
>key id;
>leaf id {
>  type uint16;
>}
>unique interface address;
>...
>  }
>
>- Use special value, such as empty string, to indicate that either
>  interface or address isn't present. But since inet:ipv[46]-address
>  cannot be empty, we would need to define the type of "address" as a
>  union of empty string and inet:ipv[46]-address.
>
>Lada
>
>>
>> If there is anything I can help with the modification, please let me
>>know.
>>
>> Thanks,
>> Yingzhen
>>
>> On 5/27/16, 4:14 AM, "Acee Lindem (acee)"  wrote:
>>
>>>Hi Lada, 
>>>
>>>On 5/27/16, 5:42 AM, "Ladislav Lhotka"  wrote:
>>>
Hi Acee,

I have a couple of questions:

1. I changed "routing-protocol" -> "control-plane-protocol" (this is
   already in GitHub). As for identities, I introduced a new base
   identity "control-plane-protocol", and derived "routing-protocol"
   from it. So the idea is that routing protocols will still use
   "routing-protocol" as their base. Is it OK?
>>>
>>>Yes - as long as there is a single list. I¹ll pull the source today.
>>>

2. We could define identities for route types but I am still not
   convinced that route-type should be added to ietf-routing because
   then we can't limit the set of types for each protocol, so that, for
   example, OSPF routes could carry IS-IS Level [12] routes.
>>>
>>>Do you mean that OSPF would install the wrong type of route? I would see
>>>this as a bug but not something the model itself should enforce.
>>>
>>>Note that OSPF can ³carry² any type of route if it is imported into OSPF
>>>and advertised as an AS External route.
>>>

3. The "multi-next-hop" case in rib-extend-01 uses interface and
address
   as keys. This means that for every next-hop *both* parameters have
to
   be given. Is it really intended?
>>>
>>>No - either or both must be specified but both are not required. I¹ll
>>>leave this to you YANG experts.
>>>
>>>Thanks,
>>>Acee
>>>
>>>
>>>

Thanks, Lada

"Acee Lindem (acee)"  writes:

> Hi Lada, 
>
>
> On 5/23/16, 8:30 AM, "Ladislav Lhotka"  wrote:
>
>>"Acee Lindem (acee)"  writes:
>>
>>> Hi Lada, 
>>>
>>> I thought I go through the impetus for the changes I discussed in
>>>my
>>>last
>>> E-mail. I believe we should make these changes and then freeze the
>>> specification other than possible modifications based on the
>>>consensus
>>>for
>>> the NETMOD operational state direction.
>>
>>I agree.
>>
>>>
>>> The request to merge draft
>>> https://www.ietf.org/id/draft-acee-rtgwg-yang-rib-extend-01.txt is
>>>based
>>> on the comments we received in the RTG WG meeting at IETF 95. The
>>> consensus in the room was that the proposed next-hop additions were
>>>pretty
>>> standard in a networking device supporting routing. We were careful
>>>not
>>>to
>>> include any MPLS or other tunneling technologies. If you feel that
>>>some
>>>of
>>> these are not applicable to hosts, we could make them features.
>>
>>I don't think that many home routers support these features either
>>(except ECMP). I still think they should be added as augments, and,
>>as
>>you know, ietf-routing was previously modified to enable it. Another
>>advantage of doing so is that it will be more future-proof: it will
>>be
>>easier to replace their definitions with something else, which may be
>>impossible if they are an integral part of ietf-routing, because of
>>the
>>rigid rules for updating published YANG modules.
>
> Lou and I had a lengthy discussion on this and we agreed that the
>base
> should support ECMP and a metric per-path (like Linux).