Re: [mpls] MPLS Base YANG Module

["Acee Lindem (acee)" <[e-mail]>]

Hi Tarek,

From: "Tarek Saad (tsaad)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, January 24, 2017 at 9:05 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: MPLS Base YANG Module

Hi Acee,

The MPLS operations we’ve defined are:

1.      impose-and-forward

2.      pop-and-forward (e.g. PHP behavior)

3.      pop-impose-and-forward

4.      swap-and-forward

5.      pop-and-lookup

So, given that this is an augmentation to the IPv4 Unicast RIB and there is no prior label stack, how would any operation other than #1 be valid?


Currently nhlfe-role is defining the path-role: primary, pure-backup, primary-and-backup.
This may equally apply to IP-RIBs (e.g. to cover IP-FRR) too, so we can remove it from mpls augmentation if it can be present in draft-acee-rtgwg-yang-rib-extend-00 (for example).

Ok – we can discuss.

Thanks,
Acee




Regards,
Tarek

From: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, January 23, 2017 at 5:23 PM
To: Tarek Saad <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: MPLS Base YANG Module

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)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, January 19, 2017 at 9:27 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Acee Lindem <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 6, 2017 at 12:33 PM
To: Tarek Saad <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module



From: "Tarek Saad (tsaad)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 6, 2017 at 12:00 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>
Date: Friday, January 6, 2017 at 11:53 AM
To: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 23, 2016 at 12:59 PM
To: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Tarek Saad <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Friday, December 23, 2016 at 12:59 PM



From: Rtg-dt-yang-arch <[e-mail]<mailto:[e-mail]>> on behalf of Acee Lindem <[e-mail]<mailto:[e-mail]>>
Date: Friday, December 23, 2016 at 12:52 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: RTG YANG Design Team <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>
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