Re: [trill] WG LC on draft-ietf-trill-o-pw

[Donald Eastlake <[e-mail]>]

Hi Yakov,

Thanks for these comments. Sorry for the delay in response. I've been
on vacation recently...

See my responses as an author below:

On Tue, Oct 1, 2013 at 10:57 AM, Yaakov Stein <[e-mail]> wrote:
> 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.

I really can't see any difference between "TRILL over Psuedowires" and
"Transport of TRILL Using Pseudowires" except that (1) I think the "X
over Y" expression is a bit more traditional in the IETF and (2) the
"X over Y" expression is less verbose. If it were not for these two
reasons, I'd be fine with changing the wording. Because of these two
reasons, I'd like to see input from others on this question. But I'm
fine with going whichever way the preponderance of opinion is.

> 2) "In this context … and, assuming the pseudowires are over MPLS or IP
> [RFC4023], as label switched routers."
>     Well, if over IP using 4023 the function is that of an IP router, not an
> LSR.

(I have inserted double quotes above where I believe you are quoting
from the draft.)

How about "... and, assuming the pseudowires are over MPLS or IP
[RFC4023] networks, as label switched or IP routers at the TRILL
Switch ports."?

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

There is no plan to remove that paragraph which, I believe, the
authors think provides some informative background material, partly
explains the changes from
http://tools.ietf.org/id/draft-yong-pwe3-trill-o-pw-00.txt, which
included both PPP (PW type = 0x0007) and Ethernet (PW type = 0x0005)
pseudowires, to draft-ietf-trill-o-pw, which mandates use of a PPP PW,
and indicates that the Ethernet PW alternative was considered.  As
informational material, it might make sense to move this paragraph to
an appendix...

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

I'm not sure why you would doubt that:

There are two kinds of TRILL packets: TRILL Data and TRILL IS-IS. The
link-type-independent part of the TRILL Data packets starts with the
fixed portion of the TRILL Header while that of the TRILL IS-IS
packets start with the IS-IS Interdomain Routeing Protocol
Discriminator byte.

On any particular link, the packet body is enveloped by a
link-type-dependent link header and trailer. The purpose of the link
header/trailer is to get the TRILL packet from one TRILL switch to the
next and to enable you to tell which of the two kinds of TRILL packets
it is. A TRILL IS-IS packet only goes one TRILL hop. But a TRILL Data
packet is routed by TRILL switches based on TRILL nickname, and the
TRILL switches, like other routers, logically strip off and throw away
the link header/trailer on receipt and, if the data is continuing in
TRILL Data packet form, logically add a new link header/trailer as
appropriate for the output link.

On an Ethernet link [RFC 6325], the link header in front of the TRILL
Header needs at least destination and source MAC addresses and an
Ethertype to distinguish the two TRILL packet types. There may also be
a VLAN tag which takes 4 bytes. And the FCS is the link trailer.
That's 16 or 20 bytes. (There could also be other assorted tags as
part of the link header like an 802.1AE tag...)

On a PPP link [RFC 6361], all you have for the link header is a two
byte PPP code point, which indicates which of the two types of TRILL
packets it is. And typically there is a two byte PPPFCS link trailer.
That's 4 bytes.

So, the PPP enveloped TRILL packet is at least 12 and commonly 16
bytes shorter than the corresponding Ethernet enveloped TRILL packet.

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

A TRILL packet body, like an IP packet body starting with the IP
Header or a BFD packet body starting with the BFD Header, is not
logically an "Ethernet packet" nor a "PPP packet" nor any other kind
of link level packet until it gets enveloped at a TRILL switch output
port.

>     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, … “

As per draft-yong-pwe3-trill-o-pw, this was refering to an RFC 4448
Ethernet PW type. I'd be happy to add a reference to that RFC.

> 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).

OK. If it isn't the custom to use custom I don't have any problem with
new wording using "new".

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

OK.

> 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.

To differentiate the two types of TRILL packets, you would either need
two PW types or a field somewhere. Having two PW types and always
setting up two PWs sounds like a nightmare. So, you need a field to
distinguish the two types of TRILL packets, just like the PPP
codepoint that is present if a PPP PW is used.

>      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!

I can't see why it matters that an RFC would not be needed since I
think the purpose of the TRILL WG is to specify aspects of the TRILL
protocol through the publication of RFCs.

>      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.

Either dissectors know what type of PW they are dealing with or they
don't. If they don't know, it makes no difference how the content is
encoded, it will just be binary cruft to the dissector. On the other
hand, if a dissector does know that the content is a PPP PW, I don't
see why there would be any problem and I don't see why you think there
is any obfuscation.

Things like WireShark are designed to peel through multiple layers,
for example parsing an Ethernet frame and then dispatching on the
payload Ethertype to parse, perhaps, an enclosed IP packet and then
dispatching on the IP Protocol type to parse the next layer, etc. Use
of a PPP pseudowire for TRILL means that any dissector that already
understands a TRILL PPP packet (as specified in RFC 6361) and
understands PPP pseudowires will automatically be able to fully parse
TRILL over pseudowires as specified in this draft. If it knows that it
is a PPP pseudowire, the dissector will feed the PPP body to its
regular PPP parsing to dispatch on the PPP code point to determine how
to parse the PPP content. There are many PPP content types including
TRILL Data (0x005d) and TRILL IS-IS (0x405d) and PPP packets are
self-describing. See
http://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2

On the other hand, it we go to the extra effort of specifying a new
pseudowire type then any dissector, even one that already understands
PPP pseudowires and TRILL, will be unable to parse TRILL over
pseudowire until the dissector is updated to know about this new
pseudowire type.

So, I would say that the dissector arugment favors the current draft.

> 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.

? A TRILL port always has to logiclly do what it needs to do to adapt
to the link to which it is attached. If it is an Ethernet link, it
needs to logically add/remove an Ethernet envelope, etc. (Even if a
TRILL switch is implemented to only attach to Ethernet links and is
implemented to keep packets in an Ethernet enveloped format, it has to
set the outer destination and source address and possibly the VLAN tag
at the output port.) Logically, a TRILL packet inside a TRILL switch
doesn't have any envelope and the port has to add/remove one. Some
processing is always necessary. For a pseudowire, seems like the
processing is called NSP (Native Service Processing). But I don't
understand what any of this has to do with selecting between the
different processing that might be required at the port depending on
how TRILL over psuedowires is specified. There is always going to be
processing. Making up a new pseudowire type and new field and new
filed values to distinguish the two types of TRILL packets just seems
like a bunch of extra work.

> 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.

Why would it require knowing that? It seems to me that a hypothetical
interworking function between TRILL OAM and PW OAM would logically be
at the TRILL switch output port which ceratinly knows what's going on.

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

That's true but seems to me a neutral observation, not as a point in
favor of going to the effort of creating a new pseudowire type or just
using the existing PPP pseudowire, which seems like a good fit.

> Thanks for making this draft concise!

You're welcome.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Y(J)S