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

From: Haoyu Song <[email-masked]>
Date: Fri, 18 Oct 2019 08:30:09 +0000

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.

  1.  It doesn't cover the encapsulation on SRv6 yet and I think a solution for SRv6 would be more useful.
  2.  More deployment consideration discussion should be given when it's encapsulated in HBH EH
  3.  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

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 18 Oct 2019 09:49:04 +0000

Hi Haoyu,
Thanks a lot for reading the draft and for sharing your comments.
Please find my answers inline tagged as [GF].

Best Regards,

Giuseppe

From: Haoyu Song [mailto:[email-masked]]
Sent: Friday, October 18, 2019 10:30 AM
To: [email-masked]; [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Mail regarding draft-fz-6man-ipv6-alt-mark

[GF]: The draft aims to be general for IPv6 data plane and we will include a new section on SRv6 in the next revision.

  1.  More deployment consideration discussion should be given when it's encapsulated in HBH EH
[GF]: Regarding HBH EH, if we consider its real deployment, it is sometimes dropped by legacy devices and not so used by intermediate nodes. DOH is preferred.
SRH can also be a good choice from this point of view. The intermediated nodes that are not in the SID list can consider the SRH as a green field, they cannot support and bypass or support and dig into the SRH TLV.

  1.  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.

[GF]: Sure, we will update and change the reference regarding PBT-I from draft-song-ippm-postcard-based-telemetry to draft-ioamteam-ippm-ioam-direct-export.

Thanks!

Haoyu

---

From: Tom Herbert <[email-masked]>
Date: Sat, 19 Oct 2019 08:32:55 -0700

On Fri, Oct 18, 2019 at 1:30 AM Haoyu Song <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Bob Hinden <[email-masked]>
Date: Sat, 19 Oct 2019 10:07:35 -0700

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.

   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.

   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.

This draft appears to depend on a number of IPPM documents, but none are listed as normative references.

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.

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.

Bob

> On Oct 19, 2019, at 8:32 AM, Tom Herbert <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Haoyu Song <[email-masked]>
Date: Sun, 20 Oct 2019 21:57:17 +0000

inline

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Saturday, October 19, 2019 8:33 AM
To: Haoyu Song <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark

> 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.

[HS] What I mean is to make it a part of SRH. Sorry I didn't make it clear. 

In what regard?

[HS] I just think there might be some deployment issues for SRv6 EH

> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Chaoyu.song%40f
> uturewei.com%7Cd8011b4323b24621feae08d754a9a4f3%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C1%7C637070959917566910&amp;sdata=p6xgfJ1PWLLA8T%2BM
> 5%2FFu%2Fa5Hae9ulu82aTnkqHPQMc0%3D&amp;reserved=0

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 21 Oct 2019 13:30:19 +0000

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:[email-masked]] 
Sent: Saturday, October 19, 2019 7:08 PM
To: IPv6 List <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Haoyu Song <[email-masked]>; [email-masked]; Tom Herbert <[email-masked]>
Subject: Re: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark

Hi,

[GF]: I will do.

[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. 

[GF]: Yes, we will add the reference to RFC4291.

[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.

[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.

[GF]: Of course, it is a separate field and we will make it clearer in the next version.

Bob

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 22 Oct 2019 04:04:08 +0000

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.

Any thoughts?

Best,
Tianran
> From: ipv6 [mailto:[email-masked]] On Behalf Of Giuseppe Fioccola
> Sent: Monday, October 21, 2019 9:30 PM
> To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>; IETF IPPM
> WG <[email-masked]>; Tom Herbert <[email-masked]>
> Cc: Haoyu Song <[email-masked]>;
> [email-masked]
> Subject: RE: [ippm] Mail regarding draft-fz-6man-ipv6-alt-mark
> 
> Dear Bob, Tom,
> Cc: Bob Hinden <[email-masked]>; Haoyu Song
> <[email-masked]>; [email-masked]; Tom
> Herbert <[email-masked]>
> 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.
> 
> [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.
> 
> [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.
> 
> >> 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.
> >>
> >>
> >>
> >> 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
> >>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 22 Oct 2019 08:33:12 -0700

Tianran,

> On Oct 21, 2019, at 9:04 PM, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Bob,
> 

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

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Oct 2019 01:19:43 +0000

Hi Bob,

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

BR,
Tianran

> Sent: Tuesday, October 22, 2019 11:33 PM
> To: Tianran Zhou <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; Giuseppe Fioccola
> <[email-masked]>; IPv6 List <[email-masked]>; IETF IPPM WG
> <[email-masked]>; Tom Herbert <[email-masked]>; Haoyu Song
> <[email-masked]>; [email-masked]
> > " 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.
> 
> >> To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>;
> >> IETF IPPM WG <[email-masked]>; Tom Herbert <[email-masked]>
> >> [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.
> >>
> >> [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
> >> 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
> >> 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
> >> [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.
> >>>
> >>> options before the routing header are processed by each destination
> >>> in the route list.
> >>>
> >> [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
> >>>>
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Oct 2019 11:38:17 +0200

Tianran,

Also in this document you state:
   The desired choice is to define a new Extension Header.
   [I-D.zhou-ippm-enhanced-alternate-marking] generalizes the data
   fields for the alternate marking method and inspired the layout.

But then it seems that you define a new TLV (aka option) for the HBH and DestOpt EHs. Is that correct?
If so it might be worth making that clear in the document. Now it reads in some places like you are proposing to create a new extension header.
Which we in general are not in favour of, given that we have three generic "container" EHs already. And tht we have text in 8200 strongly recommending against creating new EHs with hop by hop behaviour.

Best regards,
Ole

> On 23 Oct 2019, at 03:19, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Bob,
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Oct 2019 10:07:56 +0000

Hi Ole,

Thank you very much for your suggestion. You are right, the text is not clear.
We are not going to create new EH, but to define TLVs.
This draft we may consider and compare several potential EHs and provide our preference. 
We will correct this in the next version.

Thanks,
Tianran

> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2019 5:38 PM
> Cc: Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; IETF IPPM
> WG <[email-masked]>; Haoyu Song <[email-masked]>;
> [email-masked]; Tom Herbert <[email-masked]>
> If so it might be worth making that clear in the document. Now it reads in
> some places like you are proposing to create a new extension header.
> Which we in general are not in favour of, given that we have three generic
> "container" EHs already. And tht we have text in 8200 strongly recommending
> against creating new EHs with hop by hop behaviour.
> 
> Best regards,
> Ole
> 
> 
> >> <[email-masked]>; IPv6 List <[email-masked]>; IETF IPPM
> >> WG <[email-masked]>; Tom Herbert <[email-masked]>; Haoyu Song
> >> 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.
> >> label field may change the application intent(e.g.ECMP) and
> >> forwarding behavior. So that the measurement does not align with the
> original traffic.
> >> 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.
> >>
> >>>> <[email-masked]>; [email-masked];
> >>>> Tom Herbert <[email-masked]>
> >>>>  This document defines how the alternate marking method can be used
> >>>> to  measure packet loss and delay metrics of IPv6 and SRv6.
> >>>>
> >>>>  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
> >>>>
> >>>> [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.
> >>>> 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
> >>>>> On Fri, Oct 18, 2019 at 1:30 AM Haoyu Song
> >>>>> <[email-masked]>
> >> wrote:
> >>>>>>
> >>>>> 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.
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> -- IETF IPv6 working group mailing list [email-masked]
> >>>>> Administrative
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [email-masked] Administrative