Skip to main content

TRILL (Transparent Interconnection of Lots of Links) Over IP Transport
draft-ietf-trill-over-ip-17

Discuss


Yes

(Alia Atlas)

No Objection

(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Kathleen Moriarty)
(Suresh Krishnan)
(Terry Manderson)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

Warren Kumari
No Objection
Comment (2018-03-07 for -15) Unknown
Balloting NoObj in the "I've read the protocol action, and I trust the sponsoring AD so have no problem." sense of the term.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Mirja Kühlewind Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2018-03-29 for -16) Unknown
Usage of encapsulation schemes
----
The document does not clearly explain and justify why different encapsulations are needed. The document should more extensively discuss the different properties and trade-offs for each encapsulation and give clear recommendations when you to use which encapsulation. E.g. the document does not clearly specify when to use IPSec (besides saying „if security in needed“), however, the document needs to explain more clearly what is meant by this: given the over-the-Internet path is always not trusted, does that mean that IPSec should always be used in that scenario? Why is IPSec specified instead of using TLS or DTLS with the TCP or UDP encapsulations respectively? Why is both UDP and TCP encapsulation needed, given that UDP is the default that is mandatory to implement anyway? Why are the short-comings of UDP and when is it recommended/beneficial to switch to TCP?

DSCP
-----
1) Section 4.3 should also talk about decapsulation as DCSP is often overwritten on the path and therefore the DCSP of the inner and other IP headers can differ on decapsulation. Please see RFC2983 for further guidance. You probably should specify to discard the outer DSCP at tunnel egress in your use case.

2) Further it is not clear to me if the use of CS7 in appropriate for this use case as RFC 4594 says
"   o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class."

3) Moreover, if my understanding is correct, the high priority classes in TRILL are not exclusively reserved for control data. However, CS6 and CS7 is only meant for control and rounting traffic. If those classes are used it must be ensure that the traffic send with these DSCP is not overloading the network. I think further (security) considerations are needed here. 


Broadcast Link Encapsulation Considerations
------
Not every transport encapsulation can be used for Broadcast/Multicast. TCP cannot be used. This is mention later but also be consider in the text in section 5.3

TCP Encapsulation
-----
If my understanding is correct than TRILL does not know that the connect of a TRILL data packet is. That means the data could can also contain traffic that is running over TCP, right? Encapsulating TCP in TCP should generally avoided if possible and need further considerations as loss in the outer control loop that is used on the TRILL IP link appears as strongly varying delays to the inner control loop and therefore can have very negative effects.

TCP Connection Establishment (section 5.6.1)
-----
This section seem to assume for all configured or discovered tunnel endpoints should  immediately (at node start up time) and permanently open one/multiple TCP connections. I'm in general uncertain if this is the right approach. However, even if the connection is not closed, it might not be usable after an idle time, as middlebox on the path may have removed their state. Therefore, to keep a connection permanently open, the endpoint need probably to send keep-alives, or alternative a mechanism to detect such a failure (quickly) and re-establish the connection such be used. Alternative, a connection could be open and closed when needed. In this case also more recommendation is needed when to open and close the connection(s).

Fragmentation
----
The fragmentation problem for Internet links is not sufficiently addressed. trill requires a minimum size of 1,470 bytes while most Internet paths only support an MTU of 1,470 bytes which will automatically lead to fragmentation when encapsulation is added. It can not be assumed that all Internet path support IPv6, therefore the recommendation "if fragmentation is anticipated with the encapsulations specified in this document, the use of IPv6 is RECOMMENDED" is often hard to realize. I assume that many trill IS-IS packets are smaller than 1,470 bytes thus fragmentation might not occur, however, for larger packets I would rather recommend to implement an additional mechanism to enable segmentation above UDP (+ PMTU discovery) or the use of TCP. In any case more clear recommendation is needed.

Port assignment
----
Only one port per service can be assigned (see principles in rfc6335 and guidelines in rfc7605). Therefore the spec should be changed to the use of one ports and describe how different kinds of packets can be distinguished by other means (which should be easily possible to my understanding). Further, it is expected that the document confirms that any new security added later on will also use the port assigned (i.e., future versions will not be eligible for new ports
e.g. for a “TLS” variant).
Alia Atlas Former IESG member
Yes
Yes (for -15) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2018-03-18 for -15) Unknown
Based on my conversation with DEE, I understand that the HMAC is always computed over a value which is disjoint with the HKDF-Label. This is not really cryptographically ideal -- as I stated in my review, you should be HKDFing two keys off the same key -- but it does imply that the trivial attack doesn't work, so I'm removing my DISCUSS. As we discussed, please add some explanation of why this is a non-issue to the document.
Ignas Bagdonas Former IESG member
No Objection
No Objection (2018-04-04 for -16) Unknown
s/IS=IS/IS-IS
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2018-04-03 for -16) Unknown
This draft has received significant attention from the transport area while I was recovering from pneumonia, so I'm balloting No Objection while noting a couple of things that I'm confused about, that I haven't seen mentioned previously, and trusting people to Do The Right Thing.  Otherwise, I'll sit with my hands folded quietly, and watch the Discussion on Mirja's ballot position with interest.

I have (at a Comment level) the same curiosity that Mirja included in her Discuss ballot about why both UDP and TCP encapsulations are included. My curiosity extends to whether NAT traversal being out of scope for this document makes sense, given that one of the use cases given is

3.1 Remote Office Scenario

   In the Remote Office Scenario, as shown in the example below, a
   remote TRILL network is connected to a TRILL campus across a multihop
   IP network, such as the public Internet.

If NAT traversal were in scope, offering both TCP and UDP encapsulations would make more sense - TCP and UDP are treated differently enough at NATs and firewalls that HTTP/2 over QUIC/UDP uses HTTP/2 over TCP as its fallback. But it might be worth thinking about what would be required to make this work well over the public Internet. That doesn't have to be in this document, of course.

I see that Mirja has asked about the request to allocate two port numbers in this draft, one for TRILL IS-IS, and the other for TRILL Data. I'm reading this text

  The Link Header and Link Trailer in these formats depend on the
   specific link technology. The Link Header contains one or more fields
   that distinguish TRILL Data from TRILL IS-IS. For example, over
   Ethernet, the Link Header for TRILL Data ends with the TRILL
   Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS-
   IS Ethertype; on the other hand, over PPP, there are no Ethertypes in
   the Link Header but different PPP protocol code points are included
   that distinguish TRILL Data from TRILL IS-IS.

as saying that those two types of packets could be distinguished, if they were carried over a single five-tuple. I'd offer that the conversation about allocating two port numbers would terminate more quickly if you could explain whether I'm misreading that text, so that you really can't distinguish between these two packet types, or whether there is some other reason why you'd want to avoid fate-sharing between these two packet types that seem to make up an adjacency.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -15) Unknown