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

[Donald Eastlake <[e-mail]>]

Hi Yakov,

On Thu, Oct 10, 2013 at 6:42 AM, Yaakov Stein <[e-mail]> wrote:
> Donald,
>
> As it is getting hard to follow the interleaved text,
> I will extract your remarks and respond here.

OK. It looks lke we are converging to some extent.

Removing area of previous agreement:

>> I really can't see any difference between "TRILL over Psuedowires"
>>   and "Transport of TRILL Using Pseudowires"
> In the original pseudowire terminology, the PW is the tunneling
> mechanism, NOT the transport medium.  So one should be "TRILL over
> MPLS" or "TRILL over IP" the mechanism enabling the "over" being the
> pseudowire.  Over time the PW mechanism evolved into a network of
> its own in many senses, but still the term "over PW" is not used.

With this somewhat more complete explanation, I guess I see you point
a bit more clearly and am willing to change the wording.

>> I'm not sure why you would doubt that
> Even after you explanation my doubt remains.
> Whether using a PPP PW or an Ethernet PW, you transport the entire
> ingress Ethernet packet including header.

I'm not sure what you mean by "ingress". If you are referring to TRILL
ingress, yes, end stations (including layer 3 routers) communicate
with TRILL routers (RBridges) with Ethernet, whereas links between
TRILL routers that do not provide end station service can use various
link technologies.  The RBridge that ingresses the Etherent packet
converts it to a TRILL Data packet that starts with a TRILL
Header. Any ingressed packet is a TRILL Data packet. An RBridge also
creates TRILL IS-IS packets and can create TRILL Data packets. The
RBridge knows which is which so it knows how to indicate that when it
outputs the packet through an RBridge port. It does this with an
Ethertype for a port to an Ethernet link [RFC6325] and with a PPP code
point for a PPP link port [RFC6561].

> You could save this overhead by removing the Ethernet header from
> the ingress packet and transport the payload over PPP, but I do not
> believe that you propose that.

If you are talking about TRILL ingress, you can't remove the
end-station-provided Ethernet header without destroying transparency.

> Note that the Ethernet PW does not add an additional Ethernet
> header, it just adds the PW label (and optionally the control word)
> - so where do you see a difference of 12 or 16 bytes?

Because an Ethernet PW requires that its payload by in the form of an
Ethernet packet starting with an initial DA/SA. The original end
station Ethernet DA/SA are embedded after the TRILL Header and the
outer DA/SA required for the payload of an Ethernet PW have nothing to
do with the end station originated DA/SA that is being transparently
transported by TRILL.

> The "packet pseudowire" encapsulation DOES add an additional
> Ethernet header, so for it there is additional 12-16 bytes of
> overhead.
>
>> the following remarks on TRILL format
> My concern was regarding the handling of TRILL packets by the
> standard NSPs that come with Ethernet PWs. In "raw mode" the PE
> performs 802.1D processing, including blocking L2CPs, flooding,
> etc. In "tagged mode" it could additionally change tags on you. I
> don't believe that you want any of that.

Sure. The earlier draft-yong-pwe3-trill-o-pw, which specified how to
transport TRILL with both PPP PWs and Ethernet PWs, said that in the
Ethernet PW case you MUST use raw mode and non-service-delimiting.
Really, we have thought about these things.

>> To differentiate the two types of TRILL packets ...
> OK, now I understand what you mean.
>
> However, 2 PWs are not needed in order to distinguish between the 2
> types of TRILL packets, unless you need different packet handling by
> devices along the PW (not at the ends) for the two types.

But you do need somethng to distinguish them.

> The endpoints can use NSPs that look at the EtherType.

There is no EtherType to distinguish them unless you are using a PW
that has an Ethernet payload in which case you also have the extra
initial 12 or 16 bytes we are trying to avoid.

With a PPP PW you do have 2-byte codes points which pretty much serve
the same purpose but they are PPP code point and avoid the unless
initial 12 or 16 bytes.

> I was not aware that there are PPP protocol numbers for TRILL,
> which indeed would enable WireShark to continue dissecting.
> Unfortunately, the WireShark PPP dissector that I have does not seem
> to be aware of these allocations.
>
> I understand that using a PPP PW is an easy way out, but I don't
> think that it is the cleanest way of accomplishing what you want.

Just saying the word "clean" with nothing more specific does not seem
to me to be a good reason to create a new PW type and make life a
bit harder for dissectors. You haven't shown me there is anything
wrong with using a PPP PW and, in fact, in your first comments, you
said that doing so was "OK".

> BTW, if your proposal is to use an existing PW type,
> is this a BCP or a PS ?

As stated on the title page, Proposed Stadard. Standards track seems
to be the most common status for X over Y (or X transported by Y)
RFCs. They may not change X or Y but they specify the standard method
or methods at the interface, perhaps restricting what X options or Y
options are used, perhaps specifying how to map certain fields between
X and Y, etc. And where they are multiple options, usually standardizing
a mandadatory to implement set for interoperability.

RFC 6361, TRILL over PPP, is a Proposed Standard.

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

> Y(J)S
>
> -----Original Message-----
> From: Donald Eastlake [mailto:[e-mail]]
> Sent: 10 October, 2013 05:23
> To: Yaakov Stein
> Cc: [e-mail]; Stewart Bryant (stbryant); Andrew G. Malis
> Subject: Re: WG LC on draft-ietf-trill-o-pw
>
> 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