Subject: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft?

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 10 Nov 2003 22:46:31 -0500

The chairs requested that we take the
matter of adoption of this draft to the
list. Please comment.

	--Tom

http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt

---

From: "David Allan" <[email-masked]>
Date: Wed, 12 Nov 2003 05:28:49 -0500

Tom:

It would be good to see Y.1712 (OAM functionality for ATM-MPLS interworking)
also covered in this draft as it is directly applicable. I'd be glad to
provide suggested edits.

(it was presented as
http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt in
Vienna)

cheers 
Dave

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Monday, November 10, 2003 10:47 PM
> To: [email-masked]
> Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as 
> PWE3 WG draft?
> 
> 
> 

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

---

From: [email-masked]
Date: Wed, 12 Nov 2003 12:06:53 -0000

Dave I agree.  Its also a very simple solution since we have a high degree of functional convergence on both sides.

regards, Neil

> From: David Allan [mailto:[email-masked]]
> Sent: 12 November 2003 10:29
> To: [email-masked]'; [email-masked]'
> Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3
> WG draft?
> 
> 
> Tom:
> 
Vienna)

cheers 
Dave

---

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Nov 2003 08:49:29 -0800

Hi,

The only OAM function that is mappable in a network interworking case (e.g., PW)
is AIS/RDI and up/down state. Any other type of mapping is not only architecturally wrong, but not required.

So I suggest that first we have a debate on the higher level architectural issues
and requirements before accepting this draft.

Yours,
-Shahram

>Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG
>draft?
>
>
>

---

From: [email-masked]
Date: Wed, 12 Nov 2003 17:45:07 -0000

Hi Shahram.....to be strictly accurate here, in a client/server networking I/W case the only server->client OAM function mapping that is relevent is FDI (or AIS in old currency).  RDI stays within the layer/trail it is relevant to.....it has no upwards mapping from server->client in a 'backwards direction' (if you see what I mean) but terminates at the trail sink of the return direction (if one exists).

Otherwise I agree with your remarks.  

regards, Neil
> From: Shahram Davari [mailto:[email-masked]]
> Sent: 12 November 2003 16:49
> To: [email-masked]'; [email-masked]
> is AIS/RDI and up/down state. Any other type of mapping is 
> not only architecturally wrong, but not required.
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Nov 2003 10:04:03 -0800

Right. So only AIS/FDI and Down state are mappable. The down state of MPLS layer (using CV or periodic ping) is used to generate AIS on the client layer (i.e., ATM, or FR). Also an FDI in MPLS layer could be used to generate AIS on client layer (ATM/FR).

If the PEs don't support transport of ATM/FR AIS/RDI, then in theory it is possible (although not architecturally clean) to use some sort of signaling/message in MPLS network to inform the egress PE to generate the AIS/RDI on the ATM/FR connections.

-Shahram

>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, November 12, 2003 12:45 PM
>To: Shahram Davari; [email-masked]; [email-masked]
>Hi Shahram.....to be strictly accurate here, in a 
>client/server networking I/W case the only server->client OAM 
>function mapping that is relevent is FDI (or AIS in old 
>currency).  RDI stays within the layer/trail it is relevant 
>to.....it has no upwards mapping from server->client in a 
>'backwards direction' (if you see what I mean) but terminates 
>at the trail sink of the return direction (if one exists).
>
>> Subject: RE: [PWE3] Adopt 
>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3
>> WG draft?
>> 
>> 
>> Hi,
>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 12 Nov 2003 16:07:57 -0500

Sharam,

Are you commenting on the draft, or are you just guessing what you might find in the draft if you actually read it?

Peter

> Sent: Wednesday, November 12, 2003 12:04 PM
> To: [email-masked]'; [email-masked]; [email-masked]
> Right. So only AIS/FDI and Down state are mappable. The down 
> state of MPLS layer (using CV or periodic ping) is used to 
> generate AIS on the client layer (i.e., ATM, or FR). Also an 
> FDI in MPLS layer could be used to generate AIS on client 
> layer (ATM/FR).
> 
> If the PEs don't support transport of ATM/FR AIS/RDI, then in 
> theory it is possible (although not architecturally clean) to 
> use some sort of signaling/message in MPLS network to inform 
> the egress PE to generate the AIS/RDI on the ATM/FR connections.
> 
> -Shahram
> 
> 
>

---

From: [email-masked]
Date: Wed, 12 Nov 2003 21:57:35 -0000

Hi Shahram, please see below.  regards, Neil

Shahram Davari wrote 
> 
> Right. So only AIS/FDI and Down state are mappable.
NH=> Correct.

> The down 
> generate AIS on the client layer (i.e., ATM, or FR).
NH=> Yes.  This is right architectural relationship.  However, since we also have the notion of PWs in this WG then strictly speaking the mapping is now MPLS_FDI->PW_FDI->client_FDI.  That is, there is an extra layer here to 'map through'.  Further, if there are any defects that can exist in the extra PW layer entity itself then these must also be fully specified in terms of entry/exit criteria and consequent actions.....one of which is the mapping of FDI as we are discussing.  As I have mentioned before, the *adaptation* between any client and server layers should be as simple as possible and the client and server layer networks should be functionally independent.  PWs have Seq No.s defined.  Therefore defects for these must also be defined, ie at what point are Seq No. corruptions considered 'failed'?  This has still not been done and, speaking as an operator, it is not acceptable to leave this open-ended like this.  However, I can also say the same for the MPLS layer, ie the LSPs themselves.  These too need a complete set of defects specifying in terms of entry/exit criteria and consequent actions.  The only place this exists AFAIK is in Y.1711.

> Also an 
NH=> Yes....and if you think about it, since MPLS layer defects can only be detected at an LSP trail termination point, then the only source of an observed FDI on a given LSP would be from a lower layer network trail (which could be a co-cs technology like an SDH VC_4 or a lower layer co-ps LSP).
> the egress PE to generate the AIS/RDI on the ATM/FR connections.
NH=> The answer depends on the I/W relationship, ie whether it is client/server network I/W or peer service I/W.

In the case of simple client/server network I/W the server layer (eg MPLS) should *never* interrupt the client's OAM signals....these are required to pass transparently.  If they don't, this is a serious architectural violation.  So here it should never be an issue (assuming of course FDI is actually specified for the client layer technology considered).

If we have a peer service I/W relationship there is strictly *no* OAM relationship between any of the peer network trails involved....as each terminates it trail's CI (characteristic information) at an IWF, and this includes all its OAM.  However, this requires a FDI mapping to whatever is the common higher layer entity that transparently spans all the underlying peer server layer trails....and the mapping is independent from each peer server layer trail partition to the common higher layer entity.  Most higher layer entities however do not have any such OAM functions defined.  In this case one can relax the strict architectural rules and do what you are suggesting, ie map defects detected in 1 network technology partition to an FDI indicate in the downstream network partition.  However, you must be very careful to make sure this is done correctly.  A good example of this is the OAM I/W defined for ATM (I.610) and MPLS (Y.1711) in Y.1712.  This is also very simple because the harmonisation of these issues was considered early on.  This means we can have simple automatic defect detection/handling between ATM and MPLS technologies......and which is something I'd assume most operators would like to see in place.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 12 Nov 2003 17:28:01 -0600

Although a valid point for discussion, the real question 
should be whether a document in question is useful to the WG 
or not.  If it is, we can discuss the details on the list,
as is normal IETF policy.  

	--Tom

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Shahram Davari
>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt 
>as PWE3 WG draft?
>
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Nov 2003 21:54:08 -0800

No, I have actually read it.

-Shahram

>From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
>Sent: Wednesday, November 12, 2003 4:08 PM
>To: Shahram Davari; [email-masked]'; [email-masked];
>[email-masked]
>Are you commenting on the draft, or are you just guessing what 
>you might find in the draft if you actually read it?
>
>Peter
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Nov 2003 22:03:19 -0800

I think A document on OAM Interworking between PW and ATM/FR is needed.
Does that mean any draft with this title should be accepted?

-Shahram

>Sent: Wednesday, November 12, 2003 6:28 PM
>To: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Wed, 12 Nov 2003 22:11:10 -0800

Tom,

I don't mind accepting the draft as a WG item, as long as major changes in the draft are possible (off course after valid discussions).

Yours,
Shahram

>From: Shahram Davari 
>Sent: Thursday, November 13, 2003 1:03 AM

---

From: [email-masked]
Date: Thu, 13 Nov 2003 09:02:16 -0000

As Dave Allan pointed out earlier, there is a document on ATM and MPLS peer OAM I/W....it is Y.1712.  Its simple and complete.  This should not be ignored.

regards, Neil

> Sent: 13 November 2003 06:03

---

From: [email-masked]
Date: Thu, 13 Nov 2003 09:02:19 -0000

I agree Shahram.  But, speaking as an operator, we need to see defects specified in terms of automatic detection/handling, ie entry/exit criteria and consequent actions.  AFAIK these are not specified in any IETF documentation.  The only place these are specified for MPLS is in Y.1711.  Admittedly this is only for constructs that are architecturally allowed in the co-ps mode.  When the allowed arch of this mode is violated (by mp2p and PHP say) then the OAM problems this causes will require other techniques, eg LSP-Ping.  However, since XoverMPLS *must* always have p2p LSPs above the lower mp2p constructs (as this is the only way to recover from the merging) then one can run the simple Y.1711 OAM flows on these top LSPs.  {Aside - IP is cnls and therefore always uses *multiplexing and not merging*....so these OAM problems do not exist in IP.} If the p2p LSPs show a problem then check out the SDH/Sonet trails..if these show clear then wheel out the complex diagostics tools like LSP-Ping.  This seems a fine solution to me and I'd like to hear what is wrong with it.

Unless Y.1711 etc are properly taken into account I hardly think this WG can be considered to be doing a good job. 

BTW - PWs will also require similar defect detction/handling considerations as the adaptation process here contains 'active' functions like Seq Nos.

regards, Neil

> Sent: 13 November 2003 06:11
> To: Shahram Davari; [email-masked]'; [email-masked]
> I don't mind accepting the draft as a WG item, as long as 
> major changes in the draft are possible (off course after 
> valid discussions).
> 
> Yours,
> Shahram
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 13 Nov 2003 09:12:49 -0500

Did you have a different one in mind? :P  I suppose
we can play semantic games all day, which seems to be
your m.o., but I would rather get some work done in
this area if you don't mind. Several operators and vendors 
have joined in supporting the draft so it seems that there 
is a definite interest in doing this work, which you even admit 
to below. It seems to me that this draft is a good start for 
this work.

	--Tom

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 13 Nov 2003 10:07:56 -0500

If you read the draft, you must have noticed that it discusses predominantly how to map up and down states to FDI and RDI. Therefore, I don't understand what prompted your first email. Could you explain more explicitly what you think is wrong about the draft?

Thanks,

Peter

> Sent: Wednesday, November 12, 2003 11:54 PM
> To: 'Busschbach, Peter B (Peter)'; [email-masked]';
> [email-masked]; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Thu, 13 Nov 2003 07:31:27 -0800

As I said, I don't mind to start with this draft, but my experience
tells me it is pretty difficult to substantially change a draft, while
it is accepted as a WG draft.

-Shahram

>Sent: Thursday, November 13, 2003 9:13 AM
>To: Shahram Davari; [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Thu, 13 Nov 2003 07:55:19 -0800

Hi Peter,

There are 2 major things wrong with this draft:

1) The draft advocates extending ATM/FR across the PW and doing
ATM-FR Service interworking at only one PE. Meaning that interworking between
ATM/FR and MPLS (aka PW) is Network interworking, and interworking between
ATM-FR is Service interworking. But it asks for ATM-PW-FR Service interworking at both PEs. This is architecturally wrong, because at one of the PEs you are doing Network interworking (between ATM/FR and PW) for the data-plane but doing Service interworking (between ATM/FR and PW) for the Management plane.

2) The draft advocates the mapping of CC and loopback between ATM/FR and MPLS in
sections 4.7 and 4.8. Again, this is fundamentally wrong, since only  the states and
AIS needs mapping and not the CC or LB messages.

Hope that answers yours question.

Yours,
-Shahram

>Sent: Thursday, November 13, 2003 10:08 AM
>To: Shahram Davari; Busschbach, Peter B (Peter);
>[email-masked]'; [email-masked]; [email-masked]
>If you read the draft, you must have noticed that it discusses 
>predominantly how to map up and down states to FDI and RDI. 
>Therefore, I don't understand what prompted your first email. 
>Could you explain more explicitly what you think is wrong 
>about the draft?
>
>Thanks,
>
>Peter
>
>>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-
m
> >> >> ap-03.txt

---

From: Shahram Davari <[email-masked]>
Date: Thu, 13 Nov 2003 08:22:35 -0800

Hi Peter,

By mistake I omitted the OAM in the following text. Here is the correct text:

1) The draft advocates extending ATM/FR across the PW and doing
ATM-FR Service interworking at only one PE. Meaning that interworking between
ATM/FR and MPLS (aka PW) is Network interworking, and interworking between
ATM-FR is Service interworking. But it asks for ATM-PW-FR OAM Service interworking at both PEs. This is architecturally wrong, because at one of the PEs you are doing Network interworking (between ATM/FR and PW) for the data-plane but doing Service interworking (between ATM/FR and PW) for the Management plane.

Yours,
-Shahram

>Sent: Thursday, November 13, 2003 10:55 AM
>ATM-FR is Service interworking. But it asks for ATM-PW-FR 
>Service interworking at both PEs. This is architecturally 
>wrong, because at one of the PEs you are doing Network 
>interworking (between ATM/FR and PW) for the data-plane but 
>doing Service interworking (between ATM/FR and PW) for the 
>Management plane.
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 13 Nov 2003 11:45:45 -0500

>doing Service interworking (between ATM/FR and PW) for the 

	Actually I mentioned that I will be removing the 
any-to-any interworking stuff from the draft during the meeting,
as this is out of scope of the current charter.

	--Tom

---

From: [email-masked]
Date: Thu, 13 Nov 2003 18:28:50 -0000

Hi Tom,  1 question below for clarification....though perhaps George should answer.  regards, Neil

> as this is out of scope of the current charter.
NH=> Does this mean http://www.ietf.org/internet-drafts/draft-swallow-pwe3-spvc-iw-00.txt is also now out of scope?....signalling I/W is for sure a major component of service I/W and is only valid under these terms.

---

From: "Pugaczewski, Jack" <[email-masked]>
Date: Thu, 13 Nov 2003 06:49:48 -0600

>From a carrier's perspective I believe it is important to extend the
existing model.  For example in SONET and ATM there is a mapping between
F1, F2, F3, F4 and F5.  In the case of Frame Relay to ATM Interworking
FRF.8 provides a mapping for fault management between F5 AIS/RDI and
LMI.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, November 13, 2003 3:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3
WG draft?

As Dave Allan pointed out earlier, there is a document on ATM and MPLS
peer OAM I/W....it is Y.1712.  Its simple and complete.  This should not
be ignored.

regards, Neil

> >>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> >>>> 
> >>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> >>>> 
> >>>
> >>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sat, 15 Nov 2003 22:24:17 -0500

Thanks, Sharam. This helps. Please see in-line for further comments.

Peter

> doing Service interworking (between ATM/FR and PW) for the 

The document mentions both Network Interworking (figures 3 and 4) and Service Interworking (figure 5). I think that much of the text was indeed written with Service Interworking in mind. Tom already mentioned that this would be straightened out in the next version of the paper.

> AIS needs mapping and not the CC or LB messages.

Same comment: the text makes sense for Service Interworking. You are right that it does not belong in a document that discusses Network Interworking.

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Sun, 16 Nov 2003 13:43:34 +0100

Belated response to this thread as I have been in travel mode:

"Same comment: the text makes sense for Service Interworking. You are right that it does not belong in a document that discusses Network Interworking."

Correct -- we will align draft text in the next revision .

Also, as far as service interworking is concerned, and ITU-T SG 13 activity, Q.5 has not yet produced a definition, and therefore is work under progress.

/m

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Busschbach, Peter B (Peter)
Sent: 16 November 2003 04:24
To: 'Shahram Davari'; Busschbach, Peter B (Peter); [email-masked]'; Tom Nadeau (tnadeau); [email-masked]
Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft?

Peter