Skip to content

Home

Jump to bottom Edit New page
ietf-mpls-yang edited this page Jul 21, 2015 · 9 revisions

MPLS-TE YANG Model.

Welcome to the IETF MPLS-TE YANG model wiki.

IETF93 TE team meeting with Open-config MPLS consolidated team:

Minutes:

  • RSVP Refresh reduction yang grouping – how this maps to juniper config. Ina to send config snippets for this mapping.
  • RSVP statistics (packet counters, errors, etc.) do not map well into Juniper existing model – should we split into core and extended? What is the Juniper behaviour for not supported stats today if IETF Yang model grouping is used. * Protocol messages, hello stats, error stats. Ina to send the list of stats Google cares about to Pavan.
  • Plan is to start importing grouping from IETF model into openconfig model as next steps.
  • Vendor should provide deviations from the IETF model for each grouping item.
  • Auto-tunnel: Option 1: Auto-tunnel at the same branch as static tunnels. Rejected by router if management tries to change the config , Option2: automatic-tunnels separate branch (hierarchy) – read only config. Ina to socialize internally and provide feedbacks.
  • Templates: Option 1. Create a template, applied to the container (like apply groups). If template changes, actual config of the tunnel not changes. Option 2. if template changes, tunnel is affected. Option 3. if user changes the template and some tunnel is using it, we reject the config. Ina: option3 is no-go. Transport vendors support option1 – apply once and forget it. Ina to talk to BGP guys and get back.
  • Openconfig MPLS model covers MPLS data-plane. For now, openconfig and IETF will continue to have different hierarchies. This will be revisited later on. Refactor hierarchy to augment the RSVP for the tunnels instead of choice for RSVP and SR, as someone can enable both on the same tunnel and need to prevent that.
  • Openconfig does not care about TP tunnels at this time.
  • Openconfig has defined optical module.
  • Openconfig will use the same MPLS model for the static LSPs. This is already in the published draft. With LDP model, we are in good shape. Need to adapt to openconfig way for config/state and we are good to go. Meeting on 3 weeks as followup. Send Doodle poll for the meeting.

Meeting Information:

  • Meeting A - Every other Thursday, starting 12/10 Meeting Number: 302215356 Webex: URL

  • Meeting B - Every other Wednesday, starting 12/04 Meeting Number: 201725919 Webex: URL

Past Meetings:

Meeting 3 - Wednesday 12/18 @ 7:00pm EST

Minutes:

  1. Based on feedback from last TEAS WG interim meeting, need to migrate generic work to TEAS:

    • by generic it's meant dataplane agnostic (MPLS/GMPLS) not necessarily control plane agnostic
    • possibility of remarking xx-mpls-te.yang to -te-xx.yang

  2. Xia: have implementation where SDN is used to compute a TE path (for IP-TE). BGP is used for doing Traffic-Engineering. MED? path-attributes? to base the path Susan: BGP has flow classification... refer to draft-ietf-idr-te-pm-bgp-01

AI: Pavan to investigate

  1. AI: Tarek to look at what from RSVP-TE should move to RSVP yang model

  2. tentative module list: ietf-xx-te-types.yang ietf-xx-te-base.yang (DP independent) ietf-mpls-te-base.yang (DP packet MPLS specific) (e.g.) ietf-gmpls-otn-te.yang, flex-grid, ethernet ... (outside scope) Zafar: will work on technology-specific GMPLS, e.g. OTN ietf-te-rsvp.yang ietf-rsvp

  3. Pavan: Should TE links be configured under a routing instance?

    • consider the case where same TE link can co-exist under multiple routing instances ** TE link attributes may have to be replicated under each routing instance?
  • consider sending email to rtg-yang for suggestions
  1. layered topologies
  • to review the base netmod-routing-cfg instances -- Susan: investigate drawbacks of putting the links/interface list under the routing instance. Susan: PBR for TE.

Meeting 2 - Wednesday 12/10 @ 7:00pm EST

Meeting Summary

  • team progressed with TE link data model

    1. In addition to the reference models (non-final), the following models were created and checked-in:
    • ietf-mpls-te.yang
    • ietf-mpls-te-types.yang
    • ietf-mpls-te-rsvp.yang

  • Work-in-progress for TE link model was discussed

    • Base MPLS-TE link data reperesentation to be added in ietf-mpls-te.yang
    • RSVP-TE specific link data extensions to be added in ietf-mpls-te-rsvp.yang
    • Common grouping to go in iet-mpls-te-types.yang. Other models can import and reuse.

  • Team to review the checked-in of the models above and make modifications as needed.

    • to discuss changes/additions in next meeting

  • Discussed possibility of having the top of the MPLS-TE tree off a routing instance

  • Tools

  • Next steps/AIs:

    • Team: to review/add/update link data node in the model Pavan will share comments.

  • To use if-feature for vendor specific supported features

  • RSVP Yang model

    • The point of defining RSVP groupings and an RSVP (non-TE) YANG model was discussed a. Need to be able to enable RSVP on interface for non-TE (e.g. IPv4 flows) b. May require defining module in ietf-rsvp.yang. Module ietf-mpls-te-rsvp.yang can import

  • AIs: to send email to alias and ask for WG-chair's thoughts on expanding scope to include ietf-rsvp.yang module

Meetings:

Meeting 1 - Thursday 12/4 @ 7:00pm EST

Meeting Summary

A group of us (from above) met on Thursday 12/4 for the first time to discuss MPLS TE YANG model. Below are minutes/notes. Next meeting is scheduled for next Wednesday 12/10.

  • Next steps/AIs:
    • Team: to check-in all existing YANG models to GitHub: https://github.com/ietf-mpls-yang/te
    • Team: phase 1 to tackle links and link attributes for phase 1
      • team to communicate proposed attributes over email.
      • in-progress model for TE links will be discussed next week
    • Team: to use email to send proposals
    • Tarek: to send an email with minutes to the WG group
      • include invitations for next meetings
    • Tarek: to schedule weekly meeting for next wednesday onwards

Recording of meeting @ https://cisco.webex.com/ciscosales/lsr.php?RCID=7a824854ae304230ab579f6977974239

Meeting minutes/Notes:

  • Meeting organization/time (do we need to meet more often?)

    • Meet weekly,
    • OK to keep Thursday 7:00pm EST
    • Poll for next weekly meeting Wednesday 7:00pm EST
    • Consideration for holidays

  • Scope of our work:

    • MPLS TE YANG model: TE base yang types TE base yang model RSVP-TE extensions to TE base yang model
    • MPLS Tunnels/links: Config, operational/state, notification, rpcs
    • Topology (proposal to handle in another effort in TEAS)

  • Do we need an alias to communicate/send queries?

    • use mpls WG alias as long as manageable (not noisy)
    • may create another alias to use too

  • Agree on tools/process:

    • repository in GitHub: https://github.com/ietf-mpls-yang/te
      • check-in all yang models to date:
        • tagged iet-mpls-te-(1/2/3).yang
      • create ietf-mpls-te.yang
        • to include sanitized/agreed data model to be presented at IETF
      • create common draft draft-common-mpls-te-yang-model
    • review/commit process?
      • Need to converge

  • Divide the work into phases

    • ph1: TE Links: link attributes (local TE links)

      • Admin Groups, Extended Admin Groups (config)
      • SRLGs (config)
      • local/remote identifiers (config)
      • reservable bandwidth (config)
        • RSVP per interface properties
        • etc.
      • CAC (state) -- LSPs admitted on the link

    • ph2: TE Tunnels:

    • ph3: TE LSPs

    • ph4: TE Globals/templates properties

  • Revisit MPLS Yang module(s) hierarchy. Proposal:

+ ietf-mpls-base-types.yang
       |
       + -- ietf-mpls-ldp-types.yang (imports mpls-base-types)
       + -- ietf-mpls-te-types.yang  (imports mpls-base-types)
       + -- ietf-mpls-te-pce-types.yang  (imports mpls-base-types)
       + -- etc.
+ ietf-mpls-base.yang
     + -- ietf-mpls-te-base.yang (augments ietf-mpls-base.yang)
              + -- ietf-mpls-te-rsvp.yang (augments ietf-mpls-te-base.yang)
              + -- ietf-gmpls-te.yang (augments ietf-mpls-te-base.yang ? augments ietf-mpls-te-rsvp.yang, both ?)
                    - encoding types (PSC, LSC, FSC, etc.)?
                    - OTN/Optical
+ ietf-mpls-oam
    - the MPLS OAM YANG model (to augment MPLS-TE model whenever needed)
  • Where does MPLS data plane YANG state sit?
    • In respective MPLS Yang models — identified with data plane distinguisher (?)
    • data/control plane state and data plane state may not be in sync always (e.g. in transient post FRR)

How to pull

You can download the yang code in a tar ball or zip bundle:

$ cd your_repo_root/repo_name
$ git fetch origin
$ git checkout gh-pages
Add a custom footer
Add a custom sidebar
Clone this wiki locally