Subject: [PWE3] Fwd: WG LC on draft-ietf-trill-o-pw

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 4 Oct 2013 12:53:57 -0400

This is for the information of the PWE3 WG, Yaakov had some comments on the
trill list on this draft that you may find of interest. The discussion
continues on the trill list.

Cheers,
Andy

---------- Forwarded message ----------
From: Yaakov Stein <[email-masked]>
Date: Tue, Oct 1, 2013 at 10:57 AM
Subject: WG LC on draft-ietf-trill-o-pw
To: "[email-masked]" <[email-masked]>, Donald Eastlake <[email-masked]>
Cc: "Stewart Bryant (stbryant)" <[email-masked]>, "Andrew G. Malis" <
[email-masked]>

 A request was made on the PWE3 list to look at this draft, and I
volunteered to do so.****

** **

Here are my comments:****

** **

1) The term trill over pseudowires is problematic. ****

     A PW is a tunneling mechanism, although over time it has become a full
layer network.****

     I would prefer “trill pseudowire”, but that would imply a new PW type,
which this draft does not propose (more on that below).****

     So perhaps “transport of TRILL using pseudowires” would be the most
appropriate.****

2) In this context … and, assuming the pseudowires are over MPLS or IP
[RFC4023 <http://tools.ietf.org/html/rfc4023>], as label switched
routers.****

    Well, if over IP using 4023 the function is that of an IP router,
not an LSR.****

3) I find the parenthetical paragraph in section 2 somewhat strange –
is this to be removed once the draft is agreed upon ?****

    In any case, I disagree with the statement that an Ethernet PW
would require an additional 12 or 16 bytes.****

    If the TRILL packet is NOT an Ethernet packet, then an Ethernet PW
is not appropriate at all.****

    I think that you are actually referring to the generic “packet
pseudowire” encap which can carry anything,****

    but does indeed require a pseudo-Ethernet header. If this is the
intention, please restate as****

    “Although use of the packet pseudowire encapsulation of RFC 6658
would be possible, … “****

4) “It would also be possible to specify a custom pseudowire type…” ****

     It is not the custom in PWE3 to use the wording “custom type”. ****

     I believe that you simply mean a “new” PW type (see next comment).****

5) “the 3-bit Class of Service field”. Sorry, but the name has been
changed to the “Traffic Class” field.****

6) My main comment is regarding the use of the PPP encap.****

     Yes, it is OK, but I really would prefer a new PW type. ****

     Yes that would require IANA updating the PW type registry, but we
have only used up 32 out of 32K types****

     so it is not that we need to conserve them. ****

     And 1024 are “expert review”, which don’t even require this RFC
to get an allocation!****

     Why would such a definition be better ? There are at least 4 reasons:****

**A)   **PW packets are not self describing, so packet dissectors
(e.g., WireShark) need help in understanding them.****

This is normally done by looking at the PWE control protocol session.****

Obfuscating the intent here behind PW type 0x007 would thwart the
possibility of properly parsing the packets,****

impacting debugging and other operational tasks.****

**B)   **The TRILL PW requires special NSP functions to be performed,
e.g., copying the priority into the TC field****

These functions are not required of standard PPP PWs, and should be
linked to the TRILL case.****

**C)   **I seem to recall that TRILL was working on its own OAM mechanism.****

Perhaps OAM interworking between this and the PW OAM is not yet of interest,****

but I can imagine it being desired. This would require knowing that we
have a TRILL PW rather than just a PPP one.****

**D)   **It would allow us to rename this encap as a “TRILL pseudowire “.****

** **

Thanks for making this draft concise!****

** **

Y(J)S****

** **