Re: [mpls] MPLS Base YANG Module

["Rajiv Asati (rajiva)" <[e-mail]>]

>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.

This proposal is very reasonable. Label Imposition operation would be relevant to the RIB.

FWIW, NHLFE role would be relevant even for non-IP, so might be ok to keep it within the base.

>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.

Why put it within RIB AF? 

Also, what were the reasons that mpls-base-yang didn’t let ietf-mpls module augment ietf-interfaces [rfc7233] directly (similar to how ietf-ip and ietf-ipv6 did)? After all, MPLS forwarding, similar to (and independent of) IPv4 or IPv6 forwarding, would need to be enabled on the interface.


     +--rw if:interfaces
        +--rw if:interface* [name]
           ...
           +--rw ipv4!
           |  +--rw enabled?            boolean
           |  +--rw forwarding?         boolean
…
           +--rw mpls!
           |  +--rw enabled?            boolean
           |  +--rw forwarding?         Boolean
…
-- 
Cheers,
Rajiv  

-----Original Message-----
From: mpls <[e-mail]> on behalf of "Tarek Saad (tsaad)" <[e-mail]>
Date: Tuesday, January 24, 2017 at 9:05 AM
To: "Acee Lindem (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: RTG YANG Design Team <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [mpls] 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
     
    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).
     
    Regards,
    Tarek
     
    From: "Acee Lindem (acee)" <[e-mail]>
    Date: Monday, January 23, 2017 at 5:23 PM
    To: Tarek Saad <[e-mail]>, "[e-mail]" <[e-mail]>
    Cc: RTG YANG Design Team <[e-mail]>, "[e-mail]" <[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]>
    Date: Thursday, January 19, 2017 at 9:27 PM
    To: "[e-mail]" <[e-mail]>
    Cc: RTG YANG Design Team <[e-mail]>, "[e-mail]" <[e-mail]>,
     Acee Lindem <[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]>
    >Date: Friday, January 6, 2017 at 12:33 PM
    >To: Tarek Saad <[e-mail]>, "[e-mail]" <[e-mail]>
    >Cc: RTG YANG Design Team <[e-mail]>, Loa Andersson <[e-mail]>, "[e-mail]" <[e-mail]>
    >Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
    >
    > 
    >
    > 
    >
    > 
    >
    >From:
    >"Tarek Saad (tsaad)" <[e-mail]>
    >Date: Friday, January 6, 2017 at 12:00 PM
    >To: Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
    >Cc: RTG YANG Design Team <[e-mail]>, Loa Andersson <[e-mail]>, "[e-mail]" <[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]>
    >>Date: Friday, January 6, 2017 at 11:53 AM
    >>To: "Acee Lindem (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>
    >>Cc: RTG YANG Design Team <[e-mail]>, Loa Andersson <[e-mail]>, "[e-mail]" <[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]>
    >>Date: Friday, December 23, 2016 at 12:59 PM
    >>To: "Acee Lindem (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>
    >>Cc: RTG YANG Design Team <[e-mail]>, Loa Andersson <[e-mail]>
    >>Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
    >>Resent-From: <[e-mail]>
    >>Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>,
    >> <[e-mail]>, <[e-mail]>, <[e-mail]>, Tarek Saad <[e-mail]>,
    >> <[e-mail]>
    >>Resent-Date: Friday, December 23, 2016 at 12:59 PM
    >>
    >> 
    >>
    >> 
    >>
    >> 
    >>
    >>From:
    >>Rtg-dt-yang-arch <[e-mail]> on behalf of Acee Lindem <[e-mail]>
    >>Date: Friday, December 23, 2016 at 12:52 PM
    >>To: "[e-mail]" <[e-mail]>
    >>Cc: RTG YANG Design Team <[e-mail]>, Loa Andersson <[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 
    >>>
    >>>
    >>>
    >>
    >>
    >
    >