Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Donald Eastlake]

Hi Ben,

Thanks for the further review and comments. See below.

Version -08 has been uploaded with the goal of resolving these comments.

On Wed, Jan 17, 2018 at 8:48 AM, Ben Niven-Jenkins
 wrote:
>
> Hi Donald,
>
> Apologies for not responding sooner, I have reviewed the latest version (-07) 
> and still have a couple of comments, see inline below. I have also included 
> at the bottom of this email some additional editorial nits I found when 
> reading -07. I have trimmed previous comment and responses from you that are 
> now covered in the document.
>
> On 10 Jan 2018, at 20:05, Donald Eastlake  wrote:
>
> ...
>
> On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake  wrote:
>>
>> Hi Ben,
>>
>> Thanks for your review. It appears that is was not responded to in a
>> timely fashion. Apologies on behalf of the authors.
>>
>> (Your review was of the -02 version. The current version is -05.)
>>
>> On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
>>  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. 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-directory-assisted-encap-02.txt
>> > Reviewer: Ben Niven-Jenkins
>> > Review Date: 21 April 2016
>> > Intended Status: Proposed Standard
>> >
>> > Summary:
>> > I have significant concerns about this document and recommend that
>> > the Routing ADs discuss these issues further with the authors.
>>
>> Hopefully the changes made between the version -02 you reviewed and
>> the current -05 have made some improvements and, based on your
>> comments and WG LC comments, further improvements can be made.
>
>
> I think the -07 is almost good to go, the only outstanding concern I have is 
> with regards to the security considerations section, see below.

Thanks.

>> > Comments:
>> > Overall this is not the easiest document to read although some of
>> > that might be due to my lack of background in TRILL and its
>> > terminology.
>> >
>> > Major Issues:
>> >
>> > 1) The document has an Intended Status of Proposed Standard, however
>> > it does not contain any RFC2119 keywords and does not seem to make
>> > any normative statements about required behaviour which I would have
>> > expected in a Proposed Standard.
>>
>> Well, in version -05 there is at least one keyword instance.
>> Furthermore, I don't know that such keywords need to always be used
>> when an implementation requirement level is being specified. That
>> said, we could see if additional RFC 2119 keywords are warranted.
>
> I noted this as a flag to the ADs because the lack of RFC2119 key words 
> seemed unusual to me. If the ADs are happy for this to be proposed standard 
> then I am happy with it being a proposed standard.

OK.

>> > 2) Section 4: If I understand correctly the TRILL-EN spoofs the
>> > Ingress RBridge edge node's nickname in the source address field of
>> > the TRILL header. Is this likely to introduce problems? E.g. if
>> > RBridges will accept & forward frames that have their own source
>> > address in, does it perpetuate routing loops or present security
>> > considerations that the document should discuss?
>>
>> TRILL goes to great lengths to avoid loops and has a hop count in the
>> TRILL header so that, should there be a transient loop, a TRILL packet
>> in that loop (i.e., an encapsulated frame) will be discarded. In the
>> potentially more dangerous case of multi-destination packets, as
>> compared with known unicast, where copies could multiply due to forks
>> in the distribution tree, a Reverse Path Forwarding Check is used to
>> discard packets that appear to be on the wrong link or when there is
>> disagreement about the distribution tree.
>>
>> Security Considerations should probably say more on this.
>>
>> > Section 8 on Security Considerations also looks very light on
>> > text. If you are allowing TRILL-ENs to spoof RBridge source
>> > addresses (which I think you are, see comment above) I think you
>> > should have a discussion about that somewhere in the document.
>>
>> I agree that some further discussion is needed in the Security
>> Considerations section.
>
> I don’t see any discussion on TRILL-ENs spoofing ingress bridge nicknames in 
> section 7 on security considerations. I see the security consideration 
> section of the referenced 

[trill] I-D Action: draft-ietf-trill-directory-assisted-encap-08.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   : Directory Assisted TRILL Encapsulation
Authors : Linda Dunbar
  Donald Eastlake
  Radia Perlman
Filename: draft-ietf-trill-directory-assisted-encap-08.txt
Pages   : 15
Date: 2018-01-17

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



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assisted-encap/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-directory-assisted-encap-08
https://datatracker.ietf.org/doc/html/draft-ietf-trill-directory-assisted-encap-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-directory-assisted-encap-08


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] Comments on draft-ietf-trill-transport-over-mpls-06

[Andrew G. Malis]

Donald,

I agree with your recommended changes.

While we’re discussing the draft, I've previously commented that it has
several places where interoperability between implementations could be
difficult because there are several implementation choices that can be
made, and the draft doesn’t make any particular recommendations or require
any of the choices to be implemented. I have some proposed text to fix this.

1. There are two models defined, the VPLS and VPTS models, and the draft
doesn’t recommend which to use. The draft should recommend the VPTS model
as the default, as it is an emulated TRILL service. This can be fixed in
either section 2 or section 6 (or both) by adding “As this is an emulated
TRILL service, for interoperability purposes the VPTS model is the
default.” I'll let the draft authors decide if section 2 or section 6 (or
both) is better for this.

2. When using the VPTS model, section 4.3 says that either the PPP or
Ethernet encapsulation from RFC 7173 can be used, and makes no
recommendation between them. However, RFC 7173 defines the PPP
encapsulation as the chosen default, and that encapsulation should be used
here as well. This can be fixed by adding “In accordance with [RFC7173],
the PPP encapsulation is the default.”

Thanks,
Andy


On Tue, Jan 16, 2018 at 6:05 PM, Donald Eastlake  wrote:

> Hi,
>
> There are a bunch of RFCs referenced in this draft but not listed in the
> References section. They need to be added to the References.
>
> I think the Security Considerations section, while it provides a good set
> of references, needs one added sentence: something about how the document
> does not change the security considerations because it uses existing
> standards without change.
>
> Section 5 is very short and seems like it could be moved up and merged
> with the Introduction. (The section number of the following sections would
> be reduced by one.)
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Ben Niven-Jenkins]

Hi Donald,

Apologies for not responding sooner, I have reviewed the latest version (-07) 
and still have a couple of comments, see inline below. I have also included at 
the bottom of this email some additional editorial nits I found when reading 
-07. I have trimmed previous comment and responses from you that are now 
covered in the document.

> On 10 Jan 2018, at 20:05, Donald Eastlake  wrote:
> 
> Hi Ben,
> 
> As far as I know, you never responded to the email below or to the subsequent 
> email to you from Sue Hares asking you to check if the current version (-06) 
> of this draft resolves your RTGDIR review comments.
> 
> I realize there was a lot of earlier delay on the part of the TRILL WG but, 
> please, can you repond on this now?
> 
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com 
> On Thu, Oct 26, 2017 at 10:29 PM, Donald Eastlake  > wrote:
> Hi Ben,
> 
> Thanks for your review. It appears that is was not responded to in a
> timely fashion. Apologies on behalf of the authors.
> 
> (Your review was of the -02 version. The current version is -05.)
> 
> On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
> > 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. 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-directory-assisted-encap-02.txt
> > Reviewer: Ben Niven-Jenkins
> > Review Date: 21 April 2016
> > Intended Status: Proposed Standard
> >
> > Summary:
> > I have significant concerns about this document and recommend that
> > the Routing ADs discuss these issues further with the authors.
> 
> Hopefully the changes made between the version -02 you reviewed and
> the current -05 have made some improvements and, based on your
> comments and WG LC comments, further improvements can be made.

I think the -07 is almost good to go, the only outstanding concern I have is 
with regards to the security considerations section, see below.

> > Comments:
> > Overall this is not the easiest document to read although some of
> > that might be due to my lack of background in TRILL and its
> > terminology.
> >
> > Major Issues:
> >
> > 1) The document has an Intended Status of Proposed Standard, however
> > it does not contain any RFC2119 keywords and does not seem to make
> > any normative statements about required behaviour which I would have
> > expected in a Proposed Standard.
> 
> Well, in version -05 there is at least one keyword instance.
> Furthermore, I don't know that such keywords need to always be used
> when an implementation requirement level is being specified. That
> said, we could see if additional RFC 2119 keywords are warranted.

I noted this as a flag to the ADs because the lack of RFC2119 key words seemed 
unusual to me. If the ADs are happy for this to be proposed standard then I am 
happy with it being a proposed standard.

> > 2) Section 4: If I understand correctly the TRILL-EN spoofs the
> > Ingress RBridge edge node's nickname in the source address field of
> > the TRILL header. Is this likely to introduce problems? E.g. if
> > RBridges will accept & forward frames that have their own source
> > address in, does it perpetuate routing loops or present security
> > considerations that the document should discuss?
> 
> TRILL goes to great lengths to avoid loops and has a hop count in the
> TRILL header so that, should there be a transient loop, a TRILL packet
> in that loop (i.e., an encapsulated frame) will be discarded. In the
> potentially more dangerous case of multi-destination packets, as
> compared with known unicast, where copies could multiply due to forks
> in the distribution tree, a Reverse Path Forwarding Check is used to
> discard packets that appear to be on the wrong link or when there is
> disagreement about the distribution tree.
> 
> Security Considerations should probably say more on this.
> 
> > Section 8 on Security Considerations also looks very light on
> > text. If you are allowing TRILL-ENs to spoof RBridge source
> > addresses (which I think you are, see comment above) I think you
> > should have a