The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Harish,

> How does TTL expiration on the MPLS header work for P2MP LSPs ? If the
> payload is IP, then the ICMP error message (such as time exceeded) is
> tagged and sent along the LSP towards the egress, which would then
> hopefully route the packet towards the source. For P2MP LSPs, wouldn't
this
> packet be replicated across all the branches ? If so, the set of egress
PEs
> that receive this packet might route this packet towards the source. Is
> this an understood behavior for P2MP ? This probably doesn't cause any
> issues at the ingress when it receives multiple similar ICMP error
messages.

Yup. RFC3032 suggests this technique for P2P LSPs where the detecting
router cannot route the ICMP error message back to the source.
What you say about P2MP LSPs is true. Applying this technique would cause
an ICMP error message to be received by all destinations downstream of the
detecting node, and this would result in multiple ICMP error messages
being sent to the source in response to one failed data packet.

I think that the main issue that arrises is that the ingress may be
swamped in some cases.

Any suggestions?

> I'm aware of the draft proposing P2MP extensions for LSP ping. If tools
> such as mtrace are used in IP multicast networks, will these work with
P2MP
> LSPs ?

As far as I recall, mtrace actually operates using unicast addresses, and
is initiated by an egress of the multicast IP flow. [I may be wrong here,
it is a little while since I looked at this.] If what I say is correct,
then the interactions with P2MP MPLS are limited because the mtrace
packets will not use the P2MP LSP.

OK looks like we need some thought on the interaction of mtrace with P2MP
LSP ping. Ideas?

Cheers,
Adrian



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls