Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Adam Roach]

Bob --

Thanks for taking the time to explain the history and rationale of Table 
3 to me. I'm going to clear my DISCUSS based on this explanation, since 
it seems that the technical solution in the document is correct, if a 
bit non-obvious. Some additional comments inline.


[For those of you who did not see Bob's response: it appears that my 
original DISCUSS email did not reach him,  so he replied to a reduced 
audience. I have restored the traditional IESG review distribution to 
this email. For this reason, I am eliding less of Bob's response than I 
usually would]


On 2/20/18 12:51 PM, Bob Briscoe wrote:




On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach
> wrote:

On 2/8/18 11:53 AM, Donald Eastlake wrote:

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach
> wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
>

--
> DISCUSS:
>

--
>
> Thanks to the authors, chairs, shepherd, and working
group for the effort that
> has been put into this document.
>
> I have concerns about some ambiguity and/or
self-contradiction in this
> specification, but I suspect these should be easy to
fix. In particular, the
> behavior defined in Table 3 doesn't seem to be
consistent with the behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>
+-+--+
>>       | Inner   |  Arriving TRILL 3-bit ECN
Codepoint Name |
>>       | Native
 +-+++--+
>>       | Header  | Not-ECT | ECT(0)     | ECT(1)    
| CE   |
>>
+-+-+++--+
>>       | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*)
|    |
>>       |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)  
 | CE   |
>>       |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)  
 | CE   |
>>       |  CE   |      CE |      CE    |  CE(*) |    
CE |
>>
+-+-+++--+
>>
>>            Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a
currently unused
>>  combination that SHOULD be logged. In contrast to
[RFC6040], in TRILL
>>  the drop condition is the result of a valid
combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header
value to the TRILL ECN
>     codepoint (resulting in any of the four values
above) or doesn't insert
>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag,
resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an egress
gateway can only be in one of
> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node
inserted ECN information.
>
>  B. TRILL header value == Native header value
because the ingress gateway
>     copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate
node indicated congestion.

Sort of... But note that the TRILL header ECN bit s
can indicate non-ECT while the CCE bit is set making
the overall TRILL Header "CE".


Right. That's part of case C. My states above assume
application of Table 2 has already taken place.



> If that's correct, I would think that any state
other than those three needs
> to be marked with an (*). In particular, these two
states fall into that
> classification, and seem to require an asterisk:


[BB] These states are not tagged (*) cos they can arise with variants 
of ECN marking behaviour referred to in Section 4 (explained beneath 
each bullet below). By design 

Re: [trill] AD review of draft-ietf-trill-over-ip-14

[Alia Atlas]

Hi Donald,

On Tue, Feb 20, 2018 at 8:30 PM, Donald Eastlake  wrote:

> Hi Alia,
>
> On Tue, Feb 20, 2018 at 6:55 PM, Alia Atlas  wrote:
>
>> As is traditional, I have done my AD review of
>> draft-ietf-trill-over-ip-14. First I would like to thank the authors -
>> Donald, Margaret, Mingui, and Dacheng, as well as the reviewers for their
>> work on this document.
>>
>> I did find one minor issue (below) and would recommend a spell-checker to
>> catch several minor typos.  I will send this to IETF Last Call and place it
>> on the IESG telechat on March 8.
>>
>> Minor:
>>
>> 1) In Sec 5.2: " An adjacency can be formed between two TRILL over IP
>> transport ports if the intersection of the sets of encapsulation methods
>> they support is not null. If that intersection is null, then no adjacency
>> is formed."
>> Given that Sec 5.0 says that the native encapsulation MUST be supported,
>> how can the set be null?  Is this the set of encapsulation methods other
>> than the native encapsulation?  Please clarify.
>>
>
> Unless the port is configured to use some other encapsulation X for all
> types of traffic, then a port has to "support" UDP for the low bandwidth of
> Hellos and other adjacency establishment PDUs. This is different from
> advertising support for UDP which means a willingness to use it for data
> traffic and LSPs. This needs to be clarified. Maybe "limited support"
> versus "full support".
>

Thanks, that would work.  The draft currently doesn't indicate limited
support and the previous paragraph indicates that signaling nothing assumes
"native encapsulation".

Regards,
Alia

Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
> 
>  d3e...@gmail.com
>
>
>> Regards,
>> Alia
>>
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] early AD review of draft-ietf-trill-vendor-channel-00

[Alia Atlas]

Since there appears to be renewed interest in this draft, I have done an
early AD review of it and not found any issues.

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

[trill] Fwd: IPR Declaration for draft-ietf-trill-multilevel-unique-nickname

[Donald Eastlake]

Forwarding to the WG list for the record.

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

-- Forwarded message --
From: li...@gsta.com 
Date: Tue, Feb 20, 2018 at 10:14 PM
Subject: Re: Dongxin: You need to post an IPR Declaration for
draft-ietf-trill-multilevel-unique-nickname
To: d3e3e3 
Cc: trill-chairs , zhangmingui <
zhangmin...@huawei.com>


Hi,
   I don't know any IPR that has not been declared for this draft.

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

Re: [trill] AD review of draft-ietf-trill-over-ip-14

[Donald Eastlake]

Hi Alia,

On Tue, Feb 20, 2018 at 6:55 PM, Alia Atlas  wrote:

> As is traditional, I have done my AD review of
> draft-ietf-trill-over-ip-14. First I would like to thank the authors -
> Donald, Margaret, Mingui, and Dacheng, as well as the reviewers for their
> work on this document.
>
> I did find one minor issue (below) and would recommend a spell-checker to
> catch several minor typos.  I will send this to IETF Last Call and place it
> on the IESG telechat on March 8.
>
> Minor:
>
> 1) In Sec 5.2: " An adjacency can be formed between two TRILL over IP
> transport ports if the intersection of the sets of encapsulation methods
> they support is not null. If that intersection is null, then no adjacency
> is formed."
> Given that Sec 5.0 says that the native encapsulation MUST be supported,
> how can the set be null?  Is this the set of encapsulation methods other
> than the native encapsulation?  Please clarify.
>

Unless the port is configured to use some other encapsulation X for all
types of traffic, then a port has to "support" UDP for the low bandwidth of
Hellos and other adjacency establishment PDUs. This is different from
advertising support for UDP which means a willingness to use it for data
traffic and LSPs. This needs to be clarified. Maybe "limited support"
versus "full support".

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


> Regards,
> Alia
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Adam Roach's No Objection on draft-ietf-trill-ecn-support-05: (with COMMENT)

[Adam Roach]

Adam Roach has entered the following ballot position for
draft-ietf-trill-ecn-support-05: 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-ecn-support/



--
COMMENT:
--

I'm balloting "no objection" based on explanations from the author about
all three points raised in my original discuss. I have requested that the
authors include a summary of these explanations in the document to
aid implementors in understanding why Table 3 is defined the way it is,
so they don't erroneously conclude that the table is incorrect.

My original discuss text and original comments appear below for posterity.

---

Thanks to the authors, chairs, shepherd, and working group for the effort that
has been put into this document.

I have concerns about some ambiguity and/or self-contradiction in this
specification, but I suspect these should be easy to fix. In particular, the
behavior defined in Table 3 doesn't seem to be consistent with the behavior
described in the prose.

For easy reference, I've copied Table 3 here:

>   +-+--+
>   | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name |
>   | Native  +-+++--+
>   | Header  | Not-ECT | ECT(0) | ECT(1) | CE   |
>   +-+-+++--+
>   | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) ||
>   |  ECT(0) |  ECT(0) |  ECT(0)|  ECT(1)| CE   |
>   |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)| CE   |
>   |CE   |  CE |  CE|  CE(*) | CE   |
>   +-+-+++--+
>
>  Table 3. Egress ECN Behavior
>
>  An asterisk in the above table indicates a currently unused
>  combination that SHOULD be logged. In contrast to [RFC6040], in TRILL
>  the drop condition is the result of a valid combination of events and
>  need not be logged.

The prose in this document indicates:

 1. Ingress gateway either copies the native header value to the TRILL ECN
codepoint (resulting in any of the four values above) or doesn't insert
any ECN information in the TRILL header.

 2. Intermediate gateways can set the CCE flag, resulting in "CE" in the
table above.

Based on the above, a packet arriving at an egress gateway can only be in one of
the following states:

 A. TRILL header is Not-ECT because no TRILL node inserted ECN information.

 B. TRILL header value == Native header value because the ingress gateway
copied it from native to TRILL.

 C. TRILL header is "CE" because an intermediate node indicated congestion.

If that's correct, I would think that any state other than those three needs
to be marked with an (*). In particular, these two states fall into that
classification, and seem to require an asterisk:

  - Native==CE && TRILL==ECT(0)

  - Native==ECT(0) && TRILL==ECT(1)

In addition, the behavior this table defines for Native==ECT(0) && TRILL==ECT(1)
is somewhat perplexing: for this case, the value in the TRILL header takes
precedence; however, when Native==ECT(1) && TRILL==ECT(0) the Native header
takes precedence. Or, put another way, this table defines ECT(1) to always
override ECT(0). I don't find any prose in here to indicate why this needs to be
treated differentially, so I'm left to conclude that this is a typographical
error. If that's not the case, please add motivating text to Table 3 explaining
why ECT(1) is treated differently than ECT(0) for baseline ECN behavior.

---

I also have a small handful of editorial suggestions and nits to propose.

Please expand "TRILL" upon first use and in the title; see
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

---
§1:

>  In [RFC3168] it was recognized that tunnels and lower layer protocols

"In [RFC3168], it was..."
(insert comma)

---

§2:

>  These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN

"...are shown..."


>  The CRItE bit is the critical Ingress-to-Egress summary
>  bit and will be one if and only if any of the bits in the CItE range
>  (21-26) is one or there is a critical feature 

[trill] Last Call: (TRILL: Vendor Specific TRILL Channel Protocol) to Proposed Standard

[The IESG]

The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'TRILL: Vendor
Specific TRILL Channel Protocol'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol is implemented by devices called TRILL switches or RBridges
   (Routing Bridges). TRILL includes a general mechanism, called RBridge
   Channel, for the transmission of typed messages between RBridges in
   the same campus and between RBridges and end stations on the same
   link. This document specifies a method to send vendor specific
   messages over the RBridge Channel facility.






The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-vendor-channel/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[trill] WG LC on draft-ietf-trill-vendor-channel-00.txt - is complete and WG has consensus

[Susan Hares]

The WG LC call is completed for draft-ietf-trill-vendor-channel-00.txt.  The
trill WG has reached consensus to send this to the IESG for publication.   

 

Thank you for all your reviews and comments. 

 

Susan Hares

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

[trill] AD review of draft-ietf-trill-over-ip-14

[Alia Atlas]

As is traditional, I have done my AD review of draft-ietf-trill-over-ip-14.
First I would like to thank the authors - Donald, Margaret, Mingui, and
Dacheng, as well as the reviewers for their work on this document.

I did find one minor issue (below) and would recommend a spell-checker to
catch several minor typos.  I will send this to IETF Last Call and place it
on the IESG telechat on March 8.

Minor:

1) In Sec 5.2: " An adjacency can be formed between two TRILL over IP
transport ports if the intersection of the sets of encapsulation methods
they support is not null. If that intersection is null, then no adjacency
is formed."
Given that Sec 5.0 says that the native encapsulation MUST be supported,
how can the set be null?  Is this the set of encapsulation methods other
than the native encapsulation?  Please clarify.

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

[trill] Last Call: (TRILL (Transparent Interconnection of Lots of Links) Over IP Transport) to Proposed Standard

[The IESG]

The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'TRILL (Transparent
Interconnection of Lots of Links) Over IP Transport'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   The TRILL (Transparent Interconnection of Lots of Links) protocol
   supports both point-to-point and multi-access links and is designed
   so that a variety of link protocols can be used between TRILL switch
   ports. This document specifies transmission of encapsulated TRILL
   data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP
   network as a TRILL link in a unified TRILL campus. This document
   updates RFC 7177 and updates RFC 7178.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for 
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - 
Independent Submission Editor stream)
draft-ietf-tsvwg-le-phb: A Lower Effort Per-Hop Behavior (LE PHB) (None - 
IETF stream)



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

[trill] draft-ietf-trill-multilevel-unique-nickname-03.txt - WG has reached consensus

[Susan Hares]

The TRILL WG has reached consensus on
draft-ietf-trill-multilevel-unique-nickname-03.txt, and this draft will be
forwarded to the 
IESG for publication. 

 

 

Susan Hares 

 

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

[trill] Publication has been requested for draft-ietf-trill-over-ip-14

[Susan Hares]

Susan Hares has requested publication of draft-ietf-trill-over-ip-14 as 
Proposed Standard on behalf of the TRILL working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/

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

[trill] Publication has been requested for draft-ietf-trill-multilevel-unique-nickname-04

[Susan Hares]

Susan Hares has requested publication of 
draft-ietf-trill-multilevel-unique-nickname-04 as Proposed Standard on behalf 
of the TRILL working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/

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

[trill] I-D Action: draft-ietf-trill-multilevel-unique-nickname-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links 
WG of the IETF.

Title   : TRILL Multilevel Using Unique Nicknames
Authors : Mingui Zhang
  Donald E. Eastlake 3rd
  Radia Perlman
Filename: draft-ietf-trill-multilevel-unique-nickname-04.txt
Pages   : 15
Date: 2018-02-20

Abstract:
   TRILL routing can be extended to support multiple levels by building
   on the multilevel feature of IS-IS routing. Depending on how
   nicknames are managed, there are two primary alternatives to realize
   TRILL multilevel: the unique nickname approach and the aggregated
   nickname approach as discussed in RFC 8243. This document specifies a
   unique nickname approach. This approach gives unique nicknames to all
   TRILL switches across the multilevel TRILL campus.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-multilevel-unique-nickname-04
https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-unique-nickname-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-multilevel-unique-nickname-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [trill] draft-ietf-trill-parent-selection-02 - WG LC (2/2 to 2/16)

[Linda Dunbar]

Support the WGLC. I think this draft is useful and ready.

Linda Dunbar


On Fri, Feb 2, 2018 at 12:00 Susan Hares 
> wrote:
This begins a 2 week WG LC on  draft-ietf-trill-parent-selection-02.txt (2/2 to 
2/16)  which you can find at:
https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/

In your comments, please consider:

1)   will the documentation of this problem and its solution benefit 
operation of TRILL networks?

2)   Is this document ready for publication?

As a chair who is concerned about the operational aspects of TRILL, I encourage 
you to read and review this TRILL document.

Sue Hares
--
Sent from Gmail Mobile
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] draft-ietf-trill-parent-selection-02 - WG LC (2/2 to 2/16)

[Donald Eastlake]

I support this draft. I think documentation of the considerations covered
by this draft will be useful for TRILL.

Thanks,
Donald

On Fri, Feb 2, 2018 at 12:00 Susan Hares  wrote:

> This begins a 2 week WG LC on  draft-ietf-trill-parent-selection-02.txt
> (2/2 to 2/16)  which you can find at:
>
> https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/
>
>
>
> In your comments, please consider:
>
> 1)   will the documentation of this problem and its solution benefit
> operation of TRILL networks?
>
> 2)   Is this document ready for publication?
>
>
>
> As a chair who is concerned about the operational aspects of TRILL, I
> encourage you to read and review this TRILL document.
>
>
>
> Sue Hares
>
-- 
Sent from Gmail Mobile
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] draft-ietf-trill-parent-selection-02 - WG LC (2/2 to 2/16)

[Susan Hares]

Trill Wg:

 

 

I support this informational draft.  It provides a discussion of a known 
operational problem and a solution. 

I think it is important to have the IETF publish because it will help TRILL 
deployments. 

 

Sue Hares  

 

From: Donald Eastlake [mailto:d3e...@gmail.com] 
Sent: Tuesday, February 20, 2018 11:18 AM
To: Susan Hares
Cc: trill@ietf.org; trill-cha...@ietf.org
Subject: Re: draft-ietf-trill-parent-selection-02 - WG LC (2/2 to 2/16)

 

I support this draft. I think documentation of the considerations covered by 
this draft will be useful for TRILL.

 

Thanks,

Donald

 

On Fri, Feb 2, 2018 at 12:00 Susan Hares  wrote:

This begins a 2 week WG LC on  draft-ietf-trill-parent-selection-02.txt (2/2 to 
2/16)  which you can find at:

https://datatracker.ietf.org/doc/draft-ietf-trill-parent-selection/

 

In your comments, please consider:

1)   will the documentation of this problem and its solution benefit 
operation of TRILL networks? 

2)   Is this document ready for publication? 

 

As a chair who is concerned about the operational aspects of TRILL, I encourage 
you to read and review this TRILL document. 

 

Sue Hares 

-- 

Sent from Gmail Mobile

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

[trill] Last Call: (TRILL Multilevel Using Unique Nicknames) to Proposed Standard

[The IESG]

The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'TRILL Multilevel
Using Unique Nicknames'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   TRILL routing can be extended to support multiple levels by building
   on the multilevel feature of IS-IS routing. Depending on how
   nicknames are managed, there are two primary alternatives to realize
   TRILL multilevel: the unique nickname approach and the aggregated
   nickname approach as discussed in RFC 8243. This document specifies a
   unique nickname approach. This approach gives unique nicknames to all
   TRILL switches across the multilevel TRILL campus.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/ballot/


No IPR declarations have been submitted directly on this I-D.




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

[trill] Last Call: (Directory Assisted TRILL Encapsulation) to Proposed Standard

[The IESG]

The IESG has received a request from the Transparent Interconnection of Lots
of Links WG (trill) to consider the following document: - 'Directory Assisted
TRILL Encapsulation'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This draft describes how data center networks can benefit from non-
   RBridge nodes performing TRILL encapsulation with assistance from a
   directory service.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3045/





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

[trill] AD review of draft-ietf-trill-multilevel-unique-nickname-03

[Alia Atlas]

As is traditional, I have done my AD review
of draft-ietf-trill-multilevel-unique-nickname-03.  First, I would like to
thank the authors - Margaret, Donald, Mingui, and Dacheng - as well as the
reviewers and shepherd, Sue, for their work on this document.

I do have some minor comments, but these can be addressed ASAP while the
draft is in IETF Last Call.  I will request that to start and place this on
the IESG telechat on March 8.


Minor:

a) In Sec 3.1, it says "
  1) RB27 and RB3 have learned that D is connected to nickname 44.
  2) RB27 has learned that nickname 44 is accessible through RB3."

Given that RB2 is the local area's Level Border Router, I think that is
RB2 not RB3. Granted, RB3 needs to know also - but that is info from its
local area.

b) In Sec 4.3:
" For nicknames in these ranges, other RBridges will deem that they are
owned by the originating border RBridge. The paths to nicknames that fall
in these ranges will be calculated to reach the originating border RBridge.
TRILL Data packets with egress nicknames that are neither in these ranges
nor announced by any RBridge in the area MUST be discarded. "

I think this only applies if OK = 0 - and that needs to be restated as part
of the condition.

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

Re: [trill] WG LC on draft-ietf-trill-vendor-channel-00.txt (1/19 to 2/2/2018)

[Linda Dunbar]

Support the WG LC for draft-ietf-trill-vendor-channel.
I think vendor channel provides flexibility for the vendors’ managements.

I think the draft is ready for publication.

Linda

-- Forwarded message -
From: Susan Hares >
Date: Fri, Jan 19, 2018 at 11:45
Subject: WG LC on draft-ietf-trill-vendor-channel-00.txt (1/19 to 2/2/2018)
To: >
CC: 
>

This begins a 2 week WG last call on draft-ietf-trill-vendor-channel-00 from 
1/19/2018 to 2/2/2018.

During your WG last call comments, please consider:


1)  Does this vendor channel provide flexibility for the vendors management 
of TRILL switches?

2)  Will this option help vendors to continue to extend their TRILL 
campuses?

3)  Is specification ready for publication?

Cheerily, Susan Hares


--
Sent from Gmail Mobile
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] WG LC on draft-ietf-trill-vendor-channel-00.txt (1/19 to 2/2/2018)

[Radia Perlman]

This seems useful and I could find no problems with it.  I think it's ready
for publication.

It enables the flexibility of passing vendor-specific information between
like nodes without impacting non-like nodes.

Radia

On Fri, Jan 19, 2018 at 8:45 AM, Susan Hares  wrote:

> This begins a 2 week WG last call on draft-ietf-trill-vendor-channel-00
> from 1/19/2018 to 2/2/2018.
>
>
>
> During your WG last call comments, please consider:
>
>
>
> 1)  Does this vendor channel provide flexibility for the vendors
> management of TRILL switches?
>
> 2)  Will this option help vendors to continue to extend their TRILL
> campuses?
>
> 3)  Is specification ready for publication?
>
>
>
> Cheerily, Susan Hares
>
>
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill