Subject: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

From: Lizhenbin <[email-masked]>
Date: Tue, 14 Oct 2014 14:33:39 +0000

Hi Rakesh, Tarek & Robert,
I just saw you proposed the draft-gandhi-mpls-te-yang-model-00. I wonder if you are aware of the draft-chen-mpls-te-yang-cfg-00 we proposed on August 15. From our point of view, we are not experienced enough to remind our MPLSers of the new draft to propose possible discussion and collaboration. I compared the two drafts as follows:
1. The possible overlapped part
      draft-gandhi-mpls-te-yang-model-00                                      draft-chen-mpls-te-yang-cfg-00
     4.1.  Global MPLS-TE Data Model Overview . . . . . . . . . . . .  4       -->         MPLS TE Global Configuration/RSVP-TE Global Configuration
     4.2.  MPLS-TE Tunnel Interface Data Model Overview . . . . . . .  6    -->         RSVP-TE Tunnel Configuration
     4.3.  MPLS-TE Tunnel LSP Data Model Overview . . . . . . . . . .  7      -->         RSVP-TE Tunnel Configuration
     4.4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .  8        -->         MPLS TE Link Configuration/RSVP-TE Interface Configuration
2. draft-chen-mpls-te-yang-cfg-00 defines following configuration Yang beyond draft-gandhi-mpls-te-yang-model-00.
     3.4.  Explicit Path Configuration . . . . . . . . . . . . . . .   5
     3.5.  P2MP TE Leaf List Configuration . . . . . . . . . . . . .   5
     3.9.  CSPF Configuration  . . . . . . . . . . . . . . . . . . .   8
     3.10. P2MP TE Tunnel Template Configuration . . . . . . . . . .   8
3. draft-chen-mpls-te-yang-cfg-00 has already defined all Yang model for these listed configuration while draft-gandhi-mpls-te-yang-model-00 leaves many Yang Model definition as spaces.

I think maybe you are not aware of the existing draft. If you would like to cooperate on the MPLS TE Yang Models definition, we are very glad to discuss with you to try to unify these Yang models.

Best Regards,
Zhenbin(Robin)

---

From: Lizhenbin <[email-masked]>
Date: Tue, 14 Oct 2014 15:12:45 +0000

Hi MPLSer,
I would like to remind you of the other two Yang model drafts: draft-chen-mpls-te-yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. Welcome comments and collaboration.

Best Regards,
Zhenbin(Robin)

发件人: mpls [mailto:[email-masked]] 代表 Lizhenbin
发送时间: 2014年10月14日 22:34
收件人: [email-masked]; [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

Best Regards,
Zhenbin(Robin)

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Thu, 16 Oct 2014 13:34:02 +0000

Hi Robin,

Thanks for the reference to the draft. We had a look at it. We are proposing a slightly different model that introduces clear delineation between configuration, operational (state), RPC (executional), and notifications for MPLS-TE tunnels, lsps, links, and global data:

module: mpls-te

   +--rw tunnels-cfg!

   +--rw lsps-cfg!

   +--rw links-cfg!

   +--rw global-cfg!

   +--ro tunnels-oper

   +--ro lsps-oper

   +--ro links-oper

   +--ro global-oper

rpcs:

   +---x tunnels-rpc

   +---x lsps-rpc

   +---x global-rpc

   +---x links-rpc

notifications:

   +---n tunnels-notif

   +---n lsps-notif

   +---n links-notif

   +---n global-notif

We also have a detailed YANG model in-the-works (as per the above) and we’re planning to include in the next update of the draft. For example, the tunnels YANG model looks something like below.

As for collaboration, yes, we are willing to consolidate our efforts with you to produce the IETF MPLS-TE Yang model.

module: mpls-te

   +--rw tunnels-cfg!

   |  +--rw tunnel* [name type]

   |     +--rw name                    string

   |     +--rw type                    tunnel-type

   |     +--rw tunnel-id?              uint16

   |     +--rw description?            string

   |     +--rw destination* [address]

   |     |  +--rw address        inet:ip-address

   |     |  +--rw path-option* [index]

   |     |     +--rw index             uint8

   |     |     +--rw (type)?

   |     |     |  +--:(dynamic)

   |     |     |  |  +--rw dynamic

   |     |     |  +--:(explicit)

   |     |     |     +--rw explicit

   |     |     |        +--rw explicit-hoplist* [index]

   |     |     |           +--rw index                   uint8

   |     |     |           +--rw explicit-hop-address?   hop-address-type

   |     |     |           +--rw explicit-hop-action?    hop-action-type

   |     |     +--rw igp-constraint

   |     |     |  +--rw igp?          enumeration

   |     |     |  +--rw area-level?   uint32

   |     |     +--rw verbatim?         boolean

   |     |     +--rw lockdown?         boolean

   |     +--rw lsp-cfg* [index]

   |     |  +--rw index             leafref

   |     |  +--rw source?           inet:ip-address

   |     |  +--rw fast-reroute?     boolean

   |     |  +--rw record-route?     boolean

   |     |  +--rw signaled-name?    string

   |     |  +--rw priority

   |     |  |  +--rw setup?   uint8

   |     |  |  +--rw hold?    uint8

   |     |  +--rw affinity

   |     |  |  +--rw constraints* [action]

   |     |  |     +--rw action        affinity-action-type

   |     |  |     +--rw constraint

   |     |  |        +--rw affinity-list* [name]

   |     |  |           +--rw name    string

   |     |  +--rw path-selection

   |     |  |  +--rw cost-limit?   uint32

   |     |  |  +--rw hop-limit?    uint32

   |     |  |  +--rw metric?       path-metric-type

   |     |  |  +--rw tiebreaker?   path-tiebreaker-type

   |     |  +--rw bfd

   |     |  |  +--rw type?               bfd-type

   |     |  |  +--rw bringup-timeout?    uint32

   |     |  |  +--rw dampening?          uint32

   |     |  |  +--rw encap-mode?         bfd-encap-mode-type

   |     |  |  +--rw fast-detect?        boolean

   |     |  |  +--rw lsp-ping

   |     |  |  |  +--rw disable?    boolean

   |     |  |  |  +--rw interval?   uint32

   |     |  |  +--rw minimum-interval?   uint32

   |     |  |  +--rw multiplier?         uint32

   |     |  +--rw logging-event* [event]

   |     |     +--rw event    logging-event-type

   |     +--rw (policy-routing)?

   |     |  +--:(forwarding-class)

   |     |  |  +--rw forwarding-class

   |     |  |     +--rw class?   uint8

   |     |  +--:(forwarding-group)

   |     |     +--rw forwarding-group

   |     |        +--rw classes*   uint8

   |     +--rw auto-bandwidth

   |     |  +--rw overflow-threshold?    uint32

   |     |  +--rw overflow-limit?        uint8

   |     |  +--rw underflow-threshold?   uint32

   |     |  +--rw underflow-limit?       uint8

   |     |  +--rw collect-only?          boolean

   |     +--rw (announce-as)?

   |     |  +--:(autoroute)

   |     |  |  +--rw autoroute!

   |     |  |     +--rw include-ipv6-unicast?   boolean

   |     |  |     +--rw (metric-type)?

   |     |  |        +--:(metric)

   |     |  |        |  +--rw metric?                 uint8

   |     |  |        +--:(relative-metric)

   |     |  |        |  +--rw relative-metric?        uint8

   |     |  |        +--:(absolute-metric)

   |     |  |           +--rw absolute-metric?        uint8

   |     |  +--:(forwarding-adjacency)

   |     |     +--rw forwarding-adjacency!

   |     |        +--rw holdtime?               uint32

   |     |        +--rw include-ipv6-unicast?   boolean

   |     +--rw backup-bandwidth?       uint32

   |     +--rw load-share?             uint32

   |     +--rw bidirectional

   |        +--rw association

   |           +--rw id?              uint32

   |           +--rw source?          inet:ip-address

   |           +--rw global-source?   inet:ip-address

   |           +--rw type?            bidir-association-type

   +--rw global-cfg!

Regards,
Tarek

From: Lizhenbin <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 14, 2014 at 11:12 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

Hi MPLSer,

Best Regards,
Zhenbin(Robin)

发件人: mpls [mailto:[email-masked]] 代表 Lizhenbin
发送时间: 2014年10月14日 22:34
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

Best Regards,
Zhenbin(Robin)

---

From: "Osborne, Eric" <[email-masked]>
Date: Thu, 16 Oct 2014 19:18:03 +0000

I looked at both documents.  They both have some good and some bad.  The hardest part in reconciling them will be that they both have a very vendor-specific view of the world.  This is no surprise given the nature of the technology, and I don’t think it’s unique to TE.  BGP will be at least as hard to sort out.

I think we need to clearly delineate between standard features, common features, and vendor-specific ones.  Standard features might be scoped to anything that is both signaled and RFC’d, e.g., [3209, 4420, 4875, 5712, 7308].

Common are things that may have different names and which aren’t signaled, but which are in use in many/most/all implementations – things like what one vendor calls ‘autoroute announce’ and another calls ‘igp shortcuts’.  Find a common name, or a way to use both, and build a model for the subset of things that is most common across vendors.  This is a bit of a quagmire since different vendors will have different approaches to many details of common features, and it may be the most difficult part of this whole exercise.

Vendor-specific things are just that – things implemented in a particular way by only one vendor.  An example from Robert, Rakesh and Tarek’s document might be attribute-sets, which may not have an obvious parallel in other vendors’ gear.  If nothing else there needs to be someplace a vendor can append its own proprietary models.

In the end it may be more productive to do it this way – starting with a minimum set of obviouly common features and working up – than trying to reconcile two fully baked models with very different views of the world.

eric

From: mpls [mailto:[email-masked]] On Behalf Of Tarek Saad (tsaad)
Sent: Thursday, October 16, 2014 9:34 AM
To: Lizhenbin; [email-masked]
Subject: Re: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

Hi Robin,

module: mpls-te

   +--rw tunnels-cfg!

   +--rw lsps-cfg!

   +--rw links-cfg!

   +--rw global-cfg!

   +--ro tunnels-oper

   +--ro lsps-oper

   +--ro links-oper

   +--ro global-oper

rpcs:

   +---x tunnels-rpc

   +---x lsps-rpc

   +---x global-rpc

   +---x links-rpc

notifications:

   +---n tunnels-notif

   +---n lsps-notif

   +---n links-notif

   +---n global-notif

module: mpls-te

   +--rw tunnels-cfg!

   |     +--rw name                    string

   |     +--rw type                    tunnel-type

   |     |     +--rw index             uint8

   |     |     +--rw (type)?

   |     |     |  +--:(dynamic)

   |     |     |  |  +--rw dynamic

   |     |     |  +--:(explicit)

   |     |     |     +--rw explicit

   |     |     |           +--rw index                   uint8

   |     |     +--rw igp-constraint

   |     +--rw lsp-cfg* [index]

   |     |  +--rw index             leafref

   |     |  +--rw priority

   |     |  |  +--rw setup?   uint8

   |     |  |  +--rw hold?    uint8

   |     |  +--rw affinity

   |     |  |     +--rw constraint

   |     |  |           +--rw name    string

   |     |  +--rw path-selection

   |     |  +--rw bfd

   |     |  |  +--rw lsp-ping

   |     |  |     +--rw class?   uint8

   |     |        +--rw classes*   uint8

   |     +--rw auto-bandwidth

   |     +--rw (announce-as)?

   |     |  +--:(autoroute)

   |     |  |  +--rw autoroute!

   |     |  |        +--:(metric)

   |     +--rw bidirectional

   |        +--rw association

   |           +--rw id?              uint32

   +--rw global-cfg!

Regards,
Tarek

Hi MPLSer,

Best Regards,
Zhenbin(Robin)

Best Regards,
Zhenbin(Robin)

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 17 Oct 2014 23:17:45 +0000

Hi Eric,

We definitely agree with your feedback. We already realize that standardizing any YANG model has to be as generic as possible.
This is why we are trying to detach ourselves from any particular implementation including ours.
We want to cover the TE aspects from logical point of view. We are also aiming to cover the standards in terms of the model contents and naming.
Moreover, we try to have models that incorporate some of the other vendors  strong points even if they are not present in our implementation.

We started talking to the authors of draft-chen-mpls-te-yang-cfg-00 and we are looking to connect with other vendors as well to join the effort.

Regards
Robert, Rakesh and Tarek

From: <Osborne>, Eric <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 16 October, 2014 3:18 PM
To: "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, Lizhenbin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

eric

From: mpls [mailto:[email-masked]] On Behalf Of Tarek Saad (tsaad)
Sent: Thursday, October 16, 2014 9:34 AM
To: Lizhenbin; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

Hi Robin,

module: mpls-te

   +--rw tunnels-cfg!

   +--rw lsps-cfg!

   +--rw links-cfg!

   +--rw global-cfg!

   +--ro tunnels-oper

   +--ro lsps-oper

   +--ro links-oper

   +--ro global-oper

rpcs:

   +---x tunnels-rpc

   +---x lsps-rpc

   +---x global-rpc

   +---x links-rpc

notifications:

   +---n tunnels-notif

   +---n lsps-notif

   +---n links-notif

   +---n global-notif

module: mpls-te

   +--rw tunnels-cfg!

   |     +--rw name                    string

   |     +--rw type                    tunnel-type

   |     |     +--rw index             uint8

   |     |     +--rw (type)?

   |     |     |  +--:(dynamic)

   |     |     |  |  +--rw dynamic

   |     |     |  +--:(explicit)

   |     |     |     +--rw explicit

   |     |     |           +--rw index                   uint8

   |     |     +--rw igp-constraint

   |     +--rw lsp-cfg* [index]

   |     |  +--rw index             leafref

   |     |  +--rw priority

   |     |  |  +--rw setup?   uint8

   |     |  |  +--rw hold?    uint8

   |     |  +--rw affinity

   |     |  |     +--rw constraint

   |     |  |           +--rw name    string

   |     |  +--rw path-selection

   |     |  +--rw bfd

   |     |  |  +--rw lsp-ping

   |     |  |     +--rw class?   uint8

   |     |        +--rw classes*   uint8

   |     +--rw auto-bandwidth

   |     +--rw (announce-as)?

   |     |  +--:(autoroute)

   |     |  |  +--rw autoroute!

   |     |  |        +--:(metric)

   |     +--rw bidirectional

   |        +--rw association

   |           +--rw id?              uint32

   +--rw global-cfg!

Regards,
Tarek

Hi MPLSer,

Best Regards,
Zhenbin(Robin)

Best Regards,
Zhenbin(Robin)

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Mon, 20 Oct 2014 15:45:52 +0000

I’m inclined to agree.

It strikes me that it’s probably not necessary to do all this in one huge draft, and that it might be a good idea to explicitly break things up. We could therefore create a base draft for the stuff that’s standardized and will (hopefully) not be too controversial, have that move forward as a baseline that everything else can build on, and then have a second (or even several) drafts for the things that are likely to require robust debate prior to arriving at consensus. Having that baseline also allows individual vendors to use it as a base for their own proprietary extensions if they wish.

This also has the advantage (IMHO; YMMV) that it breaks things down into rather more manageable chunks, rather than just having one intimidatingly-large document at the end of a long process…

Cheers

Matt

eric

Hi Robin,

module: mpls-te

   +--rw tunnels-cfg!

   +--rw lsps-cfg!

   +--rw links-cfg!

   +--rw global-cfg!

   +--ro tunnels-oper

   +--ro lsps-oper

   +--ro links-oper

   +--ro global-oper

rpcs:

   +---x tunnels-rpc

   +---x lsps-rpc

   +---x global-rpc

   +---x links-rpc

notifications:

   +---n tunnels-notif

   +---n lsps-notif

   +---n links-notif

   +---n global-notif

module: mpls-te

   +--rw tunnels-cfg!

   |     +--rw name                    string

   |     +--rw type                    tunnel-type

   |     |     +--rw index             uint8

   |     |     +--rw (type)?

   |     |     |  +--:(dynamic)

   |     |     |  |  +--rw dynamic

   |     |     |  +--:(explicit)

   |     |     |     +--rw explicit

   |     |     |           +--rw index                   uint8

   |     |     +--rw igp-constraint

   |     +--rw lsp-cfg* [index]

   |     |  +--rw index             leafref

   |     |  +--rw priority

   |     |  |  +--rw setup?   uint8

   |     |  |  +--rw hold?    uint8

   |     |  +--rw affinity

   |     |  |     +--rw constraint

   |     |  |           +--rw name    string

   |     |  +--rw path-selection

   |     |  +--rw bfd

   |     |  |  +--rw lsp-ping

   |     |  |     +--rw class?   uint8

   |     |        +--rw classes*   uint8

   |     +--rw auto-bandwidth

   |     +--rw (announce-as)?

   |     |  +--:(autoroute)

   |     |  |  +--rw autoroute!

   |     |  |        +--:(metric)

   |     +--rw bidirectional

   |        +--rw association

   |           +--rw id?              uint32

   +--rw global-cfg!

Regards,
Tarek

Hi MPLSer,

Best Regards,
Zhenbin(Robin)

Best Regards,
Zhenbin(Robin)

---

From: Alia Atlas <[email-masked]>
Date: Mon, 20 Oct 2014 12:12:25 -0400

One of the advantages of YANG is its extensibility.  I think that this
suggestion of breaking up the
work is quite useful.  I also expect that we may see some good groupings
that are suitable for reuse
in different YANG models.

I would encourage anyone working on YANG models in the Routing Area to also
join the [email-masked]
mailing list so that we can get common discussion and coordination.

Regards,
Alia

On Mon, Oct 20, 2014 at 11:45 AM, Matt Hartley (mhartley) <
[email-masked]> wrote:

>  I’m inclined to agree.
>
>
>
> It strikes me that it’s probably not necessary to do all this in one huge
> draft, and that it might be a good idea to explicitly break things up. We
> could therefore create a base draft for the stuff that’s standardized and
> will (hopefully) not be too controversial, have that move forward as a
> baseline that everything else can build on, and then have a second (or even
> several) drafts for the things that are likely to require robust debate
> prior to arriving at consensus. Having that baseline also allows individual
> vendors to use it as a base for their own proprietary extensions if they
> wish.
>
>
>
> This also has the advantage (IMHO; YMMV) that it breaks things down into
> rather more manageable chunks, rather than just having one
> intimidatingly-large document at the end of a long process…
>
>
>
> Cheers
>
>
>
> Matt
>
>
>
> I looked at both documents.  They both have some good and some bad.  The
> hardest part in reconciling them will be that they both have a very
> vendor-specific view of the world.  This is no surprise given the nature of
> the technology, and I don’t think it’s unique to TE.  BGP will be at least
> as hard to sort out.
>
>
>
> I think we need to clearly delineate between standard features, common
> features, and vendor-specific ones.  Standard features might be scoped to
> anything that is both signaled and RFC’d, e.g., [3209, 4420, 4875, 5712,
> 7308].
>
>
>
> Common are things that may have different names and which aren’t signaled,
> but which are in use in many/most/all implementations – things like what
> one vendor calls ‘autoroute announce’ and another calls ‘igp shortcuts’.
> Find a common name, or a way to use both, and build a model for the subset
> of things that is most common across vendors.  This is a bit of a quagmire
> since different vendors will have different approaches to many details of
> common features, and it may be the most difficult part of this whole
> exercise.
>
>
>
> Vendor-specific things are just that – things implemented in a particular
> way by only one vendor.  An example from Robert, Rakesh and Tarek’s
> document might be attribute-sets, which may not have an obvious parallel in
> other vendors’ gear.  If nothing else there needs to be someplace a vendor
> can append its own proprietary models.
>
>
>
> In the end it may be more productive to do it this way – starting with a
> minimum set of obviouly common features and working up – than trying to
> reconcile two fully baked models with very different views of the world.
>
>
>
>
>
>
>
>
>
>
>
> eric
>
>
>
>
>
>
>
>
>
> *From:* mpls [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Tarek Saad (tsaad)
> *Sent:* Thursday, October 16, 2014 9:34 AM
> *To:* Lizhenbin; [email-masked]
> *Subject:* Re: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00
> and draft-chen-mpls-te-yang-cfg-00
>
>
>
> Hi Robin,
>
>
>
> Thanks for the reference to the draft. We had a look at it. We are
> proposing a slightly different model that introduces clear delineation
> between configuration, operational (state), RPC (executional), and
> notifications for MPLS-TE tunnels, lsps, links, and global data:
>
>
>
> module: mpls-te
>
>    +--rw tunnels-cfg!
>
>    +--rw lsps-cfg!
>
>    +--rw links-cfg!
>
>    +--rw global-cfg!
>
>    +--ro tunnels-oper
>
>    +--ro lsps-oper
>
>    +--ro links-oper
>
>    +--ro global-oper
>
> rpcs:
>
>    +---x tunnels-rpc
>
>    +---x lsps-rpc
>
>    +---x global-rpc
>
>    +---x links-rpc
>
> notifications:
>
>    +---n tunnels-notif
>
>    +---n lsps-notif
>
>    +---n links-notif
>
>    +---n global-notif
>
>
>
> We also have a detailed YANG model in-the-works (as per the above) and
> we’re planning to include in the next update of the draft. For example, the
> tunnels YANG model looks something like below.
>
>
>
> As for collaboration, yes, we are willing to consolidate our efforts with
> you to produce the IETF MPLS-TE Yang model.
>
>
>
> module: mpls-te
>
>    +--rw tunnels-cfg!
>
> *From: *Lizhenbin <[email-masked]>
> *Date: *Tuesday, October 14, 2014 at 11:12 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and
> draft-chen-mpls-te-yang-cfg-00
>
>
>
> Hi MPLSer,
>
> I would like to remind you of the other two Yang model drafts:
> draft-chen-mpls-te-yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00. Welcome
> comments and collaboration.
>
>
>
> Best Regards,
>
> Zhenbin(Robin)
>
>
>
>
>
>
>
>
>
>
>
> *发件人**:* mpls [mailto:[email-masked] <[email-masked]>] * 代表
> *Lizhenbin
> *发送时间:* 2014年10月14日 22:34
> *收件人:* [email-masked]; [email-masked]; [email-masked]
> *抄送:* [email-masked]
> *主题:* [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and
> draft-chen-mpls-te-yang-cfg-00
>
>
>
> I just saw you proposed the draft-gandhi-mpls-te-yang-model-00. I wonder
> if you are aware of the draft-chen-mpls-te-yang-cfg-00 we proposed on
> August 15. From our point of view, we are not experienced enough to remind
> our MPLSers of the new draft to propose possible discussion and
> collaboration. I compared the two drafts as follows:
>
>      4.1.  Global MPLS-TE Data Model Overview . . . . . . . . . . . .
> 4       -->         MPLS TE Global Configuration/RSVP-TE Global
> Configuration
>
>      4.4.  MPLS-TE Link Data Model Overview . . . . . . . . . . . . .
> 8        -->         MPLS TE Link Configuration/RSVP-TE Interface
> Configuration
>
> 2. draft-chen-mpls-te-yang-cfg-00 defines following configuration Yang
> beyond draft-gandhi-mpls-te-yang-model-00.
>
> 3. draft-chen-mpls-te-yang-cfg-00 has already defined all Yang model for
> these listed configuration while draft-gandhi-mpls-te-yang-model-00 leaves
> many Yang Model definition as spaces.
>
>
>
> I think maybe you are not aware of the existing draft. If you would like
> to cooperate on the MPLS TE Yang Models definition, we are very glad to
> discuss with you to try to unify these Yang models.
>
>
>
>
>
>
>
> Best Regards,
>
> Zhenbin(Robin)
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 23 Oct 2014 10:06:16 +0200

Folks,

I tend to agree with Matt, what we need is not merging of drafts as
much as merging of the effort and coordination between the drafts.

/Loa

On 2014-10-20 17:45, Matt Hartley (mhartley) wrote:
> I’m inclined to agree.
>
> It strikes me that it’s probably not necessary to do all this in one
> huge draft, and that it might be a good idea to explicitly break things
> up. We could therefore create a base draft for the stuff that’s
> standardized and will (hopefully) not be too controversial, have that
> move forward as a baseline that everything else can build on, and then
> have a second (or even several) drafts for the things that are likely to
> require robust debate prior to arriving at consensus. Having that
> baseline also allows individual vendors to use it as a base for their
> own proprietary extensions if they wish.
>
> vendor-specific view of the world.  This is no surprise given the nature
> of the technology, and I don’t think it’s unique to TE.  BGP will be at
> least as hard to sort out.
>
> features, and vendor-specific ones.  Standard features might be scoped
> to anything that is both signaled and RFC’d, e.g., [3209, 4420, 4875,
> 5712, 7308].
>
> Common are things that may have different names and which aren’t
> signaled, but which are in use in many/most/all implementations – things
> like what one vendor calls ‘autoroute announce’ and another calls ‘igp
> shortcuts’.  Find a common name, or a way to use both, and build a model
> for the subset of things that is most common across vendors.  This is a
> bit of a quagmire since different vendors will have different approaches
> to many details of common features, and it may be the most difficult
> part of this whole exercise.
>
> Vendor-specific things are just that – things implemented in a
> particular way by only one vendor.  An example from Robert, Rakesh and
> Tarek’s document might be attribute-sets, which may not have an obvious
> parallel in other vendors’ gear.  If nothing else there needs to be
> someplace a vendor can append its own proprietary models.
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Tarek Saad (tsaad)
> *To:* Lizhenbin; [email-masked] <mailto:[email-masked]>
> we’re planning to include in the next update of the draft. For example,
> the tunnels YANG model looks something like below.
>
> As for collaboration, yes, we are willing to consolidate our efforts
> with you to produce the IETF MPLS-TE Yang model.
>
> module: mpls-te
>
>     +--rw tunnels-cfg!
>
> *From: *Lizhenbin <[email-masked] <mailto:[email-masked]>>
> *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> draft-chen-mpls-te-yang-cfg-00 and draft-zhang-mpls-tp-yang-oam-00.
> Welcome comments and collaboration.
>
> Best Regards,
>
> Zhenbin(Robin)
>
> *发件人**:*mpls [mailto:[email-masked]] *代表 *Lizhenbin
> *收件人:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *抄送:* [email-masked] <mailto:[email-masked]>
> August 15. From our point of view, we are not experienced enough to
> remind our MPLSers of the new draft to propose possible discussion and
> these listed configuration while draft-gandhi-mpls-te-yang-model-00
> leaves many Yang Model definition as spaces.
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64