Re: [trill] Alissa Cooper's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

2017-01-19 Thread Alissa Cooper 

> On Jan 18, 2017, at 2:02 PM, Donald Eastlake  wrote:
> 
> Hi Alissa,
> 
> On Wed, Jan 18, 2017 at 10:58 AM, Alissa Cooper  wrote:
>> 
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> --
>> COMMENT:
>> --
>> 
>> Since this document implies the creation of centralized databases of
>> addressing information, I think it would help to call out in Section 6
> 
> Yes, although such centralized databases are quite common currently in
> terms of data center management and orchestration system databases.
> 
>> the need to secure the directory contents themselves, not just against
>> abuses of the push or pull services but in general against unauthorized
>> access.
> 
> OK.
> 
> I'm not sure the need to secure directories resident on TRILL switches
> is that much different from the need to secure the routing function
> and routing data of TRILL switches. But the draft also supports Pull
> Directories hosted on end stations and I think something should be
> said about end station security in connection with the end station
> hosting a directory.

Sounds good.

> 
>> Also, I recall in prior evaluations of TRILL documents some discussion
>> about how TRILL deals with ephemeral MAC addresses and my recollection is
>> that they are likely prohibited by policy on TRILL networks. But if there
> 
> The payload of a TRILL Data packet looks like an Ethernet frame. TRILL
> delivers it to end station(s) based on the destination MAC address
> and, by default, learns about MAC reachability by observing the source
> MAC address. So, while I would not say ephemeral or frequently
> changing MAC addresses are prohibited by "policy", they would reduce
> the efficiency of a TRILL campus by frequently obsoleting learned MAC
> reachability information.
> 
>> is some interaction between ephemeral MAC addresses and the services
>> described in this document that would be good for implementors to be
>> aware of, those are probably worth mentioning.
> 
> Directories need not be complete. If, for example, there were servers
> with fixed MACs and clients with mostly ephemeral MACs, I think it
> would still be reasonable to have the reachability (edge attachment
> point) information for the fixed MACs in a directory. Something about
> this could be added to the draft.

I think that would be helpful.

Thanks,
Alissa

> 
> Thanks,
> Donald
> ===
> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-rfc6439bis-04: (with DISCUSS)

2017-01-19 Thread Alvaro Retana (aretana) 
Donald:

Hi!

I am not concerned about the case you described below: where the source and 
destination are attached to the same switch.  Nor am I concerned about transit 
TRILL data packets.

I am concerned about the case where the other end stations are not attached to 
any of the local switches, but are somewhere else in the campus (or the mixed 
case where some of the other end stations are attached to an overloaded switch, 
but others are elsewhere).  In that case, if I am not missing anything, the 
appointed forwarder for the local link will accept the native frame and will 
have to send a TRILL Data Packet across the campus – the information to do that 
may not be available if the switch is overloaded.

Thanks!

Alvaro.

On 1/18/17, 11:43 PM, "Donald Eastlake" 
mailto:d3e...@gmail.com>> wrote:

Hi Alvaro,

On Wed, Jan 18, 2017 at 3:32 PM, Alvaro Retana 
mailto:aret...@cisco.com>> wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-trill-rfc6439bis-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

--
DISCUSS:
--

Section 2.4 (Overload and Appointed Forwarders) talks about potential
Appointed Forwarders which are overloaded.  In IS-IS, a node with the
overload bit set "shall not" (ISO 10589) be considered for transit.
However, the use of "SHOULD NOT appoint an RBridge in overload" and
"SHOULD re-assign VLANs from the overloaded RBridge" leaves a potential
hole in the proper forwarding of TRILL data packers.  Why aren't MUST
NOT/MUST used?  Is there something in the specific use of IS-IS by TRILL
that I am missing?

The Appointed Forwarder function has to do with accepting frames from
end stations for ingress and egressing frames to end stations. It does
not have anything to do with TRILL Data packet transit routing.

Consider the following case: two TRILL switches (RBridges) RB1 and RB2
are connected by a link L1 that also has end stations on it. The end
stations are all in VLAN X. There are other end stations in VLAN X in
the TRILL campus not on L1 but all of these other end stations are
directly connected to RB2. RB2 is in overload.

Under these circumstances, RB2 should be the Appointed Forwarder for
VLAN X as that way traffic between all of the VLAN X end stations can
be forwarded by RB2 without any IS-IS routing at all. RB2 will just
be, in effect, forwarding native frames between RB2 ports (although,
for consistency, the TRILL specifications say that RB2 ingresses this
VLAN X traffic by encapsulating it into a TRILL Data frame, and then
notices it is destined for an end station on a local port, immediately
decapsulates it, and sends it out that port).

I think this should be an easy DISCUSS to clear; either point to the
piece I'm missing, or don't use an overloaded node.

Thanks,
Donald
===
Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Stephen Farrell's No Objection on draft-ietf-trill-rfc6439bis-04: (with COMMENT)

2017-01-19 Thread Stephen Farrell 
Stephen Farrell has entered the following ballot position for
draft-ietf-trill-rfc6439bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-rfc6439bis/



--
COMMENT:
--


- section 6: is port-shutdown a new potential DoS vector?
Shouldn't that be noted here and/or in section 9?


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

2017-01-19 Thread Stephen Farrell 
Stephen Farrell has entered the following ballot position for
draft-ietf-trill-directory-assist-mechanisms-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/



--
COMMENT:
--



- 2.6: I wondered why this was useful. Is it for cases where
the secondary push service is differently connected or is it
in case the primary goes down? Might be good to say.

- section 6: what security mechanism differences are there
between the push and pull cases? Why aren't those called out
here?  Forcing the reader to delve into the various other
security mechanism RFCs and figure this out themselves seems
less good.

- section 6: apologies if I asked this before (in which case I
forget the answer;-) but how fictional/real is the crypto
stuff with TRILL in terms of the likelihood of it being
actually used? I ask again, as if the crypto stuff is mostly
fictional, then I think you ought note that here, given the
attack surface that the directory function creates.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Mirja Kühlewind's Abstain on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

2017-01-19 Thread Mirja Kuehlewind 
Mirja Kühlewind has entered the following ballot position for
draft-ietf-trill-directory-assist-mechanisms-11: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/



--
COMMENT:
--

It's not clear to me why a new protocol for the pull case is needed
(instead of using an existing one). However, I also don't have enough
background knowledge on trill to make a judgement here.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)

2017-01-19 Thread Alexey Melnikov 
Hi Donald,

> On 19 Jan 2017, at 05:16, Donald Eastlake  wrote:
> 
> Hi Alexey,
> 
>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov  
>> wrote:
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> --
>> DISCUSS:
>> --
>> 
>> In Section 3.1 there is a Version field. What are the condition(s) for
>> bumping this version number? What backward compatibility guaranties are
>> expected (if any)? How would version negotiation be done?
> 
> Well, I could say that the answers to all of your questions are about
> the same for this Version field as they are for the RBridge Channel
> Header version field [RFC7178], the TRILL Header version field
> [RFC6325], and many other version fields in IETF protocols but you
> probably wouldn't consider that a very good answer.
> 
> I suppose if text was being added along this lines, it should say that
> the version number must be incremented for a specification that does
> not just specify new field values where that is allowed in version
> zero but cannot be correctly parsed beyond the version nibble. Since
> the protocol is a request/response protocol, the responder should
> indicate the highest version number they understand but the response
> must be valid in the version number specified in the request including
> the possibility of indicating a valid error saying that the version is
> not implemented. Thus all implementations of version X would need to
> be able to at least send such an error for all versions from 0 through
> X-1. Then you would add an explicit suberror code in Section 3.6.3 for
> unimplemented version. For a version zero implementation, that would
> be returned for any higher version.
> 
> However, I don't expect an incremented version number to be needed
> anytime soon. Was it your intent with this DISCUSS to get something
> like the above added to the draft?

Yes, exactly along the lines of your text above.


___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill