Re: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)

On 12/14/2017 6:42 PM, Martin Bjorklund wrote:
> Hi,
>
> "Alexander Clemm" <ludwig@clemm.org> wrote:
>> Hi Benoit,
>>
>> I am not sure I understand your comment?
> I think the issue is that the leaf-list router-id should be of type
> yang:dotted-quad, and not inet:ip-address.
Right, imported from ietf-routing-types,  in 
https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-17

      typedef router-id {
        type yang:dotted-quad;
        description
          "A 32-bit number in the dotted quad format assigned to each
           router. This number uniquely identifies the router within
           an Autonomous System.";
      }

Regards, Benoit
>
>> I was referring to the typedef
>> router-id, which we define in example-ospf-topology.
> There is no such typedef.  There's an area-id though.
>
>
> /martin
>
>
> We made many changes
>> to make it clear that this is just an example, not a part of the actual
>> model, reflected in the description, naming, removal of contact and revision
>> information, etc.
>>
>> The tree diagram in section 5 is for the ietf-l3-unicast-topology module.
>> It is not part of an example.  The same is true for the grouping
>> l3-node-attributes.  It is part of the model.
>>
>> The example-ospf-topology model serves as an example as to how the model
>> might be refined/extended for other topologies.  As stated: "This module is
>> intended to serve as an example that illustrates how the general topology
>> model can be refined across multiple levels."  The sentence at the top of
>> the section "Extending the model - Example OSPF Topology - Model Overview"
>> states (slightly rephrased with inserted ", in this case") to "The following
>> model shows how the Layer 3 Unicast topology model can be extended, in this
>> case to cover OSFP topologies."
>>
>> Does this clarify or did you mean something else?
>>
>> Thanks
>> --- Alex
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benoit Claise
>> Sent: Thursday, December 14, 2017 3:33 AM
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; shares@ndzh.com
>> Subject: [i2rs] Benoit Claise's Discuss on
>> draft-ietf-i2rs-yang-l3-topology-14: (with DISCUSS)
>>
>> Benoit Claise has entered the following ballot position for
>> draft-ietf-i2rs-yang-l3-topology-14: Discuss
>>
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> We're making progress. Thanks.
>>
>>>> 4.
>>>>
>>>>          leaf-list router-id {
>>>>              type inet:ip-address;
>>>>              description
>>>>                "Router-id for the node";
>>>>            }
>>>>
>>>> My initial DISCUSS was: We don't want to wait for
>>>> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw,
>>>> we should expedite this publication), but any good reason why this is
>>>> aligned with its definition?
>>>>       typedef router-id {
>>>>          type yang:dotted-quad;
>>>>          description
>>>>            "A 32-bit number in the dotted quad format assigned to each
>>>>             router. This number uniquely identifies the router within an
>>>>             Autonomous System.";
>>>>        }
>>>>
>>>> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th,
>>>> it makes sense to import its router-id
>>> <ALEX> This is only used in the example.  The point of the example is
>>> to show how the model can be extended, not to define something
>>> normative, hence I don't think there is a need to introduce a
>>> dependency here which would only be distracting.
>>> </ALEX>
>> Can you help me understand how this is an example?
>> Section 5
>>
>>     module: ietf-l3-unicast-topology
>>       augment /nw:networks/nw:network/nw:network-types:
>>         +--rw l3-unicast-topology!
>>       augment /nw:networks/nw:network:
>>         +--rw l3-topology-attributes
>>            +--rw name?   string
>>            +--rw flag*   l3-flag-type
>>       augment /nw:networks/nw:network/nw:node:
>>         +--rw l3-node-attributes
>>            +--rw name?        inet:domain-name
>>            +--rw flag*        node-flag-type
>>            +--rw router-id*   inet:ip-address
>>            +--rw prefix* [prefix]
>>               +--rw prefix    inet:ip-prefix
>>               +--rw metric?   uint32
>>               +--rw flag*     prefix-flag-type
>>
>> And section 6:
>>
>>       grouping l3-node-attributes {
>>         description "L3 node scope attributes";
>>         container l3-node-attributes {
>>           description
>>             "Containing node attributes";
>>           leaf name {
>>             type inet:domain-name;
>>             description
>>               "Node name";
>>           }
>>           leaf-list flag {
>>             type node-flag-type;
>>             description
>>               "Node flags";
>>           }
>>           leaf-list router-id {
>>             type inet:ip-address;
>>             description
>>               "Router-id for the node";
>>           }
>>           list prefix {
>>             key "prefix";
>>             description
>>               "A list of prefixes along with their attributes";
>>             uses l3-prefix-attributes;
>>           }
>>         }
>>       }
>>
>> A different view at
>> https://www.yangcatalog.org/yang-search/yang_tree.php?module=ietf-l3-unicast
>> -topology#
>>
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
> .
>