Subject: [PWE3] AD review of draft-ietf-pwe3-packet-pw

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 21 Jan 2012 17:10:19 -0000

Hi,

In addition to a question about the shepherd write-up which I sent to Matthew
separately, I have a collection of small questions and nits for the authors. I
think the nits are many enough to warrant a revision, and the questions might
require a revision depending on the answers.

Thanks,
Adrian

---

I started reading this in the belief that this is truly a BCP and I 
wrote the following:

I think it would be helpful if both the Abstract and the Introduction
(to a lesser and greater extent, respectively) noted that:
- this document does not define any new procedures or protocol elements
- this document indicates how a specific function is provided using
  existing tools and mechanisms
- this document advises the Internet community on the best current
  practice for providing a packet service over an MPLS network

However, when it comes to it, you are making to code point requests to
IANA. This isn't a BCP is it? Shouldn't it be Standards Track?

---

LSR needs to be expanded in the Abstract and para 3 of the Introduction.

---

Section 1

s/via physical interface/via a physical interface/

---

Throughout the doc

s/point to point/point-to-point/
s/point to multipoint/point-to-multipoint/
s/multipoint to multipoint/multipoint-to-multipoint/

---

Section 2

s/network is shown/network as shown/

---

Figure 1 is missing a title

---

Section 2
It is not necessary to expand PSN, but if you want to, you should do it
on first use (in section 1)

---

Section 3
                                                                    
s/layer two/layer 2/   for consistency with the rest of the doc

--

Section 7

   congestion considerations being developed for PWs apply [RFC3985],
   [RFC5659].

I think you can delete "being"

---

Section 9

I found what you have written a little open to (wilful)
misinterpretation. Which code point has which name? Couldn't you have
written:

   Dotted Decimal           Description                       Reference
   -----------------------  --------------------------------  ---------

   000.00x.000              PacketPWEthA                      [This RFC]
   000.00x.001              PacketPWEthB                      [This RFC]

Do you want to make it clear that x is open for IANA to choose?

---

Appendix A

I can see some good reasons to preserve the history of discussion, 
although this is not normally done with IETF documents that are 
concerned with setting out a specification on which consensus has been
reached. If you want to carry on including the Appendix, you need to do
several things:

1. Refer to it in the body of the text. I think this is most easily done
   from the Introduction.

2. State in the Appendix why it is included. You do a good job of saying
   what is in the Appendix, but not why the Appendix is there and what
   the reader is supposed to gain from it.

3. Make it clear (in the Appendix) that it is non-normative.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 21 Jan 2012 12:39:04 -0500

Adrian,

(speaking a co-author)

Thanks for your review and comments.

The code points were a relatively recent addition that came out of a
discussion of what to put into the MAC address fields. But you're right,
the IANA allocation probably does take it away from being a BCP.

So I guess we're on the standards track now and will make the appropriate
changes to the draft.

The other comments look fine, including the IANA code points. We could
suggest 3 and 4 as the two "X" values to make IANA's life easier.

Appendix A was very useful during the development of the draft because it
kept us from endlessly iterating on design choices, but I personally
wouldn't have a problem with removing it at this point.

Cheers,
Andy

On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <[email-masked]> wrote:

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 22 Jan 2012 08:44:10 -0500

Adrian,

I meant suggesting just 3 as X.

Cheers,
Andy

On Sat, Jan 21, 2012 at 12:39 PM, Andrew G. Malis <[email-masked]> wrote:

> On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <[email-masked]>wrote:
>
>> Hi,
>>

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 24 Jan 2012 11:35:26 +0100

Adrian,

Progressing this as a BCP or informational draft was an outcome of the consensus call that enabled us to progress this draft  vs. draft-kini-pwe3-pkt-encap-efficient-ip-mpls-02.txt. However, I agree that it makes sense to change it to standards track because of the IANA request for a code point from an IETF consensus space.

Working Group: please be aware of this proposed change and send any comments to the PWE3 list.

Regards

Matthew

On 22/01/2012 13:44, "Andrew G. Malis" <[email-masked]<mailto:[email-masked]>> wrote:

Adrian,

Cheers,
Andy

On Sat, Jan 21, 2012 at 12:39 PM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:
Adrian,

(speaking a co-author)

The code points were a relatively recent addition that came out of a discussion of what to put into the MAC address fields. But you're right, the IANA allocation probably does take it away from being a BCP.

So I guess we're on the standards track now and will make the appropriate changes to the draft.

The other comments look fine, including the IANA code points. We could suggest 3 and 4 as the two "X" values to make IANA's life easier.

Appendix A was very useful during the development of the draft because it kept us from endlessly iterating on design choices, but I personally wouldn't have a problem with removing it at this point.

Cheers,
Andy

On Sat, Jan 21, 2012 at 12:10 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Adrian

---

---

---

Section 1

---

Throughout the doc

---

Section 2

---

---

Section 2

---

Section 3

--

Section 7

---

Section 9

---

Appendix A

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Jan 2012 18:01:48 +0000

> IANA. This isn't a BCP is it? Shouldn't it be Standards Track?
Done the edit, but await consensus of WG before uploading.

> LSR needs to be expanded in the Abstract and para 3 of the Introduction.
Done
> s/via physical interface/via a physical interface/
Done
> s/multipoint to multipoint/multipoint-to-multipoint/
Done and s/multi-point/multipoint/
> s/network is shown/network as shown/
"The network reference model for the packet pseudowire operating in an 
MPLS network is shown in <ref>"

The original looks correct
> Figure 1 is missing a title
Done
> on first use (in section 1)
Deleted expansion
> s/layer two/layer 2/   for consistency with the rest of the doc
Done (in section 4)
Done
>     Dotted Decimal           Description                       Reference
Both of the above done:

Dotted Decimal       Description       Reference
-------------------  ----------------  ---------

The value of x is open for IANA to choose. A value of 3 is suggested.

> 3. Make it clear (in the Appendix) that it is non-normative.
In the appendix:

This appendix is non-normative.

A number of approaches to the design of a packet pseudowire (PW) were 
investigated by the PWE3 Working Group and were discussed in IETF 
meetings and on the PWE3 list. This section describes the approaches 
that were analyzed and the technical issues that the authors took into 
consideration in arriving at the approach described in the main body of 
this document. This appendix is provided so that engineers considering 
alternative optimizations can have access to the rational for the 
selection of the approach described above.

... and at the end of the introduction:

Non-normative Appendix A provides information on alternative approaches 
to providing a packet PW that were considered by PWE3 Working Group and 
the reasons for using the method defined in this specification.

====

Plus added title to Fig3

Figure 3: Packet PW Encapsulation

-Stewart