Subject: [mpls] MPLS Base YANG Module

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 20 Jan 2017 03:27:45 +0000

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)" <[email-masked]>
Date: Friday, January 6, 2017 at 12:33 PM
To: Tarek Saad <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: RTG YANG Design Team <[email-masked]>, Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rtg-dt-yang-arch] MPLS Base YANG Module

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

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Jan 2017 22:23:22 +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)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 19, 2017 at 9:27 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: RTG YANG Design Team <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Subject: MPLS Base YANG Module

Hi WG/all,

   |  +--ro ribs
   |     +--ro rib* [name]
   |        +--ro name              string

  identity mpls {
    base rt:address-family;
    description

Regards,
Tarek

To: Tarek Saad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Thanks,
Acee

Regards,
Tarek

Regards,
Tarek and co-authors

Hi Authors,

Thanks,
Acee

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Tue, 24 Jan 2017 14:05:21 +0000

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)" <[email-masked]>
Date: Monday, January 23, 2017 at 5:23 PM
To: Tarek Saad <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: RTG YANG Design Team <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: MPLS Base YANG Module

Hi Tarek,

Thanks,
Acee

Hi WG/all,

   |  +--ro ribs
   |     +--ro rib* [name]
   |        +--ro name              string

  identity mpls {
    base rt:address-family;
    description

Regards,
Tarek

Thanks,
Acee

Regards,
Tarek

Regards,
Tarek and co-authors

Hi Authors,

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Jan 2017 23:31:46 +0000

Hi Tarek,

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

Hi Acee,

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

Ok – we can discuss.

Thanks,
Acee

Regards,
Tarek

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

Hi Tarek,

Thanks,
Acee

Hi WG/all,

   |  +--ro ribs
   |     +--ro rib* [name]
   |        +--ro name              string

  identity mpls {
    base rt:address-family;
    description

Regards,
Tarek

Thanks,
Acee

Regards,
Tarek

Regards,
Tarek and co-authors

Hi Authors,

Thanks,
Acee

---

From: Loa Andersson <[email-masked]>
Date: Wed, 25 Jan 2017 09:34:36 +0800

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:
> 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)" <[email-masked]>
> *Date: *Monday, January 23, 2017 at 5:23 PM
> *To: *Tarek Saad <[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *RTG YANG Design Team <[email-masked]>,
> "[email-masked]" <[email-masked]>
> *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)" <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, January 19, 2017 at 9:27 PM
> *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *RTG YANG Design Team <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>, Acee Lindem
> <[email-masked] <mailto:[email-masked]>>
> *Subject: *MPLS Base YANG Module
>
>
>
>     Hi WG/all,
>
>
>
>     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.
>
>     *_Example IPv4 RIB augmention for MPLS (highlighted in yellow):_*
>
>
>
>        |  +--ro ribs
>
>        |     +--ro rib* [name]
>
>        |        +--ro name              string
>
>     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
>
>     *From: *"Acee Lindem (acee)" <[email-masked] <mailto:[email-masked]>>
>     *Date: *Friday, January 6, 2017 at 12:33 PM
>     *To: *Tarek Saad <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *RTG YANG Design Team <[email-masked]
>     <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
>
>
>
>
>
>
>
>     *From: *"Tarek Saad (tsaad)" <[email-masked] <mailto:[email-masked]>>
>     *Date: *Friday, January 6, 2017 at 12:00 PM
>     *To: *Acee Lindem <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked]
>     <mailto:[email-masked]>"
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *RTG YANG Design Team <[email-masked]
>     <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *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?
>
>
>
>         *From: *Tarek Saad <[email-masked] <mailto:[email-masked]>>
>         *Date: *Friday, January 6, 2017 at 11:53 AM
>         *To: *"Acee Lindem (acee)" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>"
>         <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc: *RTG YANG Design Team <[email-masked]
>         <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         *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..
>
>
>
>         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.
>
>
>
>         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..
>
>
>
>         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)" <[email-masked]
>         <mailto:[email-masked]>>
>         *Date: *Friday, December 23, 2016 at 12:59 PM
>         *To: *"Acee Lindem (acee)" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>"
>         <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc: *RTG YANG Design Team <[email-masked]
>         <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>         <mailto:[email-masked]>>
>         *Subject: *Re: [Rtg-dt-yang-arch] MPLS Base YANG Module
>         *Resent-From: *<[email-masked]
>         <mailto:[email-masked]>>
>         *Resent-To: *<[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, Tarek Saad <[email-masked]
>         <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>
>         *Resent-Date: *Friday, December 23, 2016 at 12:59 PM
>
>
>
>
>
>
>
>         *From: *Rtg-dt-yang-arch <[email-masked]
>         <mailto:[email-masked]>> on behalf of Acee
>         Lindem <[email-masked] <mailto:[email-masked]>>
>         *Date: *Friday, December 23, 2016 at 12:52 PM
>         *To: *"[email-masked]
>         <mailto:[email-masked]>"
>         <[email-masked]
>         <mailto:[email-masked]>>
>         *Cc: *RTG YANG Design Team <[email-masked]
>         <mailto:[email-masked]>>, Loa Andersson <[email-masked]
>         <mailto:[email-masked]>>
>         *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.
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Fri, 27 Jan 2017 05:26:23 +0000

Hi Loa,

On 2017-01-24, 8:34 PM, "Loa Andersson" <[email-masked]> wrote:

    Tarek,
    
    We've used push, swap and pop, since the beginning of MPLS,
    what is the reason to rename "push" to "impose" now?
[TS]: “impose” is quite common too, but I will raise this up in our next meeting and try to converge on “push” instead.
    
    What is the difference between 3 and 4 below?
[TS]: the intention was to distinguish a case where the top label is popped and replaced with a series of labels “pop-impose-and-forward” vs. special case of swap the top label “swap-and-forward”.

Regards,
Tarek
    
    /Loa

    --

---

From: Loa Andersson <[email-masked]>
Date: Fri, 27 Jan 2017 19:32:21 +0800

Tarek,

On the “pop-impose-and-forward” are you saying that what happens is that 
an incoming packet with this label stack:

                                          +-------+
                                          |  Lz   |
                                          +-------+
                                          |  Ly   |
     +-------+                            +-------+
     |  La   |                            |  Lx   |
     +-------+                            +-------+
     |  Lb   |                            |  Lv   |
     +-------+                            +-------+
     |  Lc   |   leaves the LSR as        |  Lc   |
     +-------+                            +-------+
     |  PL   |                            |  PL   |
     |       |                            |       |

That is a pop (La) swap (La to Lv), push (Lx), push (Ly), push(Lx)
operation, right?

So nothing but push, pop, swap.

Why do we need to single out the pop-swap-push(times n)-forward
operation?

/Loa

--