Hi Linda, Thank you for your considerations. Please see my answers inline tagged as [GF]. Best Regards, Giuseppe -----Messaggio originale----- Da: Linda Dunbar [mailto:linda.dunbar@xxxxxxxxxx] Inviato: mercoledì 20 settembre 2017 00:23 A: gen-art@xxxxxxxx Cc: ietf@xxxxxxxx; draft-ietf-ippm-alt-mark@xxxxxxxx Oggetto: [Gen-art] Gen-art last call review of draft-ietf-ippm-alt-mark-10 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ippm-alt-mark-10 Reviewer: Linda Dunbar Review Date: 2017-09-19 IETF LC End Date: 2017-09-28 IESG Telechat date: ?? Summary: This document is written very clear and comprehensive. It is Ready. One single question remains open, it is minor. Major issues: None Minor issues: Section 3.1.1, second paragraph states ".. every node along the path must be able to identify unambiguously the colored packets". I think the scheme should work even if some intermediate nodes don't support the proposed scheme. If every node supports the scheme, using Link based method, there shouldn't be any disorder of packets. Correct? [GF]: You are right, the scheme will work even if some intermediate nodes are not able to identify unambiguously the colored packets. I could change this sentence because I meant that ".. every node that is designated as a measurement point should be able to identify unambiguously the colored packets". The out of order issue could be avoided in any case by taking the counter during the available counting interval (as described in section 3.2) that considers the interval we need to wait to avoid out of order because of network delay and clock error between network devices. Section 3.1.1 last paragraph also states that the "how to choose the marking field ... is out of the scope". Besides the DSCP field, what other options there could be? Just curious. [GF]: Besides the DSCP field in the IPv4 Header, draft-chen-ippm-coloring-based-ipfpm-framework suggests to use the "evil bit" (unused bit in the IPv4 Flags field) to perform marking (the IPFPM use case is mentioned in section 5.2). In addition, regarding MPLS, Synonymous Flow Label can be used for marking as reported in section 5.4 (draft-ietf-mpls-rfc6374-sfl). Regarding BIER, two OAM bits from BIER Header are reserved for the passive performance measurement marking method (draft-ietf-bier-pmmm-oam). There are also new proposals in NVO3 (draft-fmm-nvo3-pm-alt-mark) and SFC (draft-mirsky-sfc-pmamm). Nits/editorial comments: Thanks, Linda Dunbar _______________________________________________ Gen-art mailing list Gen-art@xxxxxxxx https://www.ietf.org/mailman/listinfo/gen-art Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario.