Subject: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt

From: Donald Eastlake <[email-masked]>
Date: Mon, 3 Jan 2011 12:27:20 -0500

Hi,

I've received a comment about the last figure in Section 2.3 of
draft-ietf-trill-rbridge-protocol-16.txt. This figure shows a very
high level generic view of a TRILL Data frame being sent over PPP.
However, there is a possible problem with that figure.

The general form of a TRILL Data frame is
  Link Header
  TRILL Header
  Encapsulated data frame in Ethernet format
  Link Trailer

If the link is Ethernet, the Link Header is an Ethernet Header
(destination MAC, source MAC, possible VLAN tag, Ethertype) and the
Link Trailer is an Ethernet Trailer, that is, an FCS covering the
entire frame.

If the link is PPP, then we should have a PPP Header, which is fine
and is shown in the figure, but is there a "PPP Trailer"? The figure
shows an "Ethernet FCS" which may be wrongly labeled. If there is an
FCS there, calculated as Ethernet does, how much of the frame does it
cover? In particular, does it cover the PPP Header, in which case I
think it should be labeled "PPP FCS"? Or should the convention in PPP
be to have an FCS just covering the encapsulated Ethernet frame?

In any case, I think a few words about this are needed in the
pppext-trill draft...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: James Carlson <[email-masked]>
Date: Mon, 03 Jan 2011 13:28:08 -0500

Donald Eastlake wrote:
> and is shown in the figure, but is there a "PPP Trailer"?

It depends on the underlying link type and options (e.g., RFC 1570), but
the short answer is "yes."

> The figure
> cover?

The standard PPP FCS covers the entire frame, including any HDLC and PPP
headers and user data, but without the medium-dependent bit or octet
stuffing.  See RFC 1662 for details.

Yes, it covers the same things the Ethernet FCS does.

> In particular, does it cover the PPP Header, in which case I

We don't normally do that for PPP documents -- it's assumed that the NCP
document just covers the bits that are particular to that NCP, and not
all of the common PPP bits all the way down to the bare metal -- but I
guess I can do that if it'll help with alignment with the other TRILL
documents.

(For what it's worth, I don't think the TRILL document should mention
the Ethernet FCS, either.  TRILL isn't defining Ethernet encapsulation,
and including those bits seems like duplication.  But I suppose that's
just me ...)

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 3 Jan 2011 13:57:10 -0500

Hi James,

> Yes, it covers the same things the Ethernet FCS does.

Ok. Then it should be labeled PPP FCS in that figure as an editorial correction.

> guess I can do that if it'll help with alignment with the other TRILL

Well, I would assume the RFC resulting from
draft-ietf-pppext-trill-protocol will in some cases be read by people
familiar with TRILL but not familiar with PPP. So, while it certainly
doesn't need much, making it clear that there is no Ethernet FCS in
the encapsulated material and having references pointing at the PPP
Trailer info seem like a good idea to me.

> and including those bits seems like duplication.  But I suppose that's

More than once I've gotten specific questions about whether or not the
"encapsulated Ethernet frame" inside a TRILL Data frame includes an
Ethernet FCS just covering the encapsulated material. So I think it is
better that this sort of thing be mentioned.

Thanks,
Donald

---

From: James Carlson <[email-masked]>
Date: Mon, 03 Jan 2011 14:21:24 -0500

> Trailer info seem like a good idea to me.

I've made the updates for both -- making it clear that the Ethernet FCS
is not present and that the PPP FCS (if any) is used.  I'll send you a
draft to look over.

(I think that if they're reading this and don't know much about PPP, I
think they're probably in a world of hurt.  Or at least their customers
are going to be.  I'm not about to turn this simple draft into a road
map for implementation of PPP.)

> better that this sort of thing be mentioned.

Same planet, different universes, I guess.  ;-}