Subject: Re:[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become aworking group document?

From: "chasey_ch" <[email-masked]>
Date: Mon, 12 Dec 2005 00:56:53 +0530

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?
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)

thanks,
chasey

[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become aworking group document?
From: "Sheetal A. Vispute_p05274" <[email-masked]> 
Date: Wed, 7 Dec 2005 12:47:43 +0530 (IST) 
Cc: [email-masked] 

Hi Loa,

yes it very important to become a WG doc

cheers
Sheetal

On Tue, 6 Dec 2005, Loa Andersson wrote:

> All,
>
> In Vancouver we discussed the draft-yasukawa-mpls-p2mp-oam-reqs-01.txt,
> when aksing the room about the consensus on making it a working group
> document, there were good support for making it a working group
> document.
>
> We said that we wanted to confirm this on the list. Please
> send response to this mail to the MPLS mailing list stating whether
> you think it should become a working group document or not.
>
> /Loa
>

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

References: 
[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? 
From: Loa Andersson <[email-masked]>
[mpls] draft-yasukawa-mpls-p2mp-oam-reqs-01.txtto become a workinggroup document? 
From: Loa Andersson <[email-masked]>

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 12 Dec 2005 11:44:03 -0000

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
> 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