Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires
draft-ietf-trill-o-pw-06

[Ballot discuss]
Thank you for addressing my concerns, however I still find the following quite confusing. The root cause of the problem is that whilst the MPLS network sees all TRILL packets as data packets, TRILL surely distinguishes between IS-IS PDUs and data packets, thus the use of the term "TRILL Data Packet" in conjunction with the TRILL IS_IS PDU packets is confusing in the text below.

May I suggest:

OLD
TRILL IS-IS PDUs critical to establishing and maintaining adjacency (Hello and
MTU PDUs) SHOULD be sent with the Traffic Class that would be used
for a priority 7 (maximum priority) TRILL Data packet while other
TRILL IS-IS PDUs SHOULD be sent with the Traffic Class that would be
used for a priority 6 TRILL Data packet. 
NEW
TRILL IS-IS PDUs critical to establishing and maintaining adjacency (Hello and
MTU PDUs) SHOULD be sent with the MPLS Traffic Class that would be used
for a priority 7 (maximum priority), while other TRILL IS-IS PDUs SHOULD be
sent with the MPLS Traffic Class that would be used for a priority 6. TRILL Data
packets SHOULD be sent with an MPLS Traffic Class that is lower than is used
for the TRILL IS_IS PDU packets. 
END

[Ballot discuss]
(moving one point to a comment)
Removing the doc track element of the discuss having discussed this.

"The pseudowire between such ports can be auto-configured [RFC4447]"

You say "The pseudowire between such ports can be auto-configured [RFC4447]", but I would not go so far as to describe it as an auto-configuration scheme. The operator still has to configure some parameters on the PEs. If it is indented to be fully autoconfiguring we need to discuss whether it achieves this.

"The sending pseudowire TRILL Switch port MUST copy the priority of
  the TRILL Data packets being sent to the 3-bit Traffic Class field of
  the pseudowire label [RFC5462] so the priority will be visible to
  pseudowire transit devices and they can take the priority into
  account."

Surely it should map them rather than just copy them since the two networks may have different associations between the bit-set and the queue-set?  Again

"TRILL IS-IS PDUs critical to establishing and maintaining
  adjacency (Hello and MTU PDUs) SHOULD be send with Traffic Class 7
  (maximum priority) while other TRILL IS-IS PDUs SHOULD be sent with
  Traffic Class 6."

Doesn't this  make an assumption about the TC to behavior mapping?

[Ballot comment]
some minors nit captured in the opsdir review

Dear all,
Season's greetings!

I have reviewed this document as part of the operations directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operations area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Basically it is an informational guidance on how to connect trill RBridges using PW without changing TRILL and PW specifications. You may want to take the following reviews into consideration.

1. Section 2.1:
The sending pseudowire TRILL Switch port MUST copy the priority of
the TRILL Data packets being sent to the 3-bit Traffic Class field of
the pseudowire label...
I think priority here refers to priority code in outer.VLAN.  Better clarify it.

2. Page 4 right above section 2.1, it says, "This application needs no additions  to the existing pseudowire standards". PPP PW in section 2.2 does not require any change to current RFCs for TRILL or PW.
However the appendix says it may not be true for the other types of PW.
So I suggest to give a brief explanation. For PW type other than 0x0007, it may require some changes otherwise may not be directly applicable, e.g. for type 0x0004. Then the readers may refer to the appendix.

Nit: last paragraph in Section 2, sentence fragment:

OLD

    A pseudowire is carried over a packet switched network tunnel
    [RFC3985].  For example, an MPLS or MPLS-TP label switched path
    tunnel in MPLS networks.

NEW

    A pseudowire is carried over a packet switched network tunnel
    [RFC3985], for example, an MPLS or MPLS-TP label switched path
    tunnel in MPLS networks.

Nit: second last paragraph of Sec. 2.1, unnecessary use of abbreviation (which otherwise would have to be spelled out on first use anyway):

OLD

... constraint on the TRILL campus wide Sz ...

NEW

... constraint on the TRILL campus wide MTU size ...

OLD

... MUST be used in helping to determine Sz ...

NEW

... MUST be used in helping to determine MTU size ...


Thank you,
Tina

[Ballot discuss]
(moving one point to a comment)

I have a few points that I would like to discuss on this draft:

The proposed status is proposed standard, and yet the draft introduces no new protocol. I am wondering is PS is the correct RFC type and whether the text should be an applicability statement.

"The pseudowire between such ports can be auto-configured [RFC4447]"

You say "The pseudowire between such ports can be auto-configured [RFC4447]", but I would not go so far as to describe it as an auto-configuration scheme. The operator still has to configure some parameters on the PEs. If it is indented to be fully autoconfiguring we need to discuss whether it achieves this.

"The sending pseudowire TRILL Switch port MUST copy the priority of
  the TRILL Data packets being sent to the 3-bit Traffic Class field of
  the pseudowire label [RFC5462] so the priority will be visible to
  pseudowire transit devices and they can take the priority into
  account."

Surely it should map them rather than just copy them since the two networks may have different associations between the bit-set and the queue-set?  Again

"TRILL IS-IS PDUs critical to establishing and maintaining
  adjacency (Hello and MTU PDUs) SHOULD be send with Traffic Class 7
  (maximum priority) while other TRILL IS-IS PDUs SHOULD be sent with
  Traffic Class 6."

Doesn't this  make an assumption about the TC to behavior mapping?

[Ballot comment]
"If a pseudowire supports fragmentation and re-assembly"

Whilst what follows is correct and I know PPP PWs have the FE bits,  I don't think there is any significant deployment.
In a 2009 report (http://www.nanog.org/meetings/nanog46/presentations/Tuesday/Martini_Pseudowires_N46.pdf)
it was reported that there was zero deployment of fragmentation and since then the availability of jumbo frames
in the core has made this less likely.

[Ballot discuss]
I have a few points that I would like to discuss on this draft:

The proposed status is proposed standard, and yet the draft introduces no new protocol. I am wondering is PS is the correct RFC type and whether the text should be an applicability statement.

"The pseudowire between such ports can be auto-configured [RFC4447]"

You say "The pseudowire between such ports can be auto-configured [RFC4447]", but I would not go so far as to describe it as an auto-configuration scheme. The operator still has to configure some parameters on the PEs. If it is indented to be fully autoconfiguring we need to discuss whether it achieves this.

"The sending pseudowire TRILL Switch port MUST copy the priority of
  the TRILL Data packets being sent to the 3-bit Traffic Class field of
  the pseudowire label [RFC5462] so the priority will be visible to
  pseudowire transit devices and they can take the priority into
  account."

Surely it should map them rather than just copy them since the two networks may have different associations between the bit-set and the queue-set?  Again

"TRILL IS-IS PDUs critical to establishing and maintaining
  adjacency (Hello and MTU PDUs) SHOULD be send with Traffic Class 7
  (maximum priority) while other TRILL IS-IS PDUs SHOULD be sent with
  Traffic Class 6."

Doesn't this  make an assumption about the TC to behavior mapping?

"If a pseudowire supports fragmentation and re-assembly"

Whilst what follows is correct and I know PPP PWs have the FE bits,  I don't think there is any significant deployment. In a 2009 report (http://www.nanog.org/meetings/nanog46/presentations/Tuesday/Martini_Pseudowires_N46.pdf) it was reported that there was zero deployment of fragmentation and since then the availability of jumbo frames in the core has made this less likely.

[Ballot comment]
I agree with Barry that the 2119 keywords in section 2.1 would benefit from explanatory text as to the implications of not setting the Traffic Class field to those particular values.

[Ballot comment]
I just have a small comment about Section 2.1.  It's non-blocking, so don't get too wrapped up in it:
In the first paragraph are two "SHOULD" statements.  As 2119 says, for SHOULD, that "the full implications must be understood and carefully weighed before choosing a different course," I always like it when those implications are noted, so that implementors can weigh them.  Is it worth saying a few words about what the interoperability issues are here?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-trill-o-pw-03, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Transport of TRILL Using Pseudowires) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'Transport of TRILL Using Pseudowires'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies how to interconnect a pair of TRILL
  (Transparent Interconnection of Lots of Links) switch ports using
  pseudowires under existing TRILL and PWE3 (Pseudowire Emulation End-
  to-End) standards.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-o-pw/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-o-pw/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard as indicated on the header page. While the draft doesn't specify new packet formats or code points, it does specify the standard way to run TRILL over a pseudo-wire. For such X-over-Y documents the IETF uses standards track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies how to interconnect a pair of TRILL
  (Transparent Interconnection of Lots of Links) switch ports using
  pseudowires under existing TRILL and PWE3 (Pseudowire Emulation End-
  to-End) standards.

Working Group Summary

  A previous version of this document was presented in the PWE3 WG as
  draft-yong-pwe3-trill-o-pw-00; however, the PWE3 Chairs and AD decided
  that, since it specified a Native Service Processor (NSP) for the
  TRILL serice and did not change any PWE3 standards, it belonged in
  TRILL WG. So draft-yong-trill-o-pw-01 was adopted by the TRILL WG.

  This is a short, simple draft that corresponds to an explicit work
  item in the TRILL Charter. It has been thoroughly reviewed by
  Yaakov (J) Stein, a volunteer from the PWE3 WG from the PWE3
  perspective and by the Shepherd from a more general / TRILL
  perspective.

Document Quality

  Document has been reviewed and seems to be of good quality, There are no
  known implementations yet. The document is quite simple with no need for
  any special reviews.

Personnel

  Document Shepherd: Erik Nordmark
  Responsible Area Director: Ted Lemon

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  Reviewed the document and suggested some editorial clarifications (which were
  performed in -04).

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  As stated above, was reviewed by Yaakov (J) Stein from a PWE3 perspective.
  The posting of the -00 WG draft and the WG last call was forwarded to the PWE3
  working group with an explicit request for a reviewer.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is good consensus behind the document, even if only a subset of the
  TRILL WG participants care about running TRILL over pseudo-wires.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No ID nits issues.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal review needed.

(13) Have all references within this document been identified as
either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    There are normative references to two drafts but they are already
    approved and in the RFC Editor's queue.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA actions are needed, and this has been verified against the totality of
  the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    There are no such formal descriptions in the document.