Re: [mpls] 答复: Regarding draft-gandhi-mpls-te-yang-model-00 and draft-chen-mpls-te-yang-cfg-00

[Loa Andersson <[e-mail]>]

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.
>
> 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:[e-mail]] *On Behalf Of *Tarek Saad (tsaad)
> *Sent:* Thursday, October 16, 2014 9:34 AM
> *To:* Lizhenbin; [e-mail] <mailto:[e-mail]>
> *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!
>
>     |  +--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 <[e-mail] <mailto:[e-mail]>>
> *Date: *Tuesday, October 14, 2014 at 11:12 AM
> *To: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
> <mailto:[e-mail]>>
> *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:[e-mail]] *代表 *Lizhenbin
> *发送时间:* 2014年10月14日 22:34
> *收件人:* [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *抄送:* [e-mail] <mailto:[e-mail]>
> *主题:* [mpls] Regarding draft-gandhi-mpls-te-yang-model-00 and
> draft-chen-mpls-te-yang-cfg-00
>
> 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)
>
>
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]