Re: [mpls] MPLS Base YANG Module

"Acee Lindem (acee)" <acee@cisco.com> Mon, 23 January 2017 22:23 UTC

Return-Path: <acee@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3425A129994; Mon, 23 Jan 2017 14:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level:
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkYrg6N6vXqM; Mon, 23 Jan 2017 14:23:28 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3D3129991; Mon, 23 Jan 2017 14:23:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49004; q=dns/txt; s=iport; t=1485210207; x=1486419807; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZervPT1tAxI2fkj8QDbszplBW4kVXsYLdJ1hmvLtB8k=; b=JoFTOZkImVO26RGonb3+QdvgQN9BlvoX5a8p21pSVpem7cOzpL3PF0ZO 3qx25F7jowKVYx8QZt7jer6DexG3XNl9EduZ+3gyhxVNmX78BAcFlkIOl /LDbN+sMYjoFUE2B1HEoOsDhlbfOJjeKG2IEZp9EKs7IEa72X/OC5cF8z 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQAQgoZY/4gNJK1VCRkBAQEBAQEBAQEBAQcBAQEBAYJvTgEBAQEBH2CBCQeNVJIFiAaLGYIPgg0qhXgCggQ/GAECAQEBAQEBAWMohGkBAQEDAWcSEAIBCBEDAQIhAQYHIREUCQgCBAENBYhxAxAIDq9VK4cSDYMRAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWLOoJRgUEQRxaFLgWIeIY0gUaKITgBhmGHAIQIkG6KH4RChBQBHziBRxU6hjZzAYcOgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.33,275,1477958400"; d="scan'208,217";a="198984689"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jan 2017 22:23:26 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0NMNPlS023879 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Jan 2017 22:23:26 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Jan 2017 17:23:22 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 23 Jan 2017 17:23:22 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Tarek Saad (tsaad)" <tsaad@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS Base YANG Module
Thread-Index: AQHScs0qTJTiarlCFkWDmymLFHzAAKFGqPMA
Date: Mon, 23 Jan 2017 22:23:22 +0000
Message-ID: <D4ABEA82.9905B%acee@cisco.com>
References: <495ABB60-04F9-4ADC-95B0-4081DDA05E0D@cisco.com>
In-Reply-To: <495ABB60-04F9-4ADC-95B0-4081DDA05E0D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: multipart/alternative; boundary="_000_D4ABEA829905Baceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/f0qwWQQ5jFqA3y5tHNz-RtOmXcQ>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>
Subject: Re: [mpls] MPLS Base YANG Module
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Jan 2017 22:23:30 -0000

Hi Tarek,

Since these are augmentations to the IPv4 and IPv6 unicast RIBs, what operation would be valid other than imposition (i.e., push)? Also, what is the nhlfe-role? I see the role type defined in the expired base MPLS model.

Thanks,
Acee

From: "Tarek Saad (tsaad)" <tsaad@cisco.com<mailto:tsaad@cisco.com>>
Date: Thursday, January 19, 2017 at 9:27 PM
To: "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Subject: MPLS Base YANG Module

Hi WG/all,

As part of “draft-ietf-mpls-base-yang”, we are trying to model the MPLS FTN, NHLFE and ILM tables in YANG.
One proposal is to augment the IETF routing RIB model (rfc8022) for V4 and V6 RIBs so IP prefix route also carries the additional MPLS route local label and remote label bindings per next-hop.
Below highlights the augmentation of the RIB model for V4/V6. For MPLS cross-connects (non-IP mpls routes), we propose those to reside under a new address-family (MPLS) RIB, by defining a new identity as below.
Let us know if you have feedback/comments on this proposal.


Example IPv4 RIB augmention for MPLS (highlighted in yellow):

   |  +--ro ribs
   |     +--ro rib* [name]
   |        +--ro name              string
   |        +--ro address-family    identityref
   |        +--ro default-rib?      boolean {multiple-ribs}?
   |        +--ro routes
   |        |  +--ro route*
   |        |     +--ro route-preference?          route-preference
   |        |     +--ro next-hop
   |        |     |  +--ro (next-hop-options)
   |        |     |     +--:(simple-next-hop)
   |        |     |     |  +--ro outgoing-interface?      if:interface-state-ref
   |        |     |     |  +--ro v4ur:next-hop-address?   inet:ipv4-address
   |        |     |     |  +--ro mpls:remote-labels*    mpls-label
   |        |     |     |  +--ro mpls:operation?          label-operation
   |        |     |     +--:(special-next-hop)
   |        |     |     |  +--ro special-next-hop?        enumeration
   |        |     |     +--:(next-hop-list)
   |        |     |        +--ro next-hop-list
   |        |     |           +--ro next-hop*
   |        |     |              +--ro outgoing-interface?     if:interface-state-ref
   |        |     |              +--ro v4ur:address?           inet:ipv4-address
   |        |     |              +--ro mpls:index?             string
   |        |     |              +--ro mpls:backup-index?      string
   |        |     |              +--ro mpls:role?              nhlfe-role
   |        |     |              +--ro mpls:outgoing-labels*   mpls-label
   |        |     |              +--ro mpls:operation?         label-operation
   |        |     +--ro source-protocol            identityref
   |        |     +--ro active?                    empty
   |        |     +--ro last-updated?              yang:date-and-time
   |        |     +--ro v4ur:destination-prefix?   inet:ipv4-prefix
   |        |     +--ro mpls:local-label?       mpls-label


For MPLS cross-connects (non-IP mpls routes), we propose to reside under a new address-family (MPLS) RIB, by defining a new identity as below:

  identity mpls {
    base rt:address-family;
    description
      "This identity represents the MPLS address family.";
  }

Regards,
Tarek

From: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
Date: Friday, January 6, 2017 at 12:33 PM
To: Tarek Saad <tsaad@cisco.com<mailto:tsaad@cisco.com>>, "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>, "xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>" <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module



From: "Tarek Saad (tsaad)" <tsaad@cisco.com<mailto:tsaad@cisco.com>>
Date: Friday, January 6, 2017 at 12:00 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>, "xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>" <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module

Also for completeness, the model in “draft-ietf-i2rs-rib-data-model” seems to present a “single” list of routes that contain all the different route-types (including MPLS routes).. It was mentioned that there are discussions between authors of “draft-ietf-i2rs-rib-data-model” and draft-ietf-netmod-routing-cfg”. Has anything emerged that can help us steer the MPLS augmentation?

You should align with RFC 8022 where there is a separate model per address family.

Thanks,
Acee




   +--rw route-list* [route-index]
      +--rw route-index                uint64
      +--rw match
      |  +--rw (route-type)?
      |     +--:(ipv4)
      |     |  +--rw ipv4
      |     |     +--rw (ip-route-match-type)?
      |     |        +--:(dest-ipv4-address)
      |     |        |  ...
      |     |        +--:(src-ipv4-address)
      |     |        |  ...
      |     |        +--:(dest-src-ipv4-address)
      |     |           ...
      |     +--:(ipv6)
      |     |  +--rw ipv6
      |     |     +--rw (ip-route-match-type)?
      |     |        +--:(dest-ipv6-address)
      |     |        |  ...
      |     |        +--:(src-ipv6-address)
      |     |        |  ...
      |     |        +--:(dest-src-ipv6-address)
      |     |           ...
      |     +--:(mpls-route)
      |     |  +--rw mpls-label              uint32
      |     +--:(mac-route)
      |     |  +--rw mac-address             uint32
      |     +--:(interface-route)
      |        +--rw interface-identifier if:interface-ref

Regards,
Tarek

From: Tarek Saad <tsaad@cisco.com<mailto:tsaad@cisco.com>>
Date: Friday, January 6, 2017 at 11:53 AM
To: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>, "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>, "xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>" <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module

Thanks Acee for your review and comments. The authors met and we discussed your comments, see below for more..

>> I really only have one comment and that is that the “config false” version of interface-mpls need not be replicated in both the rt:routing and rt:routing-state trees.
We discussed this and have some concerns due to potential upcoming changes discussed at netmod group. Xufeng will follow up on this thread regarding this.

>> when some of the MPLS operational state will be added? The obvious examples are the ILM, FTN, and NHLFEs.
We’ve been discussing this, and we have some initial implementation of the tables under mpls @ https://github.com/ietf-mpls-yang/te/blob/master/ietf-mpls.yang.tree.. However, we’re also discussing the possibility of augmenting RIB for MPLS routes (see below) as you pointed..

>> One view is that the ILM, FTN, and NHLFEs could be provided via an augmentation to the RIB…
It is possible to have MPLS FTN table realized as an augmentation to existing IPv4 and IPv6 RIBs models defined in “draft-ietf-netmod-routing-cfg”. However, for pure MPLS-routes (keyed by label or aka the ILM table), this would require a new separate list of routes (new address family?) and a new “MPLS” RIB. In section 5.1 of “draft-ietf-netmod-routing-cfg”, the routes have mandatory “destination-prefix” attribute, and one way to have the MPLS route list is to redefine “destination-prefix” so it signifies the MPLS incoming label for MPLS routes. Any thoughts on this?

Regards,
Tarek and co-authors


From: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>
Date: Friday, December 23, 2016 at 12:59 PM
To: "Acee Lindem (acee)" <acee@cisco.com<mailto:acee@cisco.com>>, "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: <jescia.chenxia@huawei.com<mailto:jescia.chenxia@huawei.com>>, <bin_wen@cable.comcast.com<mailto:bin_wen@cable.comcast.com>>, <igor.bryskin@huawei.com<mailto:igor.bryskin@huawei.com>>, <vbeeram@juniper.net<mailto:vbeeram@juniper.net>>, <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>, <rgandhi@cisco.com<mailto:rgandhi@cisco.com>>, <skraza@cisco.com<mailto:skraza@cisco.com>>, Tarek Saad <tsaad@cisco.com<mailto:tsaad@cisco.com>>, <raqib@brocade.com<mailto:raqib@brocade.com>>
Resent-Date: Friday, December 23, 2016 at 12:59 PM



From: Rtg-dt-yang-arch <rtg-dt-yang-arch-bounces@ietf.org<mailto:rtg-dt-yang-arch-bounces@ietf.org>> on behalf of Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Date: Friday, December 23, 2016 at 12:52 PM
To: "draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>" <draft-ietf-mpls-base-yang@ietf.org<mailto:draft-ietf-mpls-base-yang@ietf.org>>
Cc: RTG YANG Design Team <rtg-dt-yang-arch@ietf.org<mailto:rtg-dt-yang-arch@ietf.org>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: [Rtg-dt-yang-arch] MPLS Base YANG Module

Hi Authors,

Loa asked if I would do a review of the base MPLS YANG document. I really only have one comment and that is that the “config false” version of interface-mpls need not be replicated in both the rt:routing and rt:routing-state trees. For consistency, I’d recommend removing it from rt:routing.

I’d also ask where and when some of the MPLS operational state will be added? The obvious examples are the ILM, FTN, and NHLFEs.

One view is that the ILM, FTN, and NHLFEs could be provided via an augmentation to the RIB…




Thanks,
Acee