The MPLS-OPS Archive

[Archana Suresh <archanas@huawei.com>]

Please find the reply inline.

regards,
Archana Suresh


----- Original Message -----
From: "Andreas S" <dg6gai@gmail.com>
To: <mpls-ops@mplsrc.com>
Sent: Monday, May 16, 2005 3:20 PM
Subject: [MPLS-OPS]: Newbie Questions


> Hi,
>
> I am quite new to MPLS and have some questions on the FAQ on this
> website and the RFC3031 that might sound stupid to you, but I couldn't
> answer these for myself.
>
>
> A.   LSPs
>
> The FAQ gives an example of a LSP as follows (4f):
> <http://www.mplsrc.com/faq2.shtml#MPLS Components>
>
> |------| 1                                    1 |-----|
> | R1   |--\                                 /---| R5  |
> |------|   \   2          2          2     /    |-----|
>             \|------|   |-----|   |-----| /
>              | R2   |---| R3  |---| R4  |/
>              |------|   |-----|   |-----|
>
> It states that we have two LSPs: R1-R5, and R2-R3-R4.
>
> According to the formal description of the RFC3031 (section 1.15), a
> LSP is defined as follows (I quote the corresponding section
> directly):
>
> "In other words, we can speak of the level m LSP for Packet P as the
> sequence of routers:
> 1. which begins with an LSR (an "LSP Ingress") that pushes on a level m
label,
>
> 2. all of whose intermediate LSRs make their forwarding decision by
> label Switching on a level m label,
>
> 3. which ends (at an "LSP Egress") when a forwarding decision is made
> by label Switching on a level m-k label, where k>0, or when a
> forwarding decision is made by "ordinary", non-MPLS forwarding
> procedures."
>
> According to my interpretation of the above, the R2-R3-R4 path should
> start at R1 and finish at R5, as R1 is the LSR that "pushes on a level
> m label" (m=2, requirement 1), and R5 is the LSR where "a forwarding
> decision is made by label switching on a level m-k label" (requirement
> 3).
>
> Did I get this wrong in some way?


Consider for an FEC, fec1 and R5 is an egress for fec1

Using  LSP2 : R2-R3-R4.
        R4 will communicate a label lab22 to R3.
        R3 will communicate a label lab21 to R2
        [R2 & R3 and R3 & R4 could be LDP peers or RSVP peers]
Consider an unlabled packet for fec1 enters at R2 label lab21 is pushed.
At R3 lab21 is swapped with lab22.
At R4 lab22 is popped. From R4 to R5 its an unlabled packet.

Using LSP1: R1--R5
        R5 will directly communicate a label lab11 for fec1 to R1
        [R1 and R5 could be a BGP peersl or LDP targetted peers.]
Consider an unlabled packet for fec1.
This packet enters at R1 label lab11 is pushed.
        At R2 label lab21 is pushed. Now the packet has label at 2 levels
(label stack).
        At R3 the uppermost level label lab21  is realised and swapped with
lab22.
        At R4 the uppermost level label  lab22 is popped.
This time from R4 to R5 its a labled packet. At R5 lab11 is popped.
The actual path taken is  [R1-(R2-R3-R5)-R5], a case os LSP within an LSP

>
>
> B.   k > 0
>
> This leads me to my next question:
> A mentioned above, the LSP ends when a forwarding decision is based on
> a m-k level label, whereas k>0. As far as I understand, k should be
> always 1, which still satisfies the condition of k>0, but in which
> situations can k be 2, 3 or whatever?
>
>
Consider
R1---R2                                                     R11----R12
          |                                                          |
         R3----R4-----R5        R8----R9-----R10
                                 |           |
                                R6 ---- R7
LSP1 : R1--R2--R11--R12
LSP2 : R3-R4-R5-R8-R9-R10
LSP3 : R6-R7
Here the label stack goes to 3 levels (m).
So k can take greater values than 1.


> C.   Same label for different FECs at one LSR
>
> The RFC3031 (3.1) states that a LSR may only accept the same label for
> different FECs from different routers, if it can tell from which
> router the packet came (so far so good). Is there any advantage in
> doing so (apart from saving label values) and is there any
> implementation out there that uses it in this way? To me, it just adds
> avoidable complexity...
>
Not aware of any other advantage except for saving label space.
The same label drawn from a global label space, can be advertised  to all
upstream lsrs for an fec.

>
> D.   FEC-to-NHLFE Map (FTN)
>
> I was wondering if there is any use for the FTN other than in MPLS
> Ingress LSRs? Or, need/have interior LSR a FTN at all?
>
>
FTN is used at the Ingress LSRs only.


> Feedback and clarification on any of these issues would be appreciated.
>
> Thanks for your help!
>
> Regards,
>  Andreas
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
> MPLScon 2005 - May 16-19, NYC, NY
> http://www.mplscon.com/

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

MPLScon 2005 - May 16-19, NYC, NY
http://www.mplscon.com/