Re: [mpls] input on draft-smack-mpls-rfc4379bis-07.txt

[Balaji Rajagopalan <[e-mail]>]

Hi,

The following email from Kapil has the two questions I brought up after the presentation on the draft status at IETF-94.

We think these two recommendations are also candidates for 4397-bis. Please let us know your view.

—
Balaji Rajagopalan




-----Original Message-----
From: Kapil Arora
Sent: Friday, October 30, 2015 3:40 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Ramesh Kandula <[e-mail]<mailto:[e-mail]>>; Balaji Rajagopalan <[e-mail]<mailto:[e-mail]>>; Chandrasekar Ramachandran <[e-mail]<mailto:[e-mail]>>
Subject: input on draft-smack-mpls-rfc4379bis-07.txt

Hi Authors,
I have some input on draft-smack-mpls-rfc4379bis-07.txt regrading RSVP p2mp lsp ping and mpls traceroute in pipe mode.

1. Correlation of mpls echo responses for RSVP p2mp lsps:
For P2mp Lsps when mpls ping is initiated from the ingress router it reaches all the egress routers. Each egress responds with mpls echo response .
For RSVP p2mp lsps ingress router has the knowledge of all the egress routers because of the configuration, so it makes sense to correlate the echo response
from each egress with configured egress at the rsvp p2mp ingress so that ingress router knows if it hasn't got response from one or more egress routers or if
there is a forwarding issue on one or more egress. As per rfc 4379 source address of the echo response packet can be any routable address so it becomes difficult
for the ingress router to correlate from the source address of the echo response packet with one of the configured egress address. If the egress can respond with
destination address of the sub lsp as the source address of the echo response packet, ingress router can correlate all the echo responses and would be able to
isolate the failure if exists for one or more branch.

2. Mpls traceroute Pipe mode:
Consider the topology below for the reference

R1---------R2------R3-----P-------R4---------R5----R6--------R7
<----BGP AS 100----><-----BGP AS 200---------><--BGP AS 100-->
Mpls traceroute expects echo reply via IP. So say we want to run BGP traceroute in the topology mentioned above.
In the above topology if we want to run BGP traceroute from R1 to BGP FEC R7 then as per rfc 4379 all the nodes
should have IP connectivity to R1 which may not be true practically, All the routers in other  AS may not have IP
connectivity to BGP Ingress (R1) but it is fair to assume that all BGP speaking nodes (R1, R3, R4, R7) will have IP
connectivity to BGP ingress so for these kind of scenarios we can introduces the traceroute in pipe mode. If R1 initiates
a BGP traceroute in pipe mode towards FEC R7 then R1 should set the outer TTL =255 (Transport header TTL) and should
set the inner TTL to TTL=1 (BGP label TTL value) and add the BGP FEC in the mpls echo request. So TTL will expire
only at BGP speaking node i.e. R3 and R3 should validate the BGP FEC and R3 should set the Downstream interface address in
DDMT to the address of R4's address (BGP next hop address) and not the P routers address. R3 can make the decision
to working in pipe mode only if no-propogate-ttl is configured. If no-propogate-ttl is not configured then R3 can work as per rfc
6424 and send FEC stack change depending on if its entering to a new transport tunnel or not.


Thanks
Kapil Arora