Date: Wed, 6 May 2020 23:30:03 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, Benjamin Kaduk
 <kaduk@mit.edu>
Cc: Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, 
 draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, The IESG
 <iesg@ietf.org>, idr@ietf.org
Message-ID: <592e681f-eadc-4d74-9825-2e221a06d523@Spark>
In-Reply-To: <20200506213327.GK27494@kduck.mit.edu>
References: <158862918074.23288.8494237048042781894@ietfa.amsl.com>
 <7534cbdd-a370-4d40-b49e-a30158d46a44@Spark>
 <20200506175602.GG27494@kduck.mit.edu>
 <CAMMESsxLoyee62H=BEjM1qEwU+kC1pZHj_GnyBV0whTTrnFN+A@mail.gmail.com>
 <20200506213327.GK27494@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5eb3aaf0_38a5d054_2480"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/2oFgqGEtzrd7Jifo7Zhue_qHHtU>
Subject: Re: [Idr] Benjamin Kaduk's No Objection on
 draft-ietf-idr-bgp-ls-segment-routing-msd-17: (with COMMENT)
Precedence: list

--5eb3aaf0_38a5d054_2480
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Ben,

It seemed that having in R=46C8491 and R=46C8476 the following text:
=22When Link MSD is present for a given MSD-Type, the value of the Link M=
SD MUST take precedence over the Node MSD. If a Link MSD-Type is not sign=
aled, but the Node MSD-Type is, then the Node MSD-Type value MUST be cons=
idered to be the MSD value for that link.=E2=80=9D, as well as placing =22=
Node MSD is the smallest MSD supported=E2=80=9D specifically in the Node =
MSD section,
e.g. - applicable in context of Node MSD only, provided clear guidance to=
 the implementors (which is the case).
There=E2=80=99s a number of implementations that implement the behavior a=
s the above, the authors of R=46C8491 and R=46C8476 have not received any=
 questions or complains wrt inconsistency.

I really appreciate your comments, I believe we have a different intepret=
ation of the text.

Many thanks=21

Cheers,
Jeff
On May 6, 2020, 2:33 PM -0700, Benjamin Kaduk <kaduk=40mit.edu>, wrote:
> On Wed, May 06, 2020 at 02:22:45PM -0700, Alvaro Retana wrote:
> > On May 6, 2020 at 1:56:07 PM, Benjamin Kaduk wrote:
> >
> >
> > Ben:
> >
> > Hi=21
> >
> > ...
> > > It sounds like you are intending this to work the way that I was ho=
ping it
> > > would work, which is reassuring. That said (and this relates to a l=
ater
> > > comment as well), I think we may want to double-check the wording i=
n one
> > > spot: in Section 3 we define the =22Node MSD is the smallest MSD su=
pported by
> > > the node on the set of interfaces configured for use.=22 This defin=
ition
> > > seems to disallow advertising a Node MSD that is larger than any sp=
ecific
> > > Link MSD for that node. My question here was about whether a receiv=
ing
> > > node was expected to enforce this (surprising) aspect of the defini=
tion.
> > > If, instead, the definition should be changed to say only that the =
Node MSD
> > > is the MSD to be used for interfaces on this node in the absence of=
 an
> > > interface-specific value, then there is no longer any enforcement n=
eeded.
> >
> > =C2=A75 does say this: =22When Link MSD is present for a given MSD-ty=
pe, the
> > value of the Link MSD MUST take precedence over the Node MSD.=22
> >
> > Is that what you're looking for.
>
> That's what I expect, yes.
> But right now the document seems to be inconsistent, as the Node MSD is=

> claimed to be =22the smallest MSD supported=22 but can be other values.=

>
> > Keep in mind that the expectation of BGP-LS is to simply transport
> > information; the rules around that information and how the consumer
> > should process it come form the IGP documents. =C2=A0IOW, in this cas=
e
> > we're bound by what those published documents already say (see R=46C8=
491
> > and R=46C8476).
>
> So the published documents are also inconsistent=3F
>
> It still looks like we are defining usage of a field that contradicts w=
hat
> that field is defined to carry. I am not sure whether the contradiction=
 is
> across documents, within multiple documents, or only within this curren=
t
> document.
>
> If we're locked into the already-defined semantics that's fine (albeit
> unfortunate), but we shouldn't then claim that it's allowed to violate =
the
> already-defined semantics.
>
> -Ben

--5eb3aaf0_38a5d054_2480
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi Ben,<br />
<br />
It seemed that having in R=46C8491 and R=46C8476 the following text:<br /=
>
=22When Link MSD is present for a given MSD-Type, the value of the Link M=
SD MUST take precedence over the Node MSD. If a Link MSD-Type is not sign=
aled, but the Node MSD-Type is, then the Node MSD-Type value MUST be cons=
idered to be the MSD value for that link.=E2=80=9D, as well as placing =22=
Node MSD is the smallest MSD supported=E2=80=9D specifically in the Node =
MSD section,<br />
e.g. - applicable in context of Node MSD only, provided clear guidance to=
 the implementors (which is the case).<br />
There=E2=80=99s a number of implementations that implement the behavior a=
s the above, the authors of R=46C8491 and R=46C8476 have not received any=
 questions or complains wrt inconsistency.<br />
<br />
I really appreciate your comments, I believe we have a different intepret=
ation of the text.<br />
<br />
Many thanks=21</div>
</div>
<div name=3D=22messageSignatureSection=22><br />
<div class=3D=22match=46ont=22>Cheers,
<div>Jeff</div>
</div>
</div>
<div name=3D=22messageReplySection=22>On May 6, 2020, 2:33 PM -0700, Benj=
amin Kaduk &lt;kaduk=40mit.edu&gt;, wrote:<br />
<blockquote type=3D=22cite=22 style=3D=22border-left-color: grey; border-=
left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left:=
 10px;=22>On Wed, May 06, 2020 at 02:22:45PM -0700, Alvaro Retana wrote:<=
br />
<blockquote type=3D=22cite=22>On May 6, 2020 at 1:56:07 PM, Benjamin Kadu=
k wrote:<br />
<br />
<br />
Ben:<br />
<br />
Hi=21<br />
<br />
...<br />
<blockquote type=3D=22cite=22>It sounds like you are intending this to wo=
rk the way that I was hoping it<br />
would work, which is reassuring. That said (and this relates to a later<b=
r />
comment as well), I think we may want to double-check the wording in one<=
br />
spot: in Section 3 we define the =22Node MSD is the smallest MSD supporte=
d by<br />
the node on the set of interfaces configured for use.=22 This definition<=
br />
seems to disallow advertising a Node MSD that is larger than any specific=
<br />
Link MSD for that node. My question here was about whether a receiving<br=
 />
node was expected to enforce this (surprising) aspect of the definition.<=
br />
If, instead, the definition should be changed to say only that the Node M=
SD<br />
is the MSD to be used for interfaces on this node in the absence of an<br=
 />
interface-specific value, then there is no longer any enforcement needed.=
<br /></blockquote>
<br />
=C2=A75 does say this: =22When Link MSD is present for a given MSD-type, =
the<br />
value of the Link MSD MUST take precedence over the Node MSD.=22<br />
<br />
Is that what you're looking for.<br /></blockquote>
<br />
That's what I expect, yes.<br />
But right now the document seems to be inconsistent, as the Node MSD is<b=
r />
claimed to be =22the smallest MSD supported=22 but can be other values.<b=
r />
<br />
<blockquote type=3D=22cite=22>Keep in mind that the expectation of BGP-LS=
 is to simply transport<br />
information; the rules around that information and how the consumer<br />=

should process it come form the IGP documents. &=23160;IOW, in this case<=
br />
we're bound by what those published documents already say (see R=46C8491<=
br />
and R=46C8476).<br /></blockquote>
<br />
So the published documents are also inconsistent=3F<br />
<br />
It still looks like we are defining usage of a field that contradicts wha=
t<br />
that field is defined to carry. I am not sure whether the contradiction i=
s<br />
across documents, within multiple documents, or only within this current<=
br />
document.<br />
<br />
If we're locked into the already-defined semantics that's fine (albeit<br=
 />
unfortunate), but we shouldn't then claim that it's allowed to violate th=
e<br />
already-defined semantics.<br />
<br />
-Ben<br /></blockquote>
</div>
</body>
</html>

--5eb3aaf0_38a5d054_2480--