Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
draft-ietf-trill-rbridge-channel-08

I don't think my Comments warrant a Discuss, although I personally "would not have done it like this".

---

There is an assumption here that bridge alert (just like router alert)
is an acceptable function. I am not convinced and I note RFC 6398 that
seems to suggest that router alert is not a good idea in general, 
although not catastrophic in certain deployments that might be similar
to early Trill deployments.

But I worry that if the popularity of Trill grows, the bridge alert
function will cause many of the same problems it caused in IP networks.

It is worth noting that MPLS (and you do draw the comparison with G-ACh)
has a router alert label, but this is not used on the G-ACh.

At the very least, the use of bridge alert causes packets to be thrown
out of the normal forwarding path at each bridge along the path. This
means that packets are not treated the same way as data packets and so
some of the properties of OAM are lost. (Note that if you want to send
an OAM packet to a transit bridge, you will use bridge alert and all 
other transit bridges along the path up to the intended target will need
to inspect the packet.)

---

Section 3.2

What is the meaning of 
    0    - Not an RBridge Channel error frame.
I didn't finf itdiscussed in the text.

Why is
   15    Reserved
And what does "reserved" mean? IANA will need to know whether it means
"never to be allocated".

---

Why are Channel protocol numbers 0 and xFFF reserved? (And you will need
to clarify to IANA that you mean "reserved and not to be allocated".)

---

I wasn't clear about the Security aspects. I understand that if a 
payload protocol needs protection, it is responsible for this itself.
However, is there any way to protext the content of the channel header?
What would be the consequence of someone tweaking the SL bit?

Since Trill (and Ethernet) are routed sysetms (unlike MPLS) attacks 
from outside seem feasible. While you might protect the payload 
protocols through their own mechanisms, how do you protect the bridges
themselves from attacks? The rbridge channel and the bridge alert flag
see like vectors for DoS.

Rate limiting as described in 2.4 provides some mitigation. Maybe you 
should reference this in the security section.

Thanks for the IANA Considerations changes.  I'm fine with -07.

I only have two minor comments on this document:

1. The introduction contains the following standalone sentence: "Familiarity with [RFC6325] and [RFC6327] is assumed in this document."  What is the purpose of this sentence given that both references are listed as normative?

2. Section 3 says that these channel messages are subject to the usual TRILL message checks and then lists some checks that are performed.  I would suggest making an explicit reference to the document that defines those checks and list any that are not performed on channel messages.

I support Stephen's discuss positions.

"No protection is provided against forging of the ingress nickname
in a TRILL Data formatted channel message or the Outer.MacSA in a
native RBridge Channel frame. This may result in misdirected return
responses or error messages." Can you explain why this is ok? (Not
sure if some text change might follow or not.)

Thank your for addressing my concerns.