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

[Phil Bedard]

I'm not sure about the MX80 but on the MX960 with a DPC you can dedicate a
PFE on one of the DPCs to be used for tunnel services, but you lose the
Ethernet interfaces.  I believe on the newer MPCs you can do the same and
not lose the Ethernet interfaces.  Not sure about support on the MX80
though you'd have to check with Juniper.

Phil 

On 3/1/11 2:50 AM, "Egor Zimin" <lesnix at gmail.com> wrote:

>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