[incoming AD ramping up on document reviews; please treat as No
Objection with COMMENT]
I'm confused at what exactly constitutes a "Smart-Hello" -- Section
4.1 says that it "is a type of TRILL ES-IS PDU, which is specified
in [RFC8171]". The reference does not use the term, so I assume
that the reference is just for ES-IS PDUs. So, reading on, the
payload consists of TRILL IS-IS TLVs. Quoting judiciously:
[...] Both types of Smart-Hellos MUST include a
Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
[...]
[...] If
no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart-
Hello is ignored.
The first makes me think that the presence of Smart-Parameters makes
a Smart-Hello, but he second implies that a Smart-Hello can exist
without one (even if it would always be ignored).
If just the presence of a particular Smart-foo implies that an
entire TRILL GENINFO is a Smart-Hello, then I'm concerned about the
reuse of existing TLVs for subtly different purposes, like the
Neighbor TLV becoming the "Smart Endnode neighbor list"? This could
be problematic for implementations that do not support Smart-Hello
messages, which would then misinterpret the Neighbor TLV, etc.
I'm also a little unclear on the story for authentication and
protection against the injection of bogus messages. The
Authentication TLV can be used for the Smart-Hellos, which is good
(but why is it not required?), and I suppose I can't complain
terribly hard about the security model of "if you're authorized to
send, you're authorized to send anything" which is to large extent
universally deployed. But, we only say that the Edge RBrige "MAY
filter the encapsulation frame based on the inner source MAC and
Data Label as specified for the Smart Endnode." -- why can this not
be a MUST, to prevent spoofing/injection? In a similar vein,
stronger conditions could be imposed if hybrid ports are disallowed,
but I don't know how feasible that is (or what actual hybrid port
deployments look like).
In Section 5.2:
The attached edge RBridge processes and forwards TRILL Data packets
based on the endnode property rather than for encapsulation and
forwarding the native frames the same way as the traditional
RBridges.
This left me confused for quite some time. Is the "for
encapsulation" supposed to be "by encapsulating"?
o If receiving a unicast TRILL Data packet with RB1's nickname as
egress from the TRILL campus, and the destination MAC address in
the enclosed packet is a MAC address that has been listed by a
"Smart Endnode", RB1 leaves the packet encapsulated to that Smart
Endnode. The outer Ethernet destination MAC is the destination
Smart Endnode's MAC address, the inner destination MAC address is
either the Smart Endnode's MAC address or some other MAC address
that the Smart Endnode advertised in its Smart Hello, and the
outer Ethernet source MAC address is the RB1's port MAC address.
This is describing modifications that RB1 makes to the received
Ethernet frame containing and encapsulated TRILL Data packet, right?
It might be more clear to describe this as a transformation than a
declarative statement about the nature of the Ethernet frame.
Perhaps
NEW:
o If receiving a unicast TRILL Data packet with RB1's nickname as
egress from the TRILL campus, and the destination MAC address in
the enclosed packet is a MAC address that has been listed by a
"Smart Endnode", RB1 leaves the packet in an encapsulated
form, targetted to that Smart Endnode. It changes the outer
Ethernet destination MAC to the destination Smart Endnode's
MAC address, the inner destination MAC address remains as
either the Smart Endnode's MAC address or some other MAC
address that the Smart Endnode advertised in its Smart Hello,
and the outer Ethernet source MAC address used for the last
hop is the RB1's port MAC address.
In Section 6
[...] The
solution for the MAC flip-flopping issue is to set a multi- homing
bit in the RSV field of the TRILL data packet.
I think this is supposed to be the 'M' bit that is allocated in the
Smart-MAC APPsub-TLV?
[...] (An alternative solution
would be to use the ESADI protocol to distribute multiple attachments
of a MAC address of a multi-homing group, The ESADI is deployed among
the edge RBridges (See section 5.3 of [RFC7357])).
This seems like a teaser of an aside that seems like it should either get
expounded upon, for example with a comparison against using the M
bit as previously described, or removed.
-Benjamin
_______________________________________________
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill
