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
From: Ketan Talaulikar <ketant.ietf@xxxxxxxxx>
Sent: Tuesday, February 15, 2022 3:49 AM
To: Ron Bonica <rbonica@xxxxxxxxxxx>
Cc: int-dir@xxxxxxxx; BESS <bess@xxxxxxxx>; draft-ietf-bess-srv6-services.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: Intdir telechat review of draft-ietf-bess-srv6-services-10
[External Email. Be cautious of content]
Hi Ron,
Thanks for your review and please check inline below for responses.
On Mon, Feb 14, 2022 at 10:49 PM Ron Bonica via Datatracker <noreply@xxxxxxxx> 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://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?
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.
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
KT> I am, personally, not in favor of using the term "legacy" in this case.
It seems that this isn't backwards compatible unless either:
- the SHOULD becomes a MUST
- the mechanism is described in this document
KT> Ack. We can change the SHOULD to MUST.
3) I concur with Warren Kumari's DISCUSS
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
