Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark

Hi Bob,

Thank you very much for your suggestion. I agree.
We will update this in the next revision.

BR,
Tianran

> -----Original Message-----
> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> Sent: Tuesday, October 22, 2019 11:33 PM
> To: Tianran Zhou <zhoutianran@huawei.com>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Giuseppe Fioccola
> <giuseppe.fioccola@huawei.com>; IPv6 List <ipv6@ietf.org>; IETF IPPM WG
> <ippm@ietf.org>; Tom Herbert <tom@quantonium.net>; Haoyu Song
> <haoyu.song@futurewei.com>; draft-fz-6man-ipv6-alt-mark@ietf.org
> Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
> 
> Tianran,
> 
> 
> > On Oct 21, 2019, at 9:04 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> >
> > Hi Bob,
> >
> > Thanks for your comments.
> > On this:
> > " In the EH definition in Section 3.1.1 there is a field called "Flow ID".
> I can’t tell if this is the same or different from the IPv6 flow label defined
> in RFC8200 and RFC6437.   This should be clarified and justified."
> >
> > Here are my thoughts:
> > 1. The flow label in rfc8200 is used for application service, like LB/ECMP,
> QoS. The flow ID used in the EH is to identify the monitored flow, and may
> be assigned by a controller. That is to say, flow label and flow ID within
> the same packet will have different scope, identify different flows,
> different usage. So it's better to separate the two.
> > 2. The flow ID is used for monitoring and measurement. The reuse of flow
> label field may change the application intent(e.g.ECMP) and forwarding
> behavior. So that the measurement does not align with the original traffic.
> > 3. The flow label may be changed en route. The reuse of the flow label field
> for the flow ID may violate the measurement task.
> 
> The issue I raised is that because the names are similar, it is easy to confuse
> the two.  If this is different, the draft needs to be much clearer on its
> definition.  For example, the draft doesn’t include most of the text you wrote
> above.
> 
> I would also suggest a different name so it won’t be confused.  For example,
> “measurement ID”, or similar.
> 
> Bob
> 
> 
> >
> > Any thoughts?
> >
> > Best,
> > Tianran
> >> -----Original Message-----
> >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Giuseppe
> >> Fioccola
> >> Sent: Monday, October 21, 2019 9:30 PM
> >> To: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>;
> >> IETF IPPM WG <ippm@ietf.org>; Tom Herbert <tom@quantonium.net>
> >> Cc: Haoyu Song <haoyu.song@futurewei.com>;
> >> draft-fz-6man-ipv6-alt-mark@ietf.org
> >> Subject: RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
> >>
> >> Dear Bob, Tom,
> >> Thanks a lot for your review of the draft. Much appreciate.
> >> Please find my answers inline tagged as [GF].
> >>
> >> Best Regards,
> >>
> >> Giuseppe
> >>
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> >> Sent: Saturday, October 19, 2019 7:08 PM
> >> To: IPv6 List <ipv6@ietf.org>; IETF IPPM WG <ippm@ietf.org>
> >> Cc: Bob Hinden <bob.hinden@gmail.com>; Haoyu Song
> >> <haoyu.song@futurewei.com>; draft-fz-6man-ipv6-alt-mark@ietf.org; Tom
> >> Herbert <tom@quantonium.net>
> >> Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
> >>
> >> Hi,
> >>
> >> I did a quick read of this draft and have a few comments.
> >>
> >> It appears to be defining a new IPv6 extension header.   It should say
> that
> >> in the title and be described in the abstract.
> >>
> >> [GF]: I will do.
> >>
> >>   This document defines how the alternate marking method can be used to
> >>   measure packet loss and delay metrics of IPv6 and SRv6.
> >>
> >> As Tom mentioned, SRv6 is part of IPv6, they are not separate things.
> >>
> >> [GF]: Sure, we meant that it can be applicable to IPv6 and, as a
> >> consequence, also to SRv6. We will specify it better in the next revision.
> >>
> >>   The IPv6 Header Format defined in [RFC8200] introduces the format of
> >>   the IPv6 addresses, the Extension Headers in the base IPv6 Header and
> >>   the availability of a 20-bit flow label, that can be considered for
> >>   the application of the Alternate Marking methodology.  In this
> >>
> >> RFC8200 does not define the format of IPv6 addresses.  That is done
> >> in RFC4291.
> >>
> >> [GF]: Yes, we will add the reference to RFC4291.
> >>
> >> This draft appears to depend on a number of IPPM documents, but none
> >> are listed as normative references.
> >>
> >> [GF]: We will review the dependencies. In particular we may need to
> >> cut the reference to draft-zhou-ippm-enhanced-alternate-marking and
> >> leave only RFC
> >> 8321 and draft-ietf-ippm-multipoint-alt-mark.
> >>
> >> One of these is RFC 8321, but that has status of Experimental.  I
> >> don’t think this document can be Standards track if it depends on an
> Experimental RFC.
> >>
> >> [GF]: Consider that RFC 8321 was classified as Experimental since it
> >> describes a methodology that came from lab experience. In particular,
> >> the first example of application was with IP packets where there is
> >> no space for marking and we reused the DSCP field for our scope.
> >> However the applicability of the method is general and, in this
> >> draft, the new IPv6 extension header introduces an appropriate
> >> marking field that would be dedicated only for the alternate marking
> >> method and not for other purposes. So we refer to RFC 8321 just for
> >> information and this does not necessarily imply that the draft should be
> experimental, therefore it could be discussed.
> >>
> >> In the EH definition in Section 3.1.1 there is a field called "Flow
> >> ID".  I can’t tell if this is the same or different from the IPv6 flow
> label defined
> >> in RFC8200 and RFC6437.   This should be clarified and justified.
> >>
> >> [GF]: Of course, it is a separate field and we will make it clearer
> >> in the next version.
> >>
> >> Bob
> >>
> >>
> >>
> >>> On Oct 19, 2019, at 8:32 AM, Tom Herbert <tom@quantonium.net> wrote:
> >>>
> >>> On Fri, Oct 18, 2019 at 1:30 AM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
> >>>>
> >>>> I just read this draft and I think it’s an implementation of the
> >>>> draft
> >> [I-D.zhou-ippm-enhanced-alternate-marking], which discusses the
> >> method of encapsulating the enhanced alternate marking header in
> >> IPv6. I have several comments.
> >>>>
> >>>>
> >>>>
> >>>> It doesn’t cover the encapsulation on SRv6 yet and I think a
> >>>> solution for
> >> SRv6 would be more useful.
> >>>
> >>> SRv6 _is_ a subset IPv6. It is one type of routing header. Like any
> >>> other use case of IPv6, HBH and destination options are useable when
> >>> SRv6 header is present. Because SRv6 is a routing header destination
> >>> options before the routing header are processed by each destination
> >>> in the route list.
> >>>
> >>>> More deployment consideration discussion should be given when it’s
> >>>> encapsulated in HBH EH
> >>>
> >>> In what regard?
> >>>
> >>>> The document mentioned two PBT modes discussed in
> >> [I-D.song-ippm-postcard-based-telemetry]. Since the PBT-I variation
> >> has been merged in another draft
> >> [I-D.ioamteam-ippm-ioam-direct-export], this draft may need to be updated
> accordingly.
> >>>>
> >>>>
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>>
> >>>> Haoyu
> >>>>
> >>>> _______________________________________________
> >>>> ippm mailing list
> >>>> ippm@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/ippm
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------