Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Nov 2012 13:13:02 -0800

We would really like to she some more explicit indications from WG 
participants that they have read this document and agree with it.

Please include any substantial as well as editorial improvements that 
result from reviewing the document.

    Erik

On 10/25/12 3:55 PM, Donald Eastlake wrote:
> This message begins a TRILL WG two week Last Call on the
> draft-ietf-trill-directory-framework draft.
>
> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street, Milford, MA 01757 USA
>   [email-masked]
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Radia Perlman <[email-masked]>
Date: Wed, 14 Nov 2012 13:34:30 -0800

I've never been fond of "framework" documents, but this is fine for
describing the problem.  If it's supposed to be complete in some sense
(whatever that means for a "framework"), it's missing some things that
people suggested last week, e.g., the ability to be informed of an ACL
policy, to make, e.g., a hypervisor have an endnode table that has (IP
address, MAC address, TRILL switch address, only allowed from this set of
MAC addresses).

And there might be other information we'd want pushed or pulled, e.g., IPv4
and IPv6 address.

Is it clear that the framework document doesn't preclude these extra things
even though I don't think they are in the draft?

Do we really need a framework document instead of just a single WG document
on formats and algorithms that perhaps has a few paragraphs to explain why
a directory is useful?

Radia

On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark <[email-masked]> wrote:

>> draft-ietf-trill-directory-**framework draft.
>>
>> Thanks,
>> Donald
>> ______________________________**_________________
>> trill mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/trill<https://www.ietf.org/mailman/listinfo/trill>
>>
>>
> ______________________________**_________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/trill<https://www.ietf.org/mailman/listinfo/trill>
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Nov 2012 15:55:32 -0800

On 11/14/12 1:34 PM, Radia Perlman wrote:
> address, MAC address, TRILL switch address, only allowed from this set
> of MAC addresses).
> And there might be other information we'd want pushed or pulled, e.g.,
> IPv4 and IPv6 address.
> Is it clear that the framework document doesn't preclude these extra
> things even though I don't think they are in the draft?

The reason for having the separate framework document is to enable the 
WG to discuss and get consensus around the general direction - the set 
of problems to solve and how they fit with current TRILL - without 
getting into details such as which protocol to use to pull information 
out the directory.

> Do we really need a framework document instead of just a single WG
> document on formats and algorithms that perhaps has a few paragraphs to
> explain why a directory is useful?

If there was more WG discussion around the directory assisted approach 
and the discussion indicated a clear direction, then we might be able to 
simplify this into one draft.

Regards,
    Erik

> Radia
>
> On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Please include any substantial as well as editorial improvements
>     that result from reviewing the document.
>
>         Erik
>
>
>         draft-ietf-trill-directory-__framework draft.
>
>         Thanks,
>         Donald
>            Donald E. Eastlake 3rd +1-508-333-2270
>         <tel:%2B1-508-333-2270> (cell)
>         [email-masked] <mailto:[email-masked]>
>         _________________________________________________
>         trill mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/trill
>         <https://www.ietf.org/mailman/listinfo/trill>
>
>
>     _________________________________________________
>     trill mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/trill
>     <https://www.ietf.org/mailman/listinfo/trill>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 15 Nov 2012 20:31:56 +0000

Radia,

Thanks for the comments.
Want to clarify that "draft-ietf-trill-directory-framework" is only intended to describe the benefits of directory assistance for TRILL network and the high level stuff (e.g. basic Pull/Push models). The draft is not intended for describing the detailed mechanism.

The mechanism which we discussed last week is described in "draft-dunbar-trill-scheme-for-directory-assist" (which is still a personal draft).

I think it is necessary to have the framework document so that we don't have to justify why directory assistance is needed for TRILL. We already spent 3 IETF meeting cycles to justify why we need directory assistance. It will be more productive to separate justification from the mechanisms, so the discussion can be focused.

As for describing policy (or ACL in your email), we discussed to add as responses to Pull request to the detailed mechanism. I can add a simple statement in the framework to indicate that Policy can be added and leave the details to the mechanism draft.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Wednesday, November 14, 2012 3:35 PM
To: Erik Nordmark
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

I've never been fond of "framework" documents, but this is fine for describing the problem.  If it's supposed to be complete in some sense (whatever that means for a "framework"), it's missing some things that people suggested last week, e.g., the ability to be informed of an ACL policy, to make, e.g., a hypervisor have an endnode table that has (IP address, MAC address, TRILL switch address, only allowed from this set of MAC addresses).

And there might be other information we'd want pushed or pulled, e.g., IPv4 and IPv6 address.

Is it clear that the framework document doesn't preclude these extra things even though I don't think they are in the draft?

Do we really need a framework document instead of just a single WG document on formats and algorithms that perhaps has a few paragraphs to explain why a directory is useful?

Radia
On Wed, Nov 14, 2012 at 1:13 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>> wrote:

We would really like to she some more explicit indications from WG participants that they have read this document and agree with it.

Please include any substantial as well as editorial improvements that result from reviewing the document.

   Erik

Thanks,
Donald
=============================
  Donald E. Eastlake 3rd   +1-508-333-2270<tel:%2B1-508-333-2270> (cell)
  155 Beaver Street, Milford, MA 01757 USA
  [email-masked]<mailto:[email-masked]>
_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trill

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 16 Nov 2012 12:30:21 -0800

Authors,

Please find my detailed comments (with %sam) regarding this draft.

cheers
-sam

1.  “This draft describes why and how Data Center TRILL networks can be
   optimized by utilizing a directory assisted approach.”.
%sam – 'How' is part of the solution document isn’t it?
 
2.  Sec 3 – “Unnecessary filling of slots in MAC table of edge RBridges RB1,
        due to RB1 receiving broadcast/multicast traffic (e.g. ARP/ND,
        cluster multicast, etc.) from end stations under other edge
        RBridges that are not actually communicating with any end
        stations attached to RB1.”
%sam - Where is RB1? It is not indicated in the picture. 

3.  Sec 4 – “If the application location information can
   be fed to RBridge edge nodes, in some form of Directory Service,
   then RBridge edge nodes won't need to flood data frames with unknown
   DA across the TRILL campus.”
%sam – You may want to clarify here - Does flooding happen when the DA is not present in the Directory. If not, I see a problem. How do you account for the dropped frames. In traditional model, the frames are broadcasted and not dropped.

4.  Sec 4 – “It can trust the directory to tell it where
         the DA is or it will discard the frame if the directory says
         the DA does not exist in the campus.”
%sam- Little confused and same concern as above . Are you saying that the frame is dropped if the DA is not present in the directory. Shouldn’t it flood just like in regular case?

5.  Sec5 – “The {list of interested RBridges} would get populated when an
   RBridge queries for information, or pushed down from management
   systems.”
%sam – Is the document describing the framework for how and when a specific model should be used to populated. Could both pull and push exist at the same time?

6.  Sec 5.3“Under this model, it is recommended that the ingress RBridge simply
   drops a data packet (instead of flooding to TRILL campus) if the
   packet's destination address can't be found in the MAC&VLAN<->Egress
   RBridge mapping table.”
%sam – What is the rationale for this recommendation? How do you know the Directory server has upto date dB that it pushes down to RBridge? If the dB is not consistent, wouldn’t the unknown unicast frames get dropped as per the above?

7.  “The detailed method and hand-shake mechanism between RBridge and Directory Server(s) is beyond the scope of this framework draft.”
%sam – How does the Directory server know whether to push, full or partial info to an RBridge, if there is no handshake mechanism? FW should identify those requirements.

8.  %Sam - On the same lines,If there exists more than one directory server, what are the requirements for both Push and pull models. For ex: How does RBridge know from where to pull the data or which dir server know to push the entries onto the RBridge?

9. For words like should, must, could you use caps SHOULD, MUST etc. Think there is a RFC for the same.

10. Sec 5.3 "There are several options to trigger the pulling process.
   For example, the RBridge edge node can send a pull request whenever
   it receives an unknown DA, or the RBridge edge node can simply
   intercept all ARP/ND requests and forward them to the Directory
   Server(s) that has the information on where the target stations are
   located."
%Sam - I think the options when to pull should clearly be identified and listed, rather than as an example.

11. Sec 6. "Therefore, we suggest TRILL consider directory assisted approach(es).
    This draft only describes the basic framework of using directory
    assisted approach for RBridge edge nodes. More complete mechanisms
    will be described in separate drafts."
%sam - Are you saying, there are complicated mechanisms for Directory assisted approach? What do you mean by basic FW?

12. %sam - Security considerations should take into account of securing the dB of the directory server as well.

13. %sam - May be I am missing the bigger picture for the scope of this draft. Draft describes two different models for directory assisted TRILL N/w. What I fail to see in the draft is the list for requirements for each of those. Should all the requirements be clearly identified and laid out in the draft as well? I do not think the requirements belong in solution document. For example: In Pull model, requirement for 'what should happen when the request time-out? What are the requirements when Directory server reboots? etc. I fail to see those things clearly identified in the document.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Nov 2012 09:59:35 -0500

I have read the document, and want to raise some basic questions about
this document.

An original premise for this document was that it would use the same
Ethertype=0x8100 encoding for the inner header as the the base
protocol. This was done for backwards-compatability with base RBs and
to allow non-FGL aware RBs to forward FGL frames. Under this
assumption, having the labels split into two different parts using
separate fields made sense.

However, with the -01 revision, the above assumption has been thrown
out. FGLs now use a different ethertype encoding, and various parts of
the document make it clear that an RB operates in either FGL or VL
mode, with no overlap or backwards compatability. RBs implementing VL
are not supposed to receive or process FGL formatted TRILL data
frames.

Given that, I do not see a compelling justification for retaining the
"double tagging" encoding format the current document
supports. Specifically, I'd suggest:

1) not having separate high-order and low-order FGL fields; just
define one field that is 24 bits long.

2) Remove the second ethertype=0x893B field completely. We are just
wasting 2 bytes. (the field serves no useful purpose and must always
hold the value of 0x893B.)

3) While I don't have a strong opinion either way, I would also like
to see a justification for having an "Alternate Priority" field. The
base TRILL protocol doesn't have one. Why is it needed for FGLs?

Under the previous encapsulation format, we got the extra priority
"for free" since it was part of the TAG, but I'd like to see the
rational/use case for having this extra field stand on its own
merits. Is this just a "what the heck, why not" field? Or is there a
compelling use case for it?

I am also uncomfortable with some of the wording in the document
regarding "silicon".

>    2. Silicon Considerations
> 
>       Fine-grained labeling (FGL) should, to the extent practical, use
>       existing features, processing, and fields that are already
>       supported in at least some fast path silicon implementations that
>       currently support the TRILL base protocol.

This makes sense. We do not want to pick encodings that will be
problematatic for silicon (generally).  However, we also need to
balance such a desire against not restricting our design solely to
favor, say, one particular implementation. (I am not suggesting that
is being done here, just pointing out that if the current encoding
does favor certain implementations, we need to be upfront about that,
and discuss the implications openly.)

>    2. Silicon Considerations: Existing TRILL fast path silicon chips can
>       perform base TRILL Header insertion and removal to support ingress
>       and egress. In addition, it is believed that most such silicon
>       chips can also perform the native frame to FGL mapping and the
>       encoding of the FGL as specified herein, as well as the inverse
>       decoding and mapping. Some existing silicon can perform only one
>       of these operations on a frame in the fast path and is thus not
>       suitable to implement fast path TRILL FGL processing; however,
>       other existing chips are believed to be able to perform both
>       operations on the same frame in the fast path and are suitable for
>       FGL implementation.

My impression in talking to folk familiar with silicon implementations
is that silicon has gotten pretty good at being able to extract fields
from fixed arbitrary offsets into a packet. Thus, while they may be
able to extract the two separate labels and combine them (as the
current proposal calls for), they can just as easily extract a single
label of 24 bits.

If we are going to stick with the current encoding, I'd like to hear
directly from the silicon implementors why that is *necessary* and why
they cannot support the more natural/obvious format for 24-bit labels.

I have additional comments on the draft, but they may not be relevant
depending on how the above points are resolved.

Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 19 Nov 2012 17:48:56 +0000

Hi Sam,

Thanks for the comments. Answers are inserted below:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Friday, November 16, 2012 2:30 PM
To: Donald Eastlake
Cc: [email-masked]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

Authors,

cheers
-sam

1.  "This draft describes why and how Data Center TRILL networks can be
   optimized by utilizing a directory assisted approach.".
%sam - 'How' is part of the solution document isn't it?

[Linda] Yes. We will change the text accordingly.

2.  Sec 3 - "Unnecessary filling of slots in MAC table of edge RBridges RB1,

        stations attached to RB1."

[Linda] RB1 is just an example, how about changing the wording to

"Unnecessary filling of slots in MAC table of edge RBridges, e.g. RB1,

        stations attached to RB1."

3.  Sec 4 - "If the application location information can

   DA across the TRILL campus."

%sam - You may want to clarify here - Does flooding happen when the DA is not present in the Directory. If not, I see a problem. How do you account for the dropped frames. In traditional model, the frames are broadcasted and not dropped.

[Linda] The solution draft will specify the policy of dropping frames with unknown DA or flooding. This paragraph is mainly to say that there is less chance of receiving data frames with unknown DA with directory service. Will change the wording accordingly.

4.  Sec 4 - "It can trust the directory to tell it where

         the DA does not exist in the campus."

%sam- Little confused and same concern as above . Are you saying that the frame is dropped if the DA is not present in the directory. Shouldn't it flood just like in regular case?

[Linda] The policy to drop or flood when entry is not in the directory should be configured as stated earlier.

5.  Sec5 - "The {list of interested RBridges} would get populated when an

   systems."

%sam - Is the document describing the framework for how and when a specific model should be used to populated. Could both pull and push exist at the same time?

[Linda] Yes, both pull and push can co-exist. It is up to the configuration.

6.  Sec 5.3"Under this model, it is recommended that the ingress RBridge simply

   RBridge mapping table."

%sam - What is the rationale for this recommendation? How do you know the Directory server has upto date dB that it pushes down to RBridge? If the dB is not consistent, wouldn't the unknown unicast frames get dropped as per the above?

[Linda] How about changing  the wording to "it is operator's decision on if a frame with unknown DA should be dropped or flooded when the DA doesn't exist in the directory" ?

7.  "The detailed method and hand-shake mechanism between RBridge and Directory Server(s) is beyond the scope of this framework draft."

%sam - How does the Directory server know whether to push, full or partial info to an RBridge, if there is no handshake mechanism? FW should identify those requirements.

[Linda] The detailed description is in "draft-dunbar-trill-scheme-for-directory-assist-01". Do you have any suggestion on what should be described in the framework draft?

[Linda] OK

   located."

[Linda] OK. Will change wording accordingly.

[Linda] Is it OK to use "more detailed mechanisms"?

[Linda] We can add those requirement. Thanks.

Linda

On Oct 25, 2012, at 3:55 PM, Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Donald

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 19 Nov 2012 20:53:05 +0000

Thomas, 

Your comments are for "fine labeling" draft but not to "directory framework", is it? 

Linda

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomas Narten
> Sent: Monday, November 19, 2012 9:00 AM
> To: Erik Nordmark
> Cc: [email-masked]

---

From: Yizhou Li <[email-masked]>
Date: Tue, 20 Nov 2012 14:25:31 +0800

Some comments:
1. "Push request" and "Pull request" are explicitly used in section 5.2 &
5.3. I would like to suggest to add what are the mandatory parameters for
each request. Push request is for retrieving full set of mappings and pull
request is for retrieving a particular mapping. Therefore push request
should include the requesting RB and optionally VLAN list. Pull request
should include the requesting RB and queried IP or MAC.

2. Table 1 does not contain IP info. I think IP address is mandatory info in
directory server. Otherwise section 5.3 pull request triggered by ARP/ND
would be problematic. The draft uses MAC&VLAN<->Egress RBridge to describe
the mapping entry overall which ignores IP info. Suggest to add IP too.

3. Some of the contents in draft
draft-dunbar-trill-scheme-for-directory-assist and/or slides presented in
last meeting, I kind of think should be included in the framework, e.g.,
section 5 Push-Pull Hybrid Model in
draft-dunbar-trill-scheme-for-directory-assist and slide 3 on potential
types of directory servers. They are more framework focused, especially the
location correlation of directory server and RBridge. 

Thanks,

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Donald Eastlake
Sent: Friday, October 26, 2012 6:55 AM
To: [email-masked]
Subject: [trill] WG Last Call: draft-ietf-trill-directory-framework-01.txt

Thanks,
Donald

---

From: "Black, David" <[email-masked]>
Date: Sat, 24 Nov 2012 15:28:42 -0500

Hi Linda,

Here are some (somewhat tardy) comments on this WG Last Call.

(1) As noted by some of the others who commented, more functionality
details would be good to add, especially on mixing of the push and
pull models in Section 5.  Cache consistency needs to be covered,
at least its invalidation portion, as relying solely on aging out
entries can black-hole traffic that uses a stale entry that hasn't
aged out yet.

(2) I also agree with Erik's earlier comment about not understanding
why Appointed Forwarders are in this draft.  If use of a directory
can relax Appointed Forwarder restrictions without causing problems
(e.g., loops), that needs to be explained somewhere, probably in
Section 4.  Otherwise, Appointed Forwarders should not be discussed.

(3) On the comment about capitalizing MUST, SHOULD and MAY, the 
applicable RFC is RFC 2119, but those terms are not ordinarily used
in requirements documents.  An explanation that these keywords
express requirements on protocol development should be provided in
order to use the upper case versions of these keywords.

Here are some more detailed comments:

Abstract:
   Edge RBridges currently learn the mapping between MAC addresses and
   their egress RBridges by observing the data packets traversed
   through.

Change to: ... by observing traffic that traverses the RBridge.

Section 1, 1st paragraph:

                (This ''blocked'' state
   has no effect of TRILL Data or IS-IS frames, which can still be sent
   and received. It only affects native frames.)

"of TRILL data" -> "on TRILL Data" in second line above.

In item 2 in the list, I'd change "usually" to "often":
   2. Topology is usually based on racks and rows.

In item 3 in the list, explain that server reload can change the MAC
address and why that change may be needed or desirable, because
Section 4 appears to assert that the MAC address can change.  If
that wasn't intended, this text in Section 4 needs attention for
physical servers (it's ok for VMs):

   When a VM is moved to a new
   location or a server is loaded with a new application with different
   IP/MAC addresses, it is more likely that the DA of data packets sent
   out from those VMs are unknown to their attached edge RBridges.  

Item 4 should follow up on the mention of subnets in item 3 and
observe that multiple subnets on the same port at the same time is
common for server virtualization and the change rate is higher than
for physical servers.

In the definition of "Bridge", change "draft" to "document".

Section 3, p.6, first bullet - change both instances of "RB1" to
"an RBridge" as there's no RB1 in figure 1.

The last bullet in Section 3.1 is a bit sloppy about its use of the
word "entries".  It needs to explain exactly what is in an "entry" -
it might be possible to do this in an introduction by stating that
the presence of an entry (and list what it contains) avoids flooding
of inbound frames that match the entry.

Section 3.2, Scenario #1 - The use of the word "uplink" is confusing,
overly constraining and not necessary.  The important concept is how
many ToR switches are in each rack.  It's quite feasible for a server
or switch in a rack to have multiple uplinks to the same ToR (e.g.,
when the links are 1 Gigabit Ethernet).

Section 4, first sentence:
OLD
   In data center environment, applications placement to servers,
   racks, and rows is orchestrated by Server (or VM) Management
   System(s).
NEW
   In a data center environment, the assignment of applications
   to servers, including rack and row selection, is orchestrated
   by Server (or VM) Management System(s).
END

I'd suggest deleting Section 6 (Conclusion and Recommendations),
as it's important for considering what the WG will do, but may not
have much value in a published RFC.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik
> Nordmark
> Sent: Wednesday, November 14, 2012 4:13 PM
> To: [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 27 Nov 2012 16:11:11 +0000

David, 

Thank you very much for the detailed comments. I will incorporate them in the next revision. 

Some answers to your comments are inserted below:

> From: Black, David [mailto:[email-masked]]
> Sent: Saturday, November 24, 2012 2:29 PM
> To: [email-masked]; Linda Dunbar
> Subject: RE: [trill] WG Last Call: draft-ietf-trill-directory-
> framework-01.txt
> 
> Hi Linda,
> 
[Linda] This framework is mainly to cover the benefits of directory service. I will add some high level description, however I will try not to repeat the description in the mechanism draft which covers the details of caching and policy of pull/push. 

> Section 4.  Otherwise, Appointed Forwarders should not be discussed.
[Linda] Agree. Will change accordingly. 

> order to use the upper case versions of these keywords.
[Linda] Will change per you comments. Thanks.