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 <d3e...@gmail.com> wrote:

> Hi Alia,
>
> On Tue, Feb 20, 2018 at 6:55 PM, Alia Atlas <akat...@gmail.com> 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
> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA=gmail=g>
>  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] 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] 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

[trill] AD review of draft-ietf-trill-transport-over-mpls-07

[Alia Atlas]

As usual, I have done my AD review of
draft-ietf-trill-transport-over-mpls-07. I would like to thank the authors
- Mohammed, Kingston, Donald, and Lucy - as well as the reviewers for their
work on this document.

I do have a couple minor comments to fix.  I will request IETF Last Call in
parallel with these being rapidly fixed - and place it on the March 8
telechat.

1) The title is misleading - this is not trill encapsulated in MPLS - but
in Ethernet psuedo-wires for transport over an MPLS backbone.  It should be
fixed.  Perhaps: "TRILL Transparent Transport via VPLS Constructs across an
MPLS Network" ?

2)  Please clarify how traffic from a TRILL tenant is mapped by the PE/VTSD.

Thanks,
Alila
___
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)

[Alia Atlas]

Thank you!

Regards,
Alia

On Fri, Feb 16, 2018 at 12:24 AM, R Parameswaran <parameswaran...@gmail.com>
wrote:

>
> Hi Alia, Donald,
>
> Ack, thanks for the heads up - I'll try and spin it back out later
> tonight.
>
> regards,
>
> Ramkumar
>
>
> On Thu, Feb 15, 2018 at 4:07 PM, Alia Atlas <akat...@gmail.com> wrote:
>
>> There is no time left to accommodate delays in uploading the updated
>> draft.  I need to review this and EVERYTHING ELSE from trill that will be
>> published from the WG by Tuesday so it can make the last telechat on March
>> 8 before IETF 101.
>>
>> The trill working group is closing.
>>
>> On Feb 15, 2018 2:35 PM, "R Parameswaran" <parameswaran...@gmail.com>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> I support this as author, please see inline @[RP]:
>>>
>>> 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?
>>>
>>>
>>> [RP] Yes, the problem (discussed in the draft) has been seen in customer 
>>> deployments, and I believe the technique listed in the draft will help 
>>> alleviate the issue.
>>>
>>> 2)   Is this document ready for publication?
>>>
>>>
>>> [RP]: It's nearly ready. Donald (Eastlake) was kind enough to offer some 
>>> suggestions and a template draft (based on the latest public draft) with 
>>> page numbering laid out. I'll upload this within a day or so - these are 
>>> purely textual changes, there are no functional edits in this upload.  
>>> Wondering if you could extend the last call by a few days to accommodate 
>>> this..
>>>
>>> thanks,
>>>
>>> Ramkumar
>>>
>>>
>>>
>>> As a chair who is concerned about the operational aspects of TRILL, I
>>> encourage you to read and review this TRILL document.
>>>
>>>
>>>
>>> Sue 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

[trill] AD review of draft-ietf-trill-directory-assisted-encap-09

[Alia Atlas]

As is traditional, I have done my AD review
of draft-ietf-trill-directory-assisted-encap-09.
I would like to thank the authors - Linda, Donald, and Radia - for their
work on this document.

I have placed this on the IESG telechat on March 8 and will send it to IETF
Last Call as soon
as it is moved to the IESG for publication.

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

[trill] AD review of draft-ietf-trill-multi-topology-05

[Alia Atlas]

As is customary, I have done my AD review of
draft-ietf-trill-multi-topology-5.
I would like to thank the authors - Donald, Mingui, and Ayan - for a clear
and
well-written document.

I have no comments and will put it in IETF Last Call - though I am still
waiting for
the shepherd's write-up.

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

[trill] trill WG closing at IETF 101

[Alia Atlas]

I would like to remind the TRILL working group that I will be closing it at
IETF 101.
We discussed this at IETF 99 and IETF 100.

I have told the WG that important work would need to move fast.  If you are
the author of
a WG draft, then it will require excellent response times to get your WG
draft done.
There are currently 8 drafts in WGLC.

Any that are not in IETF Last Call - including my AD review by next Tues
are highly unlikely to make the March 8 telechat, which is my final
telechat.

I can only read so fast - and if the draft wasn't top of stack for over six
months, then I have to question its criticality to be published.

You will start seeing AD reviews from me on drafts; please respond and deal
ASAP.

Regards,
Alia
___
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)

[Alia Atlas]

There is no time left to accommodate delays in uploading the updated
draft.  I need to review this and EVERYTHING ELSE from trill that will be
published from the WG by Tuesday so it can make the last telechat on March
8 before IETF 101.

The trill working group is closing.

On Feb 15, 2018 2:35 PM, "R Parameswaran"  wrote:

>
> Hi,
>
> I support this as author, please see inline @[RP]:
>
> 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?
>
>
> [RP] Yes, the problem (discussed in the draft) has been seen in customer 
> deployments, and I believe the technique listed in the draft will help 
> alleviate the issue.
>
> 2)   Is this document ready for publication?
>
>
> [RP]: It's nearly ready. Donald (Eastlake) was kind enough to offer some 
> suggestions and a template draft (based on the latest public draft) with page 
> numbering laid out. I'll upload this within a day or so - these are purely 
> textual changes, there are no functional edits in this upload.  Wondering if 
> you could extend the last call by a few days to accommodate this..
>
> thanks,
>
> Ramkumar
>
>
>
> As a chair who is concerned about the operational aspects of TRILL, I
> encourage you to read and review this TRILL document.
>
>
>
> Sue 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

Re: [trill] AD review of draft-ietf-trill-address-flush-04

[Alia Atlas]

Thanks for the quick response!

On Jan 22, 2018 7:57 PM, "Donald Eastlake" <d3e...@gmail.com> wrote:

> Hi Alia,
>
> A -05 version has been posted fixing this and one other typo.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>
> On Mon, Jan 22, 2018 at 5:41 PM, Alia Atlas <akat...@gmail.com> wrote:
> > As is customary, I have done my AD review of
> > draft-ietf-trill-address-flush-04.  First, I would like to thank the
> authors
> > - Weiguo, Donald, Yizhou, and Mohammed - as well as the reviewers for a
> > clear and well-written document.
> >
> > I have one minor concern to be fixed before IETF Last Call ends.  I have
> > started IETF Last Call and placed the document on the February 8 IESG
> > telechat.
> >
> > Minor:
> >
> > 1) Sec 2.2:  Please specify that the length is specified in octets.
> >
> > Regards,
> > Alia
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] AD review of draft-ietf-trill-ecn-support-04

[Alia Atlas]

As is traditional,I have done my AD review of
draft-ietf-trill-ecn-support-04.  First, I would
like to thank Donald and Bob and the reviewers of this draft for their work
on an excellent
document.

I do not have any comments or concerns at this time.  I have requested an
IETF Last Call
and placed this draft on the February 8 IESG telechat.

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

Re: [trill] AD review of draft-ietf-trill-resilient-trees-08

[Alia Atlas]

Hi Mingui,


I have reviewed the updated draft and still have serious concerns.

1) In Sec 5.3: "Due to the  multi-destination RPF check in TRILL,
local protection can
   only be used at a fork point where the primary and backup trees
   diverge and the set of nodes downstream is identical for both paths.
   If these conditions do not apply, local protection MUST NOT be
used." was added.

But even the example in Figure 4.1 doesn't yield such a set of nodes
downstream that is identical for both paths from any node!


2) Sec 3.2.1: " But it is desirable that every RBridge independently
computes Affinity Links for a backup DT across the whole campus."

   That may be - but there is NO ALGORITHM that describes how an
RBridge would independently compute the Affinity Links.

   There isn't even a description of why an RBridge would declare an
affinity link!  Are you trying to make sure that certain links are
included

   in the backup tree???  Also in Sec 3.2.1, I see

"This document RECOMMENDS achieving the independent *backup tree*

*   determination* method through a
   slight change to the conventional DT
   calculation process of TRILL.
   Basically, after *After* the primary DT is calculated, the
   *every* RBridge will be aware of which links are used in that primary
   tree. When the backup DT is calculated, each RBridge increases the
   metric of these links by
   a proper value (for safety, it's recommended to use the summation
of all original link metrics
   in the campus but not more than 2**23), *2**23,* which gives these links a
   lower priority of being chosen for the backup DT by the Shortest Path
   First calculation. All links on this backup DT can be assigned as
   Affinity Links but this is unnecessary. *may not be necessary.* In
order to reduce the
   amount of Affinity Sub-TLVs flooded across the campus, only those NOT
   picked by the conventional DT calculation process SHOULD be announced
   as Affinity Links."

but it isn't clear

   (i) Does each RBridge compute the backup DT upon receiving the
Backup Tree APPsub-TLV that connects a backup DT

   to the primary DT by specifying the root?

   (ii) If each RBridge is already computing the backup DT by
adjusting the metric of all links in the primary DT,

how could an RBridge determine to announce an Affinity Link
that "is not picked by the conventional DT

calculation process".

   (iii) How would the backup tree be certain to have the same set of
downstream nodes to support the multi-destination

RPF check?

3)  Sec 3.2.1 claims that MRT requires the same root for the trees.
Of course, it is fairly straightforward to have a proxy node connected
in an

inbound direction to all other nodes except an outbound direction to
the primary node, and then compute so that the two MRTs are in reality
rooted

at different nodes.  The point is NOT that you should use MRT (though
it would guarantee maximally disjointness) - but rather that you have
a

barely described algorithm that is going to fail to provide
disjointness in many topologies, and that has no way of guaranteeing
the conditions

that are claimed to be needed for the multi-destination RPF check.


I see no indication that there are implementations of this or modeling
of how well the algorithm will work.

The draft is seriously underspecified and I remain concerned that what
is proposed is at best unusable.


Given the planned time-frame to close TRILL by IETF 101, unless there
are implementations or serious modeling work for

algorithms behind this draft, I do not see a way forward in the TRILL WG.


I see that this draft was adopted by the WG in 2013.  I do not see any
discussion on the list of the draft since then -

until there were requested directorate views.  I do not see how this
draft is covered by the charter - though if there

were serious support behind this draft now and actual implementations
and modeling to show the coverage, I could be

persuaded that it is still relevant and there is enthusiasm to do the
needed work.


If so - then the draft can be taken to rtgwg for discussion as an
individual draft.


Regards,

Alia





On Mon, Jan 22, 2018 at 4:33 AM, Zhangmingui (Martin) <
zhangmin...@huawei.com> wrote:

> Hi Donald,
>
>
>
> Thanks a lot for your comments.
>
>
>
> An updated version has just been uploaded to address these comments.
>
>
>
> Mingui
>
>
>
> *From:* Donald Eastlake [mailto:d3e...@gmail.com]
> *Sent:* Wednesday, January 17, 2018 1:49 AM
> *To:* trill@ietf.org
> *Cc:* draft-ietf-trill-resilient-tr...@ietf.org; Alia Atlas
> *Subject:* Re: [trill] AD review of draft-ietf-trill-resilient-trees-08
>
>
>
> Hi,
>
>
>
> I've reviewed this draft in light of Alia's comments and have comments as
> follows:
>
>- It should be clearer that each primary distribution tree may have at
>most 

[trill] AD review and progressing of draft-ietf-trill-arp-optimization-08

[Alia Atlas]

First, I'd like to thank the authors for handling the technical concerns
seen by the IESG during the last review process.

As is customary, I have done my AD review of this draft.  I do not have any
issues that need to be addressed.  I have requested IETF Last Call and
scheduled this for the July 7 telechat, though it might get moved to after
IETF 99 depending upon the document load for that telechat.

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

[trill] AD review of draft-ietf-trill-centralized-replication-08

[Alia Atlas]

As is customary, I have done my AD review
of draft-ietf-trill-centralized-replication-08. First, I would like to
thank the authors - Weiguo Hao, Yizhou Li, Muhammad Durrani, Sujay Gupta,
and Andrew Qu - for their work on this document.

I do have a few concerns that need to be addressed before the document can
proceed to IETF Last Call.  If the authors can address them very rapidly
(this week), then I have time for an IETF Last Call and putting the draft
on the IESG Telechat of July 6.


1) In Sec 3, it says"In this case, the RPF calculation on each RBridge
should use the centralized node as the ingress RBridge instead of the real
ingress virtual RBridge to perform the calculation."
In Sec 7, it says"The egress nickname in the multi-destination TRILL Header
is the nick5 and the ingress nickname is still P-nick."

>From scanning RFC6325, I am reminded that the egress nickname indicates the
destination tree.   I don't see clearly specified here how the RBridge
determines which RPF calculation to use for a particular frame

In Sec 11,"A C-nickname is a specialized pseudo-nickname for which transit
RBridges perform a different RPF check algorithm for TRILL data packets
with the C-nickname in the ingress nickname field."

If I follow the logic here, an RBridge is intended to install a different
RPF interface-set for each C-nickname - but what that RPF interface-set is
will also be dependent upon the egress nickname specified?? Does this
turn the look-up from a simple ingress nickname (16 bit) to interface-set
into a something more complicated?
I guess it could be a recursive lookup, where if the ingress nickname is a
C-nickname, then the RPF interface-set is looked up again from the egress
name instead?

If I am correct, then this is a definite change in fast-path forwarding
behavior and should be described extremely clearly - which it is not.

I don't think that Sec 8 helps in guessing which distribution tree will be
used.

2) In Sec 10:"In this case, an edge group using CMT [RFC7783] MUST NOT set
the C-
   nickname flag on the pseudo-nickname it is using."
Given that an implementation support RFC7783 may not support this document,
please
clarify in the document how it is that an implementation conformant to
RFC7783 is guaranteed to not set the C-nickname flag.

3) Sec 11:" When active-active edge RBridges use centralized replication to
   nickname and the C-nickname is used as ingress nickname in the TRILL
   header for the unicast TRILL encapsulation of BUM traffic."

I have no idea what this sentence fragment means.

4) Sec 12: There is a claim of no new security concerns, but this basically
gives a device the ability to advertise an R-nickname and get all/some of
the BUM traffic unicast to it - where that device could modify, block, or
respond to the BUM traffic and the rest of the campus - except for the
local neighbors of ingress RBridge would have no idea this was happening!
I think that some discussion of exactly what security mechanisms for IS-IS
ensure that a device injecting an R-nickname is trusted would be helpful as
well as articulating the potential impact.

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

[trill] progressing draft-ietf-trill-mtu-negotiation

[Alia Atlas]

First, I would like to thank the authors - Mingui, Zudong, Donald, Radia,
and Somnath - for their work on this document.

As is customary, I have done my AD review. For this draft, I have found no
issues. I have requested IETF Last Call and scheduled the document for the
IESG telechat on July 6.

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

[trill] AD review of draft-ietf-trill-rbridge-multilevel-04

[Alia Atlas]

As is customary, I have done my AD review
of draft-ietf-trill-rbridge-multilevel-04.  First, I would
like to thank the authors - Radia, Donald, Mingui, Anoop, and Hongjun - for
their work on this document.

>From my review, I do have a few high level concerns.  In particular, this
document has the job of guiding future WG work and setting out some
high-level decisions for the architecture of multi-level TRILL.
Unfortunately, there are several areas where the draft isn't willing to
commit to specific guidance or pick one alternative.   If there had been
vigorous discussion and debate on this, I might have more confidence that
there are strong reasons that truly justify the multiplication of
complexity represented in this document.   I don't see any of that on the
list.

I will require an updated draft and discussion before progressing this
document.


Major:

a) Sec 2.2.2.2:  Unless I'm missing something - this is proposing changing
the format of the basic TRILL header to accommodate multi-level IS-IS,
which would impact all hardware implementations of TRILL deployed
everywhere.   The idea of allowing both options just makes for yet more
complexity, options, and challenges in interoperability & troubleshooting!
  Please don't invent complexity.  I don't see any discussion on the
mailing list around this point and the document doesn't emphasize that this
is an extremely bad option - done to trade-off  complexity & storage at the
border switches.   This is definitely an area where operators and vendors
need to weigh in and silence can not imply consensus.

b) Sec 7:  I would strongly prefer to see a clear trade-off described in
terms of hardware impact as well as how flag-days for software could be
avoided.   I'm not seeing any considerations given to upgrading.  I also am
not excited that the WG isn't willing to pick one approach to go forward
with.  Multiple approaches mean at least twice the pain for implementing,
testing, troubleshooting, learning the technology, and so on.

c) I expect some section of management/operational considerations for how
different choices impact the ability to transition from a single area to a
multi-area solution.

Minor:

1) Sec 1.1 item 5: Is the concern about the 16-bit nickname limit for trill
switches based on the likelihood of collision from picking nicknames?   I
have a hard time picturing a network with over 65,500 trill switches and
distribution trees that doesn't run into many other issues.   Please clarify
the details of this concern in the document.

2) Sec 6:  The simple option of having topology constraints to avoid having
multiple trill switches in different areas connected to the same link
doesn't seem to have been considered.  Please add and clarify why a
topology constraint is or isn't acceptable operationally.  As you well
know, simplification and ease of interoperability are critical criteria for
evaluating the options.

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

[trill] AD review and progressing of draft-ietf-trill-rfc6439bis-03

[Alia Atlas]

As is customary, I have done my AD review of draft-ietf-trill-rfc6439bis-03.

First, I would like to thank the authors - Donald, Yizhou, Mohammed, Ayan
and Fengwei - for their work on thsi well-written document.

I do not have any specific comments on the draft from my review.   I have
requested IETF Last Call and placed the draft on the January 19 telechat.

I am slightly concerned by the complexity and number of different options
that TRILL has in most aspects - but given that there is WG consensus and
plans to implement, I am merely expressing my concerns.

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

[trill] AD review & progressing draft-ietf-trill-directory-assist-mechanisms-10

[Alia Atlas]

As is customary, I have done my AD review
of draft-ietf-trill-directory-assist-mechanisms-10.
First, I would like to thank the authors - Donald, Linda, Radia, and Yizhou
- for their work on this well-written complex document.

I have done my AD review and found no issues (though 3 typos that I recall
;-).
I have requested IETF Last Call and expect this to be on the IESG Telechat
on January 19.

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

Re: [trill] RtgDir review: TRILL: Interface Addresses APPsub-TLV

[Alia Atlas]

Danny,

Thank you very much for your review.

Regards,
Alia

On Thu, May 5, 2016 at 2:41 PM, McPherson, Danny 
wrote:

>
> I’m comfortable with your stated intentions here Donald.
>
> Thanks for the prompt response,
>
>
> -danny
>
>
>
>
> On 5/5/16, 12:02 PM, "Donald Eastlake"  wrote:
>
> >Hi Danny,
> >
> >Thanks for your comments. See below.
> >
> >On Wed, May 4, 2016 at 10:27 AM, McPherson, Danny
> > wrote:
> >>
> >> Hello,
> >>
> >> I have been selected as the Routing Directorate reviewer for this
> >> draft. The Routing Directorate seeks to review all routing or
> >> routing-related drafts as they pass through IETF last call and IESG
> >> review, and sometimes on special request. The purpose of the review
> >> is to provide assistance to the Routing ADs. For more information
> >> about the Routing Directorate, please see
> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >>
> >> Although these comments are primarily for the use of the Routing
> >> ADs, it would be helpful if you could consider them along with any
> >> other IETF Last Call comments that you receive, and strive to
> >> resolve them through discussion or by updating the draft.
> >>
> >> Document: draft-ietf-trill-ia-appsubtlv-07.txt
> >> Reviewer: Danny McPherson
> >> Review Date: May 4, 2016
> >> Intended Status: Proposed Standard
> >>
> >>
> >> Summary:
> >>
> >>  I have some minor concerns about this document that I think should
> >>  be resolved before publication.
> >>
> >>
> >> Comments:
> >>
> >> I believe the draft is technically sound, however, the quality and
> >> readability needs a bit more work, particularly as it relates to
> >> introduction of new terms, and consistent application and use of all
> >> terms.  There are also some general error handling and encoding
> >> issues that need to be given consideration.
> >>
> >>
> >> Major Issues:
> >>
> >> I have no “Major” issues with this I-D.
> >
> >Thanks.
> >
> >> Minor Issues:
> >>
> >> 1. ERROR HANDLING: There are a number of places in the document
> >> where it discusses the receipt of malformed, badly encoded,
> >> non-matching, or corrupt messages, and the advice is to either
> >> [silently] discard or ignore the messages.  Some general guidance
> >> should be given here to enable operational diagnosis of any issues
> >> that may result in temporal or persistent problems, where logging
> >> and other actions should occur.  Some aspects of this might leverage
> >> the OAM Framework efforts, although it appears much of the TRILL
> >> work leaves this to the implementer.
> >
> >In the IETF context "silently discard" means that there is no
> >on-the-wire message sent. It says nothing about whether or not
> >counters are kept of such condition or errors are logged. A suggestion
> >to log such events and/or keep such counters can be added.
> >
> >> 2. When using “Nickname” it would be useful to define the encoding
> >> as an unsigned 16-bit integer, or just reference "as specified in S
> >> 3.7 of RFC6325”.
> >
> >OK. Will add the reference.
> >
> >> 3. The inclusion of the “TLV” acronym in the "APPsub-TLV” TLV name
> >> seems loose and redundant to me, as opposed to “APPsub TLV” or
> >> similar.
> >
> >This comes from RFC 6823, Section 3.2, which says that sub-TLVs that
> >go inside the GENAPP TLV "are refrred to as APPsub-TLVs".
> >
> >> 4. Inconsistent use of “Interface Address APPsub-TLV”, “IA
> >> APPSub-TLV”, “Interface Address APP-subTLV”, and “AppsubTLV” makes
> >> it seem like you’re talking about different things.
> >
> >OK - that should be made more consistent, probably standardizing on
> >"IA APPsub-TLV".
> >
> >> 5. The use of “sub-sub-TLV” seems a bit loose and sloppy to me as
> >> well, and should be cleaned up.  E.g., S 5.2 “IA Appsub-TLV
> >> Sub-Sub-TLVs SubRegistry"
> >
> >You don't like "sub-sub-TLV"?
> >
> >Seems like, strictly speaking, you have IS-IS PDUs which contain
> >TLVs. Then some TLVs can contain sub-TLVs. (The GENAPP TLV is the only
> >one that occurs to me with a special name for its sub-TLVs, namely
> >APPsub-TLVs.) and some sub-TLVs can contain a further nested level,
> >which it seems to me to be precise and logical to call sub-sub-TLVs.
> >(I am not aware of any requirement for any more deeper nesting in a
> >use of IS-IS.) So, would you prefer that what are called sub-sub-TLVs
> >in this document just be called "sub-TLVs" (which I agree they are)
> >resulting in two different levels with the same name? While there
> >might be some errors in their use in this draft, the mere use of
> >APPsub-TLV and sub-sub-TLV for the two levels does not seem "loose and
> >sloppy" to me...
> >
> >> 6. Only one of the “Figures” is labeled / captioned
> >
> >OK. All the principal figures should be labeled. (I don't think cases
> >where there is a small, indented figure that just expands part of a
> >principal figure and appears shortly after the principal figure need
> >to be 

Re: [trill] [RTG-DIR] RtgDir Review: draft-ietf-trill-centralized-replication-05

[Alia Atlas]

Hi Keyur,

Thank you very much for your review.

Regards,
Alia

On Wed, Apr 27, 2016 at 6:30 PM, Keyur Patel (keyupate) 
wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir.
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-trill-centralized-replication-05
> Reviewer: Keyur Patel
> Review Date: 27-Apr-2016
> Intended Status: Standards Track
>
>
> Summary:
> The document is well written and seems ready for the publication. No major
> issues found. Minor nits are listed below.
>
> Major Issues:
> None.
>
> Minor Issues
>
>
>1. Intended Status: "Standards Track" Please.
>2.
>
>Section 1, 3 paragraph: S/will be described/is described.
>3.
>
>Section 11.1, Do you need to define any error conditions where
>multiple flag bits are set?
>
>
> Regards,
> Keyur
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] RtgDir review: draft-ietf-trill-arp-optimization

[Alia Atlas]

Geoff,

Thank you very much for your review.

Regards,
Alia

On Fri, Apr 15, 2016 at 9:44 PM, Geoff Huston  wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-trill-arp-optimization-05.txt
> Reviewer: Geoff Huston
> Review Date: 16 April 2016
> IETF LC End Date: date-if-known
> Intended Status: copy-from-I-D
>
> Summary:
> This document is basically ready for publication, but has nits
> that should be considered prior to publication.
>
> Comments:
> I found the draft concise and clear. It was readable and readily
> understood.
>
> Major Issues:
> No major issues found
>
>
> Minor Issues:
> No minor issues found.
>
> Nits:
> Minor:
>  section 2: “...receive and save such mapping information also.”
> seems a bit stilted  and I would say “also receive and save such mapping
> information.
>
>  section 3.1 "populate the information of sender's IP/MAC in its
> ARP table”. Do the authors really mean "ARP table" if the information was
> learned by ND? i.e. its clear that the authors are referring to the local
> IP/MAC address table, but the previous text tends to associated ARP with
> IPv4 and ND with IPv6. Perhaps “AARP/ND table” ?
> ___
> 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