Re: [mpls] MPLS Base YANG Module

[Loa Andersson <[e-mail]>]

Tarek,

We've used push, swap and pop, since the beginning of MPLS,
what is the reason to rename "push" to "impose" now?

What is the difference between 3 and 4 below?

/Loa


On 2017-01-24 22:05, Tarek Saad (tsaad) wrote:
> 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] <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
>
>
>
> _______________________________________________
> 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]