Subject: [Int-dir] Intdir telechat review of draft-ietf-bess-srv6-services-10

From: Ron Bonica via Datatracker <[email-masked]>
Date: Mon, 14 Feb 2022 09:19:36 -0800

Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Major issues:

1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

2) In Section 3.2.1 the draft says:

  BGP speakers that do not support this specification may misinterpret,
   on the reception of an SRv6-based BGP service route update, the part
   of the SRv6 SID encoded in MPLS label field(s) as MPLS label values
   for MPLS-based services.  Implementations supporting this
   specification SHOULD provide a mechanism to control the advertisement
   of SRv6-based BGP service routes on a per-neighbor and per-service
   basis.  The details of deployment designs and implementation options
   are outside the scope of this document.

s/BGP speakers that do not support this specification/Legacy BGP implementations

It seems that this isn't backwards compatible unless either:

- the SHOULD becomes a MUST
- the mechanism is described in this document

3) I concur with Warren Kumari's DISCUSS

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 15 Feb 2022 14:18:59 +0530

Hi Ron,

Thanks for your review and please check inline below for responses.

> shouldn't advertise an MPLS label?

KT> You are correct that there are no MPLS labels used in the forwarding.
The label fields are part of the BGP NLRI Encoding and not something
introduced newly. The transposition scheme leverages them for encoding
efficiency and better packing of BGP updates.

> s/BGP speakers that do not support this specification/Legacy BGP

KT> I am, personally, not in favor of using the term "legacy" in this case.

> - the mechanism is described in this document

KT> Ack. We can change the SHOULD to MUST.

Thanks,
Ketan

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 15 Feb 2022 15:12:17 +0000

Thank you Ron for your intdir review. As you have probably noticed, I just updated my ballot on this I-D.

Regards

-éric

On 14/02/2022, 18:20, "Int-dir on behalf of Ron Bonica via Datatracker" <[email-masked] on behalf of [email-masked]> wrote:

    Reviewer: Ron Bonica
    Review result: Not Ready

    Major issues:

    _______________________________________________
    Int-dir mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/int-dir

---

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Feb 2022 21:33:02 +0000

Ketan,

Mislabeling attributes is not only sloppy, but it can be dangerous. The danger is that somebody might read the label and believe it. Or conversely, that our labels will become meaningless, even when they are correct, because people learn that things are so frequently mislabeled.

Wouldn't we be better off with a new AFI/SAFI?

                                                                            Ron

Juniper Business Use Only
From: Ketan Talaulikar <[email-masked]>
Sent: Tuesday, February 15, 2022 3:49 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; BESS <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Intdir telechat review of draft-ietf-bess-srv6-services-10

[External Email. Be cautious of content]

Hi Ron,

On Mon, Feb 14, 2022 at 10:49 PM Ron Bonica via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

I am an assigned INT directorate reviewer for draft-ietf-bess-srv6-services.txt.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/<https://urldefense.com/v3/__https:/datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!TFWBh-IuHBLZ57zYsuHQyQca6MbsqWaKQ9Is6VSpRk9t4bmO3DZJ-JaLWnnJkGda$>
<https://datatracker.ietf.org/group/intdir/about/<https://urldefense.com/v3/__https:/datatracker.ietf.org/group/intdir/about/__;!!NEt6yMaO-gk!TFWBh-IuHBLZ57zYsuHQyQca6MbsqWaKQ9Is6VSpRk9t4bmO3DZJ-JaLWnnJkGda$>>.

Major issues:

KT> You are correct that there are no MPLS labels used in the forwarding. The label fields are part of the BGP NLRI Encoding and not something introduced newly. The transposition scheme leverages them for encoding efficiency and better packing of BGP updates.

Thanks,
Ketan

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Feb 2022 19:37:29 -0600

>    are outside the scope of this document.
Much thanks to Ron for this OpsDir review -- I'd completely missed the
above points, and they are important to address.

W

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 17 Feb 2022 07:30:21 +0000

Hi all,
About this point:

I have seen in some BESS documents that this field is called “Service Label”, not “MPLS label”.
Because MPLS does not exist in VxLAN too, but the same label is used.
Hence, 1) is easy to resolve. It is just a terminology correction that makes sense in principle for all BESS documents.
Eduard
From: BESS [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: Thursday, February 17, 2022 4:37 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

On Mon, Feb 14, 2022 at 11:20 AM Ron Bonica via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Ron Bonica
Review result: Not Ready

Major issues:

Much thanks to Ron for this OpsDir review -- I'd completely missed the above points, and they are important to address.

W

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/last-call

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Thu, 17 Feb 2022 07:41:26 +0000

I agree with Vasilenko.

The meaning of the label is given by the encapsulation, e.g. for the EVPN family, label=VNI if the bgp encapsulation extended community indicates VXLAN, and label=MPLS-label if the encapsulation indicates MPLS.

In this document, the label is a transposed function if the encapsulation indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with the approach used by SAFIs that support different identifiers in the label field.

Thanks.
Jorge

From: Vasilenko Eduard <[email-masked]>
Date: Thursday, February 17, 2022 at 8:30 AM
To: Warren Kumari <[email-masked]>, Ron Bonica <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10
Hi all,
About this point:
1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

Major issues:

W

---

From: Ketan Talaulikar <[email-masked]>
Date: Thu, 17 Feb 2022 13:50:26 +0530

+1

On Thu, Feb 17, 2022 at 1:11 PM Rabadan, Jorge (Nokia - US/Sunnyvale) <
[email-masked]> wrote:

> I agree with Vasilenko.
>
>
>
> The meaning of the label is given by the encapsulation, e.g. for the EVPN
> family, label=VNI if the bgp encapsulation extended community indicates
> VXLAN, and label=MPLS-label if the encapsulation indicates MPLS.
>
>
>
> In this document, the label is a transposed function if the encapsulation
> indicates SRv6 (given by the SRv6 Services TLV). So it is consistent with
> the approach used by SAFIs that support different identifiers in the label
> field.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *Vasilenko Eduard <[email-masked]>
> *Date: *Thursday, February 17, 2022 at 8:30 AM
> *To: *Warren Kumari <[email-masked]>, Ron Bonica <[email-masked]>
> *Cc: [email-masked] <
> [email-masked]>, [email-masked] <
> [email-masked]>, [email-masked] <[email-masked]>, [email-masked] <
> [email-masked]>
> *Subject: *RE: [bess] [Last-Call] Intdir telechat review of
> draft-ietf-bess-srv6-services-10
>
> Hi all,
>
> About this point:
>
> Hence, 1) is easy to resolve. It is just a terminology correction that
> makes sense in principle for all BESS documents.
>
> Eduard
>
> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Warren Kumari
> *Sent:* Thursday, February 17, 2022 4:37 AM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: [bess] [Last-Call] Intdir telechat review of
> draft-ietf-bess-srv6-services-10
>
>
>
>
>
>
>

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 17 Feb 2022 10:02:58 +0000

Hi all,

I agree with Vasilenko and Ketan.

The meaning of the label is given by the encapsulation. According to RFC8365[https://datatracker.ietf.org/doc/html/rfc8365], there are already a precedent for using the label field to carry VNI and without the new AFI/SAFI, and there are a large number of implementations and deployments that prove this scheme is feasible.

Thanks,
Shunwan

From: BESS [mailto:[email-masked]] On Behalf Of Ketan Talaulikar
Sent: Thursday, February 17, 2022 4:20 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>
Cc: [email-masked]; Vasilenko Eduard <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; Warren Kumari <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

+1

On Thu, Feb 17, 2022 at 1:11 PM Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Vasilenko.

Thanks.
Jorge

From: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 17, 2022 at 8:30 AM
To: Warren Kumari <[email-masked]<mailto:[email-masked]>>, Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10
Hi all,
About this point:
1) In Section 3.2.1, the draft transposes bits into the MPLS Label field. This
is surprising because MPLS appears nowhere in the forwarding plane. Maybe we
shouldn't advertise an MPLS label?

I have seen in some BESS documents that this field is called “Service Label”, not “MPLS label”.
Because MPLS does not exist in VxLAN too, but the same label is used.
Hence, 1) is easy to resolve. It is just a terminology correction that makes sense in principle for all BESS documents.
Eduard
From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Warren Kumari
Sent: Thursday, February 17, 2022 4:37 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] [Last-Call] Intdir telechat review of draft-ietf-bess-srv6-services-10

Major issues:

W