Subject: [RTG-DIR] RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 29 Jun 2011 14:00:39 +0200

RtgDir review: draft-li-pwe3-ms-pw-pon-03.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-li-pwe3-ms-pw-pon-03.txt
Reviewer: Matthew Bocci
Review Date: 28-06-11
IETF LC End Date: 28-06-11
Intended Status: Informational

Summary:

I have some concerns about this document that I think should be resolved before publication.

Comments:

Major Issues:

- It is not clear from the draft how PW OAM works when one segment of an MS-PW is established using OMCI. End-to-end VCCV on an MS-PW (as defined in RFC5085 and RFC6073) requires that each segment negotiate or be configured with its VCCV capabilities, so that the end-to-end PW uses a common set of OAM tools supported by each segment. It would be useful if the draft explained how VCCV is handled on the OMCI-controlled segment and whether there are any implications for 'regular' IP/MPLS PW segments.
- How is the OMCI-controlled segment treated at the S-PE where it is switched to the LDP controlled segment? Does it look like a static segment, and so confirms to relevant parts of RFC6073?
- It would be useful to include some more detail on what PW parameters are carried by OMCI, and what parameters need to be configured at the T-PE and S-PE e.g. how are interface parameters handled? What specific PW types and encapsulation modes are supported (so we know what can be supported end-to-end on the MS-PW).
- How is PW OAM message mapping handled by OMCI? Does it release the PW label, or does it use status signaling (the draft only very briefly mentions this), or is the assumption that native service OAM is always carried in-band?

Minor Issues:

Abstract

   This document describes the application of MPLS multi-segment
   pseudowires (MS-PWs) in a dual-technology environment comprising a
   Passive Optical Network (PON) and an MPLS Packet Switched Network
   (PSN).

   PON technology may be used in mobile backhaul networks to support the
   end segments closest to the aggregation devices.  In these cases,
   there may be a very large number of PW Terminating Provider Edge
   nodes (T-PEs).  The MPLS control plane could be used to provision
   these end segments, but support for the necessary protocols would
   complicate the management of the T-PEs and would significantly
   increase their expense.  Alternatively, static, or management plane,
   configuration could be used to configure the end segments, but the
   very large number of such segments in a PON places a very heavy
   burden on the network manager.

   This document describes how to set up the end segment of an end-to-
   end MPLS PW over a Gigabit-capable Passive Optical Network (GPON)
   using the GPON management protocol, Optical Network Termination
   Management and Control Interface (OMCI).  This simplifies and speeds
   up PW provisioning.

MB> Compared to what? I believe the author means compared to manual
provisioning, but it would help to be explicit.

   This document also shows how a MS-PW may be constructed from an end
   segment supported over a PON, and stitched to one or more segments
   supported over an MPLS PSN.

1.  Introduction

[…snip…]
Figure A depicts the physical infrastructure of an Optical
   Distribution Network (ODN).

MB> I think this is as used in mobile backhaul (because it shows base
stations), but please can you be specific. Also, it would be useful if the
figure indicated the technology between the base stations and the ONU.

[…snip..]

Routing protocols and dynamic label distribution protocols like LDP
   would significantly increase the ONUs' cost and complexity as they
   place requirements on both hardware and software.  Besides coding and
   maintenance of these new protocols, a much powerful CPU and more
   memory are also necessary for them to run smoothly.

MB> I think the issue here is that you need a whole set of IP and MPLS control protocols that are not used for anything other than managing PWs. This might not make sense on a basic box like an ONU. I would suggest rephrasing this paragraph as follows:
"Additional protocols only needed for one task, such as routing and dynamic label distribution for PWs, require additional CPU and memory resources which may not be justified on a simple device such as an ONU."

[…snip…]
Since there may
   be very many ONUs (and hence very many PWs) in a PON, this comprises
   a large amount of operational effort.

MB> c/comprises/requires

Additionally, there must be a
   concern that the configuration at the ONU and the OLT will be
   inconsistent because for any PW, both the ONU and the OLT must be
   configured.

MB> I think the issue is that the OLT and ONU are configured separately,
so care must be taken to ensure that the config is consistent at each end.
Perhaps this would be better phrased as:
"Additionally, care must be taken to ensure that the PW configuration is consistent at the OLT and ONU, since these nodes are configured separately."

[..snip..]
This document shows how the two technologies (PON and PSN) can be
   combined to provide an end-to-end multi-segment MPLS PW.

MB> I think we should be careful not to claim this is end-to-end MPLS. I do not think OMCI would normally be classed as an MPLS protocol (even though I agree the data path for the PW is MPLS). I think the term MPLS should be
removed here and just call is an end-to-end MS-PW.

3.  Multi-Segment Pseudowire over PON Network Reference Model

[snip]
It should be noted that all PW segments are of the same technology,
   which is packet encapsulated.

MB> I am not sure I understand this. Does it mean to say: "It should be noted that all PW segments encapsulate the same packet technology."?

4.  Label Provisioning for Pseudowires over PON
The labor of provisioning static labels at the ONUs for PWs can be
   significantly reduced by using a management protocol over PON.  At
   the time, this approach keeps the ONU simple by not requiring the
   implementation of a new dynamic control protocol.

MB> 'At this time ' is not necessary and should be deleted.

The usual management protocol in a GPON system used to manage and
   control ONUs is OMCI.  It is used to perform all GPON physical layer
   and data GTC layer configuration on ONUs.  Per [G.984.4amd2] and
   [G.988], OMCI can also be used to set up PWs and the MPLS LSP Tunnels
   from ONUs to OLT.  When using OMCI to provision PWs in a GPON, the
   network manager sends configuration information to the OLT only.  The
   OLT will select suitable PW labels and send all PW and MPLS LSP
   tunnel parameters to the ONUs through OMCI.  The AC can be identified
   in the OMCI signaling so that the network manager does not need to
   configure the PWs at each ONU.

MB> Please explain exactly what parameters are signaled, since these are being expanded upon all the time by the PWE3 working group.

Nits:

References:
- The reference to draft-ietf-pwe3-segmented-pw should be updated to RFC6073

- The draft uses the term 'stitching' or 'stitched'. Please replace with 'switching' or 'switched' as appropriate, as these are the accepted terms used for MS-PWs.

- In Section 3:
At present, Ethernet over GEM is the dominant encapsulation in GPON.
   For fast deployment of MPLS over GPON, put MPLS PWs over Ethernet
s/put/putting
   over GEM is an alternative way of transport MPLS PWs over GPON with
s/transport/transporting
   existing hardware.

- In Section 4:
A MS-PW with a segment running over a PON, where the OLT acts as an
   S-PE and the ONU as a T-PE, PW provisioning can be performed through
   static configuration, e.g., from an NMS.
MN> This sentence doesn't parse. I would suggest changing the first phrase to:
"Where an MS-PW includes a segment running over a PON,...

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 29 Jun 2011 16:03:32 +0100

Hi Matthew,

[cranky old author hat on]

Thanks for the review, I guess.

> - It is not clear from the draft how PW OAM works when one segment of an MS-PW

>  is established using OMCI. End-to-end VCCV on an MS-PW (as defined in RFC5085
> and RFC6073) requires that each segment negotiate or be configured with its
VCCV
> capabilities, so that the end-to-end PW uses a common set of OAM tools
supported
> by each segment. It would be useful if the draft explained how VCCV is handled
on
> the OMCI-controlled segment and whether there are any implications for
'regular' 
> IP/MPLS PW segments.

What makes you think there would be anything special here?
What is different using OMCI versus a management protocol or LDP?

This document is about carrying the MPLS PW over different tunnelling
technologies, so why wouldn't section 9.3 of RFC 6073 simply apply?

So, possibly you are asking: "How does OMCI signal PW information such as VCCV
capabilities?" Might be a reasonable question if this document was intended to
define the OMCI extensions for signaling PWs in a PON. But it is not! That is
clearly out of scope for the IETF.

As Section 4 says...

   OMCI supports the configuration of a number of PW types including
   TDM, ATM, and Ethernet, and the protocol can also be used to allow
   the ONU to notify the OLT of the status of the AC.

> - How is the OMCI-controlled segment treated at the S-PE where it is switched
to
>  the LDP controlled segment? Does it look like a static segment, and so
confirms
>  to relevant parts of RFC6073? 

Isn't that the way *any* two segments are stitched according to 5659 and 6073?
How could this vary from that architecture, especially given the introductory
text in this document?

> - It would be useful to include some more detail on what PW parameters
> are carried by OMCI, and what parameters need to be configured at the
> T-PE and S-PE e.g. how are interface parameters handled? What specific
> PW types and encapsulation modes are supported (so we know what can
> be supported end-to-end on the MS-PW).

Why is this document the right place to do that?
The definition and extension of OMCI belongs in the ITU-T.

> - How is PW OAM message mapping handled by OMCI? Does it release
> the PW label, or does it use status signaling (the draft only very briefly 
> mentions this), or is the assumption that native service OAM is always 
> carried in-band?

Was it your intention that draft-ietf-pwe3-oam-msg-map was applicable to MS-PWs?
I guess isn't too late to pull it back from the RFC Editor Queue and return it
to the PWE3 working group for addition of that text. You will recall that I
raised this issue while reviewing that draft and was told that MS-PW was out of
scope at the moment. The only additional text added to cover MS-PW is:
   This document is scoped only to single segment PWs. The mechanisms
   described in this document could also be applied to T-PEs for MS-PWs
   ([RFC5254]).

So, isn't it a bit unreasonable to ask this I-D to give more attention to
message mapping (especially when the e2e PW is the same type)?

> Abstract

[SNIP]
>   Alternatively, static, or management plane,

Indeed, per the previous paragraph. A note could be added.

> figure indicated the technology between the base stations and the ONU.

Phooey!

The caption says "typical". The second paragraph after the figure talks about
use in mobile backhaul.

> MB> I think the issue here is that you need a whole set of IP and MPLS control
> protocols that are not used for anything other than managing PWs. This might
> not make sense on a basic box like an ONU. 

Yes, you have understood the issue correctly. The point is that those protocols
are not there in an ODN. I think this is clear to anyone who has understood what
the ODN is.

> I would suggest rephrasing this paragraph as follows:
> "Additional protocols only needed for one task, such as routing and dynamic
> label distribution for PWs, require additional CPU and memory resources which
> may not be justified on a simple device such as an ONU."
>
> […snip…]
> Since there may

Maybe a matter of style. It looks OK to me.

> "Additionally, care must be taken to ensure that the PW configuration is
> consistent at the OLT and ONU, since these nodes are configured separately."

If care could be taken, there would be no concern! So we could write

"Additionally, there is an issue that the configuration of each PW at the OLT
and ONU might be inconsistent since these nodes are configured separately."

Looks pretty much what we had.

> MB> I think we should be careful not to claim this is end-to-end MPLS.
>  I do not think OMCI would normally be classed as an MPLS protocol (even
> though I agree the data path for the PW is MPLS). I think the term MPLS
> should be removed here and just call is an end-to-end MS-PW.
 
I strongly disagree. If you take this path then you will find that all
management configured PWs that are MPLS in the data plane cannot be called MPLS
PWs. You will then need to go back and revise all of the PW RFCs. 

The fact is that the e2e PW here is an MPLS PW, and it is MS. There is simply no
necessity to debate the provisioning mechanism.

> MB> I am not sure I understand this. Does it mean to say: "It should be noted
that all PW segments 
> encapsulate the same packet technology."?

No. It means what it says. The PW technology of each PW segment is the same, and
that technology is "packet encapsulated".

> MB> 'At this time ' is not necessary and should be deleted.

Fine

> MB> Please explain exactly what parameters are signaled, since these are being
> expanded upon all the time by the PWE3 working group.

Same point. Why is this in scope for this document or for the IETF? The issue of
extending the protocol to signal PWs is clearly an issue for the ITU-T.

> - The reference to draft-ietf-pwe3-segmented-pw should be updated to RFC6073

Will that mean that we are subject to ALU IPR? :-)
Yes. This sort of nit often arises as document progresses through the system and
is picked up and fixed using idnits on each revision.

> - The draft uses the term 'stitching' or 'stitched'. Please replace with
'switching' or
> 'switched' as appropriate,  as these are the accepted terms used for MS-PWs.

RFC 6073
   In Figure 2, pseudowires in two separate PSNs are stitched together
   using native service attachment circuits.

But we can make the change.

>   over GEM is an alternative way of transport MPLS PWs over GPON with

Yes

> "Where an MS-PW includes a segment running over a PON,...

I can parse it. We will try to rewrite.

Thanks,
Adrian

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 29 Jun 2011 17:46:17 +0200

Adrian,

>What is different using OMCI versus a management protocol or LDP?

LDP has VCCV capability negotiation procedures. Any management platform
should be able to configure VCCV capabilities. I assume that OMCI can do
this. Can it?  

>technologies, so why wouldn't section 9.3 of RFC 6073 simply apply?

I'm not talking about the data plane.

>clearly out of scope for the IETF.

Yes, I agree it is out of scope. However, I think it is reasonable to
explain if OMCI can do this, so that VCCV can be used end to end on the
MS-PW. 

>How could this vary from that architecture, especially given the

OK fine, but why not state that?

>The definition and extension of OMCI belongs in the ITU-T.

No, it is not the right place to define it, but it is useful information
to help the reader to understand what PW types can be supported.

>message mapping (especially when the e2e PW is the same type)?

OK that's a fair point in terms of the scope of the message mapping draft,
but the draft does mention that AC

>> [ŠsnipŠ]
>> [Šsnip..]
>> [ŠsnipŠ]

Ok

>extending the protocol to signal PWs is clearly an issue for the ITU-T.

I agree that it is up to the ITU to define these. This is an informational
draft, anyway. It is useful information because it can impact the end to
end capabilities of the PW.

>But we can make the change.

Thanks. 

>I can parse it. We will try to rewrite.

Thank you.

Matthew

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 29 Jun 2011 18:27:48 +0200

Adrian,

One other thing.

On 29/06/2011 16:46, "Bocci, Matthew (Matthew)"
<[email-masked]> wrote:

[snip]

>>message mapping (especially when the e2e PW is the same type)?

Actually you already state that it ONU can notify the OLT of the status of
the AC at the end of section 4, so I think this is fine.

Regards

Matthew