Hi Suresh, On Thu, Jun 30, 2016 at 11:14 PM, Suresh Krishnan <[email protected]> wrote: > Hi Donald, > Your proposed changes and clarifications look good to me. I will look over > the new version when it is posted.
Version -14 has been posted with the intent of resolving your DISCUSS. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] > Thanks > Suresh > > On 06/30/2016 02:13 PM, Donald Eastlake wrote: >> Hi Suresh, >> >> Thanks for your comments. See below. >> >> On Wed, Jun 29, 2016 at 7:08 PM, Suresh Krishnan >> <[email protected]> wrote: >>> Suresh Krishnan has entered the following ballot position for >>> draft-ietf-trill-irb-13: Discuss >>> >>> ... >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> * Section 6 has a few errors that need to get fixed before this document >>> goes forward. e.g. It is not clear what a "192.0.2.0/32" subnet means >>> especially since the only host shown to be on the subnet 192.0.2.2 cannot >>> obviously fall inside the subnet range. The /32 needs to be replaced with >>> something shorter depending on what the authors/WG intended (say a /24). >> >> Yes. That should have been "/24". >> >>> * RB2 seems to be advertising ES2s IPv4 address 198.51.100.2/32 instead >>> of the prefix of the subnet while RB1 seems to be advertising the the >>> IPv4 prefix of the ES1 subnet. One of these is wrong. Not sure which one >>> is intended. >> >> It should be the prefix in both cases. >> >>> * What is the rationale for using a /112 IPv6 prefix for numbering an >>> IPv6 link with hosts? Things like SLAAC (RFC4862) will not work in such >>> links. Is there a reason the authors want to use a longer than /64? >>> Please read RFC7421 for advantages of using a /64 instead and to find out >>> what things break if you do not use a /64. >> >> The Distributed Layer 3 gateway specified in this draft is expect to >> primarily be used in data centers where I would expect everything to >> be strictly configured by an orchestration system. Thus stateless >> autoconfiguration seems less likely and I suspect it just wasn't >> through of. However, I don't see a problem with changing this to "/64" >> and the mechanism specified could be used in other contexts outside >> data centers. >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Section 5: What does "Layer 2 routing" mean in this context? >> >> Previously standardized TRILL routing, which is based on destination >> MAC address as mapped into a TRILL nickname. The wording can be >> clarified. >> >>> Sections 7.3 & 7.4: What is the point of including these sub-TLVs if no >>> prefix is being advertised? (The Total Length=0 case specified in the >>> document) >> >> Sometimes a zero length has some special meaning. The draft just says >> that it has the obvious meaning although it is not a particularly >> useful value. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA >> [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
