Re: [trill] AD review of draft-ietf-trill-over-ip-14
Hi Alia, The just posted version -15 attempts to resolve your comments. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Feb 20, 2018 at 8:39 PM, Alia Atlas <akat...@gmail.com> wrote: > 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
Re: [trill] AD review of draft-ietf-trill-over-ip-14
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
Re: [trill] AD review of draft-ietf-trill-over-ip-14
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, 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] AD review of draft-ietf-trill-over-ip-14
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
