Hi, On 25/10/2014 14:37, Xiayangsong wrote: > Hi Brian > > Thanks for your attention on this topic. I am an engineer not > a standard guy . I discussed this idea with Behcet who > kindly put me as the first author. > > So I try to respond you from engineering perspective.
Understood, but IETF standards are supposed to correspond to real engineering, so that is no problem. > > Thanks Frank > > -----邮件原件----- 发件人: Brian E Carpenter > [mailto:[email protected]] 发送时间: 2014年10月25日 8:54 收 > 件人: [email protected]; > [email protected]; > [email protected] 主题: Re: I-D Action: > draft-xia-nvo3-vxlan-qosmarking-00.txt > > Hi, > > This draft needs to be discussed in tsvwg I think. It has > some significant problems IMHO: > > 1. It confuses QoS and priority in a strange way. > Frank=>QoS > is about packet loss, bandwidth, latency and jitter. Those are the usual QoS metrics of course. > Bandwidth can be controller by CAR technology. As for latency > and jitter, they are kind of inherent parameter of a given > network, and there is hardly a way to controller them . > Thus, in most scenario, QoS is about packet loss control > which is based on priority. I suggest carefully reviewing RFC 2474 and RFC 2475, and the specific descriptions of per-hop behaviours in RFC 2597 and RFC 3246. Also it is worth reviewing RFC 4594, draft-geib-tsvwg-diffserv-intercon, and the work of the AQM WG (http://datatracker.ietf.org/wg/aqm/charter/). Truly there is a lot more to queue management than simple priority. > 2. It repeats the MPLS error of trying to express service > differentiation in 3 bits. > Frank=>I don't know the MPLS > error, please teach me. However, in engineering area, MPLS 3 > bit has a pragmatic purpose. You can check switches/routers > specification from different vendors about this. The problem is that re-using the three EXP (experimental) bits in MPLS for quality of service signalling was an afterthought. Three bits simply isn't enough to express a reasonable range of service classes. Unfortunately it is all we have in MPLS, but that is not a valid reason for copying the same mistake. If you adopt 6 bits, it should be fairly easy to adopt the whole diffserv model. That would save a lot of work, both in specification and in implementation. > > 3. It makes a completely inaccurate statement about diffserv: > "The first three bits of DS field are used for IP precedence > and the last three are used as diff serv bits." > Frank=>I > guess the statement was copied from some RFC, and I would > double check it. If so, that RFC is wrong. It is true that in some cases, the recommended diffserv code points were chosen to have the same bit pattern as the old ToS precedence bits. This was done so that if packets marked with diffserv code points happened to pass through a legacy router that supported the ToS bits, the results would be reasonable. However, diffserv code points are in fact defined as opaque 6-bit values. The above references should make this clear. In summary my suggestion is 1) use 6 bits 2) state that they are to be interpreted exactly like the DSCP defined in RFC 2474 3) this simplifies the question of mapping between the vxlan header and the IP header, when needed. 4) it would also simplify interworking with the QoS model for WebRTC that is under development. Regards Brian > > Brian > > On 25/10/2014 08:16, [email protected] wrote: >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> >> Title : Quality of Service Marking in Virtual >> eXtensible Local Area Network Authors : Frank Xia >> Behcet Sarikaya Filename : >> draft-xia-nvo3-vxlan-qosmarking-00.txt Pages : 9 >> Date : 2014-10-24 >> >> Abstract: The Virtual eXtensible Local Area Network enables >> multiple tenants to operate in a data center. Each tenant >> needs to be assigned a priority group to prioritize their >> traffic. Cloud carriers wish to use quality of service to >> differentiate different applications. For these purposes, >> three bits are assigned in the eXtensible Local Area >> Network header. How these bits are assigned and are >> processed in the network are explained in detail. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-xia-nvo3-vxlan-qosmarking/ >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-xia-nvo3-vxlan-qosmarking-00 >> >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list [email protected] >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
