Subject: [mpls-tp] comments on the OAM requirements draft

From: "Rolf Winter" <[email-masked]>
Date: Fri, 10 Jul 2009 17:10:31 +0200

Hi,

While we were working on the OAM framework draft, and in particular on the P2MP case, we stumbled across a bunch of ambiguities or missing pieces in the OAM requirements draft that we felt might need to be addressed before we can progress with the document (and maybe later in the process others might run into similar situations). In particular P2MP has so little requirements attached to it that it is not easy to clearly identify what it really needed in that space. Might be because P2MP is not even strongly required in the first place (SHOULD in the draft). In case P2MP OAM is being provided it would be good if the draft states at least which requirements then apply and which not, i.e. are there requirements in the draft that do not apply from the general section? Or are there additional requirements such as the need to separately monitor a root/leaf relationship in the P2MP case instead of monitoring the whole tree alone etc. I feel the same is true for associated bi-directional and unidirectional LSPs etc which is generally under-represented in the draft. I also see a deviation between the general MPLS-TP reqs and the OAM reqs as according to the general requirements all unidirectional, co-routed bidirectional and associated bidirectional point-to-point transport paths MUST be supported (req 8) but OAM not. Is that a sensible approach? I sometimes feel these documents progress too fast without the proper coordination amongst related documents.

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Fri, 10 Jul 2009 17:11:35 +0100

Good observations Rolf.....I tend to agree.

First point to note is that a 'connection' has a very specific meaning
in an *information* sense, ie a connection MUST only have a single
source.  What this then means practically are things like:

-	the (parent) connection entity itself carries the source
(information) semantic.  This is precisely why (the child) traffic units
in a co-ps mode network can take a short-cut on labelling by omitting SA
information....a condition which is not true when connections do not
exist, ie cl-ps traffic units must carry absolute SA label information.

Aside=> One can also take short-cuts on the forwarding label in co mode
networks, ie the forwarding label only need be link connection (ie
single hop) unique.  Again this is not true when connections do not
exist, eg cl-ps mode case, and once again we must add an absolute DA to
each traffic unit for forwarding purposes.

-	a connection is also the basis of a whole raft of things related
to performance/SLA management of client services because it is a
necessary (albeit not fully sufficient) requirement for deterministic
resource assignment.....which then has a recursive impact on what
performance inheritance means across client/server layer network
relationships.  A connection is also a required basis for the
simple/sparse OAM we operators need in MPLS-TP (or any other co-ps mode
technology for that matter).

Further:

-	only a p2p connection is a truly recursive/atomic construct....a
p2mp connection is not.  This is why one cannot piggy-back BDI OAM
messages in CV OAM message for p2mp constructs, and it is why the OAM in
co mode network needs to be generally of a unidirectional nature (there
is a whole raft of other stuff that follows from this, such as why
request/response OAM won't correctly trace out misconnectivity in co
mode networks, but we need not get into that detail here).

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rolf Winter
> Sent: 10 July 2009 16:11
> To: [email-masked]
> Subject: [mpls-tp] comments on the OAM requirements draft
> 
> Hi,
> 
> While we were working on the OAM framework draft, and in 
> particular on the P2MP case, we stumbled across a bunch of 
> ambiguities or missing pieces in the OAM requirements draft 
> that we felt might need to be addressed before we can 
> progress with the document (and maybe later in the process 
> others might run into similar situations). In particular P2MP 
> has so little requirements attached to it that it is not easy 
> to clearly identify what it really needed in that space. 
> Might be because P2MP is not even strongly required in the 
> first place (SHOULD in the draft). In case P2MP OAM is being 
> provided it would be good if the draft states at least which 
> requirements then apply and which not, i.e. are there 
> requirements in the draft that do not apply from the general 
> section? Or are there additional requirements such as the 
> need to separately monitor a root/leaf relationship in the 
> P2MP case instead of monitoring the whole tree alone etc. I 
> feel the same is true for associated bi-directi
>  onal and unidirectional LSPs etc which is generally 
> under-represented in the draft. I also see a deviation 
> between the general MPLS-TP reqs and the OAM reqs as 
> according to the general requirements all unidirectional, 
> co-routed bidirectional and associated bidirectional 
> point-to-point transport paths MUST be supported (req 8) but 
> OAM not. Is that a sensible approach? I sometimes feel these 
> documents progress too fast without the proper coordination 
> amongst related documents.
> 
> Best,
> 
> 	Rolf
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
>  
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:17:43 +0200

Hi Rolf,

thanks for your comment.
Similarly to the answer I gave to Annamaria and others, we tried to find
the good balance between "solution agnostic" and "solution specific".
The current result of this is the draft as it is today.
Yet, I tend to agree with you that on certain points (e.g. P2MP)
we are too much on the generic side.
We'll see what it is possible to do without ending-up specifying
a solution.

regards,
-m

Rolf Winter a écrit :
> Hi,
> 
> While we were working on the OAM framework draft, and in particular on the P2MP case, we stumbled across a bunch of ambiguities or missing pieces in the OAM requirements draft that we felt might need to be addressed before we can progress with the document (and maybe later in the process others might run into similar situations). In particular P2MP has so little requirements attached to it that it is not easy to clearly identify what it really needed in that space. Might be because P2MP is not even strongly required in the first place (SHOULD in the draft). In case P2MP OAM is being provided it would be good if the draft states at least which requirements then apply and which not, i.e. are there requirements in the draft that do not apply from the general section? Or are there additional requirements such as the need to separately monitor a root/leaf relationship in the P2MP case instead of monitoring the whole tree alone etc. I feel the same is true for associated bi-dire

cti
>  onal and unidirectional LSPs etc which is generally under-represented in the draft. I also see a deviation between the general MPLS-TP reqs and the OAM reqs as according to the general requirements all unidirectional, co-routed bidirectional and associated bidirectional point-to-point transport paths MUST be supported (req 8) but OAM not. Is that a sensible approach? I sometimes feel these documents progress too fast without the proper coordination amongst related documents.
> 
> Best,
> 
> 	Rolf
>