[j-nsp] [c-nsp] P2MP LSPs :: TailEnd/Bud nodes behavior

[Egor Zimin]

In my case I have a deal with MX80

2011/3/1 Phil Bedard <philxor at gmail.com>:
> In the Juniper case you can get around the double replication on the M/T
> by using a tunnel services PIC and using a tunnel interface to terminate
> the P2MP LSP.   Just a limitation of the platforms.
>
> Phil
>
> On 2/28/11 10:44 AM, "Egor Zimin" <lesnix at gmail.com> wrote:
>
>>Hello, guys
>>
>>Today I noticed very interesting difference in implementation of P2MP
>>LSPs by Cisco and Juniper.
>>The difference is related to explicit/implicit-null behavior of S2L
>>Sub-LSP tailend routers:
>>Cisco implementation:
>>(http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_te_p2mp_p
>>s6922_TSD_Products_Configuration_Guide_Chapter.html)
>>---
>>The tailend routers allocate unreserved labels, which are greater than
>>15 and do not include implicit or explicit null labels.
>>---
>>
>>In Juniper's implementation tailend allocates implicit/explicit null
>>label as a usual.
>>As a consequence of this, (it looks like) we can have unnecessary
>>replication before "Bud" nodes.
>>
>>For example:
>>Let's consider this configuration:
>>###
>>label-switched-path LSP-P2MP-16--19 {
>>    to 10.245.87.19;
>>    p2mp TREE1;
>>}
>>label-switched-path LSP-P2MP-16--18 {
>>    to 10.245.87.18;
>>    p2mp TREE1;
>>}
>>label-switched-path LSP-P2MP-16--15 {
>>    to 10.245.87.15;
>>    p2mp TREE1;
>>}
>>label-switched-path LSP-P2MP-16--17 {
>>    to 10.245.87.17;
>>    p2mp TREE1;
>>}
>>###
>>> show mpls lsp p2mp ingress
>>Ingress LSP: 1 sessions
>>P2MP name: TREE1, P2MP branch count: 4
>>To              From            State Rt P     ActivePath       LSPname
>>10.245.87.17    10.245.87.16    Up     0 *
>>LSP-P2MP-16--17
>>10.245.87.15    10.245.87.16    Up     0 *
>>LSP-P2MP-16--15
>>10.245.87.18    10.245.87.16    Up     0 *
>>LSP-P2MP-16--18
>>10.245.87.19    10.245.87.16    Up     0 *
>>LSP-P2MP-16--19
>>Total 4 displayed, Up 4, Down 0
>>###
>>As you can see, there are four leaves. Three bottom leaves use the
>>same downstream interface:
>>###
>>> show rsvp session p2mp detail | match "PATH sentto"
>>  PATH sentto: 10.245.87.146 (xe-0/0/2.0) 4 pkts
>>  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
>>  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 2 pkts
>>  PATH sentto: 10.245.87.149 (xe-0/0/1.0) 3 pkts
>>###
>>> show rsvp session p2mp
>>Ingress RSVP: 18 sessions
>>P2MP name: TREE1, P2MP branch count: 4
>>To              From            State   Rt Style Labelin Labelout LSPname
>>10.245.87.17    10.245.87.16    Up       0  1 SE       -        3
>>LSP-P2MP-16--17
>>10.245.87.15    10.245.87.16    Up       0  1 SE       -        3
>>LSP-P2MP-16--15
>>10.245.87.18    10.245.87.16    Up       0  1 SE       -   309200
>>LSP-P2MP-16--18
>>10.245.87.19    10.245.87.16    Up       0  1 SE       -   309200
>>LSP-P2MP-16--19
>>Total 4 displayed, Up 4, Down 0
>>###
>>
>>As you can see, we have two different out labels (3 and 309200) for
>>the same P2MP LSP. Label 3 is allocated by node 10.245.87.15 because
>>of PHP.
>>
>>Can anybody explain, what IETF speaks about this case ? Must tailend
>>routers allocate unreserved label or not ? I can't find any mention of
>>this case in RFCs (4875, 4461).
>>
>>--
>>Best regards,
>>Egor Zimin
>>_______________________________________________
>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>



-- 
Best regards,
Egor Zimin