Subject: Re: [RTG-DIR] Review of draft-ietf-trill-over-ip-08

From: Ines Robles <[email-masked]>
Date: Tue, 3 Jan 2017 20:30:37 +0900

Hi,

I agree with your comment,

thank you,

Cheers,

Ines.

On 30.12.2016 02:43, Donald Eastlake wrote:
>>                  Section 4.5: TRILL Over IP IS-IS SubNetwork Point of Attachment
>>                          I think it would be nice to add in the text the meaning of "111111"
>> depicted in the figure.
> Humm... Those are the first digits of vertically arrayed bit numbers
> (10 through 15). So, since it would fit, maybe we should make those
> bits one character space wider so the bit number can be horizontal
> rather than vertical. I think that would be clearer.
>
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 10:56:30 -0800

Some observations:

- the title is misleading; this is TRILL over UDP, not trill over IP.

- the use of two different ports invites some potentially unintended
problems, e.g., selective blocking of the control vs. data plane. IMO,
given that TRILL's purpose is to extend Ethernet (not IP), this service
would be better served using a single port and differentiated
encapsulated traffic by whatever method TRILL nodes use internally.
Otherwise, this spec needs to include specific description of unexpected
behavior, e.g., data frames on the IS-IS port and IS-IS frames on the
data port.

- regardless of whether one or two ports are requested, this doc should
provide the needed information for IANA (e.g., a service name and
description compliant with RFC6335).

- the section on MTU handling might benefit from informationally citing
intarea-tunnels, and consider using the recommendations there. In
particular, it's not sufficient to assume IPv4 supports 576 byte MTUs
(that's the minimum receiver reassembly MTU, not the transit MTU). That
section should also address issues of PMTUD and PLMTUD.

FWIW.

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 4 Jan 2017 20:43:10 -0500

Hi Joe,

Thanks for the comments.

> - the title is misleading; this is TRILL over UDP, not trill over IP.

Humm... The two encapsulations specified do use UDP and it seems
implausible that TCP would be used. But it is possible someone would
want to use SCTP or some other non-UDP IP encapsulation. That would
presumably be via some future document. So I guess, on balance it
would be better to change the title as you suggest.

> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the

I guess I don't see this.

As for selective blocking, if someone can control the passing of
traffic through links connecting TRILL switches, they can always block
a subset of traffic based on whatever criteria they want. I don't
think it makes significant difference what header field they look at.

Similarly, if someone can modify traffic passing through links between
TRILL switches, if the traffic is IP they could swap around port
numbers, but they could also swap around other header fields.
Presumably it is a policy decision for network managers based on their
threat model whether or not to use facilities by TRILL or otherwise to
provided to secure control traffic and/or use link security to protect
all traffic over a link. (Similarly, it is a matter for end system
users/managers to decide whether to use end-to-end security.)

I suppose we could throw in a few sentences saying that if security is
not being used and data or control is mislabeled as the other and it
happens to be parseable as the other, you will get junk in the data
stream or screwed up control information. But I don't think the
mislabeling of control and data as the other by TRILL code is a
realistic problem. It would be detected by the crudest of testing.

> description compliant with RFC6335).

OK.

> section should also address issues of PMTUD and PLMTUD.

I'll take a look at that draft in this context.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Jan 2017 10:44:37 -0800

Hi, Donald,

> I guess I don't see this.
It's a configuration issue - what happens when (not if) a sysadmin opens
up one port but not the other?

IMO, unless there's a reason for that sort of selective filtering or
there's a specific need to encapsulate the traffic differently, these
ought to be treated as a single service - TRILL UDP encapsulation.

It's only inside the TRILL system that the difference between data and
IS-IS is useful and this encapsulation will have no effect on those nodes.

> think it makes significant difference what header field they look at.

I'm thinking of the increased complexity and potential for failure by
not "fate sharing" data and IS-IS traffic.

> users/managers to decide whether to use end-to-end security.)
I'm asking whether you actually expect or want IP transit nodes to treat
data and IS-IS traffic differently - via different routes, different
drop policies, etc. If not, then there's no benefit from having two
service ports.

> stream or screwed up control information. 
TRILL data and IS-IS is already treated differently inside a TRILL
campus, e.g., by their existing headers. I can't see data being treated
as IS-IS or vice versa inside the campus, regardless of which port the
traffic arrives on.

That's largely my point - if the encap/decap node wouldn't need to treat
these differently in either direction (leaving or entering the TRILL
campus), then they're one service.

> But I don't think the

It *can* be detected, but your protocol needs to specify the correct
behavior. Is the UDP tunnel ingress/egress supposed to prevent such
mislabeling on ingress? If so, why would it care? If not, then again
there's no point to two services.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Jan 2017 11:00:57 -0800

PS - I have a broader question about this work.

Why is this a service at all?

There are dozens of ways of taking existing IP or Ethernet traffic and
encapsulating them for IP tunnel transit, some including much stronger
protections (e.g. SEAL/AERO provides better fragmentation/reassembly
support).

Why not use one of those existing services?

The only thing this saves is the link header/trailer overhead, but then
it also begs the question of the identity of these tunnel endpoints
within the TRILL system (which are indicated by addresses used in those
link headers).

(if there is an answer to this, it really should be included in the intro)

Joe