Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires
RFC 7173

Note: This ballot was opened for revision 03 and is now closed.

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2014-01-31)
No email
send info
Thank you for addressing my concern.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-01-08 for -04)
No email
send info
section 4 typos: 
- "TRILL level secuirty mechanisms, such as the ability
use" 
- s/criterion/criteria/

(Brian Haberman) No Objection

Comment (2014-01-07 for -04)
No email
send info
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.

(Joel Jaeggli) No Objection

Comment (2014-01-08 for -04)
No email
send info
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

Barry Leiba No Objection

Comment (2013-12-30 for -03)
No email
send info
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?

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection