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

[Donald Eastlake <[e-mail]>]

Hi James,

On Mon, Jan 3, 2011 at 1:28 PM, James Carlson <[e-mail]> wrote:
> Donald Eastlake wrote:
>> 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"?
>
> It depends on the underlying link type and options (e.g., RFC 1570), but
> the short answer is "yes."
>
>> 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?
>
> 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.

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

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

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.

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

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.

> --
> James Carlson         42.703N 71.076W         <[e-mail]>

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