The MPLS WG Archive

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

Hi Chasey,

Thanks for the comments.

> Subject: Re:[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txt to become
> a working group document?
>
> few humble questions
> (tell me if am wrong fundamentally):
>
> 1. why the draft doesnt talk about segment OAM though for PMP
scalability
> as an issue?

Scalability is as much a requirement for P2MP as for P2P. In fact, since
the nature of P2MP is that there are more egresses per LSP, scalability
must be given considerably more attention.

You specifically ask about "segment OAM" so I wondered if you were
referring to a technique already described in
draft-ietf-mpls-oam-requirements, but I can't find any reference there. So
perhaps you are suggesting some new behaviors and requirements specific to
P2MP?

Maybe if you could spell out what you are thinking about in a little more
detail we could consider incorporating it into a future version of the
draft.

> 2. why there is no mention of OAM procedure for backup tunnel
> (especially for facility protection when one path can backup multiple
> paths, hence should never go down ideally)

I am not clear why your question is specific to P2MP. But I am also not
clear why you single out facility backup tunnels as being more critical
than other tunnels. The importance of a tunnel depends on the use to which
it is put, and it is quite possible that many tunnels are more critical
than facility backup tunnels.

Further, your comment says that a facility backup tunnel "should never go
down ideally". But you must observe that we are talking about OAM. OAM
does not prevent tunnels from going down. It simply allows you to detect
and isolate faults (conversely to monitor the continued absence of
faults).

Again, perhaps you could indicate what you would like to see described in
the draft so that we can look at how to include it.

Thanks,
Adrian


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