[Lsr] Benjamin Kaduk's No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-23: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-ospfv3-segment-routing-extensions-23: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ -- COMMENT: -- Thank you for addressing my Discuss point! [Original COMMENT section preserved unchanged below] Section 1 Is there a start of the separate document that covers SR with the IPv6 data plane that we could reference from here? Section 5 In some cases it is useful to advertise attributes for a range of prefixes. The Segment Routing Mapping Server, which is described in [I-D.ietf-spring-segment-routing-ldp-interop], is an example of where a single advertisement is needed to advertise SIDs for multiple prefixes from a contiguous address range. I note that the referenced document does not use the word "range" to describe the prefix being assigned multiple SIDs; it might be helpful to say a few more words about how the range of prefixes gets mapped to what is discussed in the linked document. I'm also not entirely sure how to construct the prefix range just given this format description. Suppose I have an IPv4 prefix of 18.18/16 and a range size of 4; my prefix length is 16 and the address prefix is encoded as 0x12012. Am I then representing the four prefixes 18.18/16, 18.19/16, 18.20/16, and 18.21/16? Or am I constrained to be a subset of 18.18/18 (in which case I don't know what the actual distinct prefixes would be)? The examples in Section 6 suggests the former, but I would suggest stating this explictly, here. Section 6 Should there be any discussion of the historical or future reasons why V and L are separate flag bits, given that the only legal combinations are currently 00 and 11, i.e., fully redundant? It may not be necessary to expand ASBR on first usage here, since it's in the terminology section (and marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt). If the NP-Flag is not set, then any upstream neighbor of the Prefix- SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop popping mechanism used in the MPLS dataplane. If the NP-flag is not set, then the received E-flag is ignored. Is it going to be clear that "pop" only applies when this Prefix-SID is the outermost label? (Or am I super-confused about how this is supposed to work?) A similar consideration may apply to the discussion of the NP flag as well. Also some redundantly expanded ABR and ASBR here as well. This is useful, e.g., when the originator of the Prefix- SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. Are we still supposed to call these the EXP bits after RFC 5462? (I had to look up what they were; not sure if this means that we should put a reference in for them or not, given that I'm not a practitioner here.) When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on reception. Do I understand this correctly that this is because the mapping server may not know the needs of the individual routers, and if the routers had specific needs they should advertise the SIDs directly (which would take precedence over the mapping server's advertisement)? If so, given the following discussion, I wouldn't suggest adding any extra text about it, but I do want to make sure I'm understanding it properly. When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV, then the value advertised in the Prefix SID Sub-TLV is interpreted as a starting SID/Label value. Am I remembering correctly that Prefix-SID can appear multiple times within OSPFv3 Extended Prefix Range? Then each Prefix-SID would be indicating a distinct range but adhering to the same parameters of the range that are indicated in the Extended Prefix Range TLV? This seems a little weird on the face of it (as opposed to a single Prefix-SID sub-TLV per Extended Prefix Range), but maybe there's a use case that I'm missing on first glance. Section 7.1 (Probably off-topic: what's the use case for assigning the same Adj-SID to different adjacencies?) Section 7.2 Perhaps add DR to the terminology section (or expand on first usage)? Section 8.1 When a Prefix-SID is advertised by the Mapping Server, which is indicated by the M-flag in the Prefix-SID Sub-TLV (Section 6), the route
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
On Thu, Jan 10, 2019 at 4:42 AM Acee Lindem (acee) wrote:
> Hi Andy,
>
> On 1/10/19, 7:38 AM, "Andy Bierman" wrote:
>
> On Thu, Jan 10, 2019 at 12:34 AM
> wrote:
>
> > Hi Andy,
> >
> >
> >
> > What I’m still not catching is the difference you make between
> having a
> > description statement telling :” A server MUST accept a string up to
> 64
> > characters in length” and a type string with length “0..64” ?
> >
> > There is probably something that I’m missing here.
> >
> >
> >
>
> A server MAY accept a string longer than 64 characters.
> A range 0..64 means a server MUST NOT accept a string longer than 64
> Characters
>
> I don't think we should set the string range unless the range in specified
> in the protocol RFCs. In some cases, it may be beneficial to provide
> guidance in the description. I believe this is similar to Juergen's
> position.
>
>
Agreed -- that is a good guideline for protocol related strings.
But what about admin strings?
NETCONF/YANG does not have a data type like SnmpAdminString
(which has a range of 0..255 octets)
Some of us implement servers using the theory that the NMS knows
what it's doing and servers do what they are told. So if the client
configured a 1M byte admin string the server would try to accept it instead
of putting an arbitrary limit (because there is no YANG limit).
I prefer the SnmpAdminString approach because the client knows what
every compliant server will accept. But YANG models just use plain string
and only regression test tools ask for 1M byte admin strings. IMO, this has
not been
a problem in real deployments. We should continue to use plain "string" for
admin strings.
Thanks,
> Acee
>
Andy
>
>
>
> > Brgds,
> >
> >
> >
>
>
> Andy
>
>
> > *From:* Andy Bierman [mailto:a...@yumaworks.com]
> > *Sent:* Wednesday, January 09, 2019 18:06
> > *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> > Ebben Aries; yang-doct...@ietf.org;
> > draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> > draft-ietf-isis-yang-is-is-cfg-29
> >
> >
> >
> > Hi,
> >
> >
> >
> > I agree with Juergen.
> >
> > The protocol has a "too-big" error is the server will not accept a
> big
> > string.
> >
> > There should not be a false choice between an arbitrary maximum and
> > "terabytes".
> >
> >
> >
> > You cannot use a range-stmt to specify the minimum required length
> that
> > must be supported.
> >
> > length "3..max" does not allow strings of length 0 - 2.
> >
> >
> >
> > The description-stmt can have "A server MUST accept a string up to 64
> > characters in length"
> >
> > which lets the client choose a length from 0 to 64, and this will
> work on
> > all server implementations.
> >
> >
> >
> > Andy
> >
> >
> >
> >
> >
> > On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> > j.schoenwael...@jacobs-university.de> wrote:
> >
> > Hi,
> >
> > please see my other email about the distinction I make between a hard
> > length restriction and the minimum length expected to be supported.
> I
> > wonder how you can sensibly pick a limit for things like
> non-best-reason:
> >
> > leaf non-best-reason {
> > type string;
> > description
> > "Information field to describe why the alternate
> > is not best.";
> > }
> >
> > You are simply creating an arbitrary restriction. And humble server
> is
> > not likely to send you an jpg image (and a bogus server will do so
> > anyway). (There are other similar objects.)
> >
> > Since I am searching for 'type string', I wonder whether these are
> > clear enough definitions.
> >
> > leaf prefix {
> > type string;
> > description
> > "Protected prefix.";
> > }
> > leaf alternate {
> > type string;
> > description
> > "Alternate nexthop for the prefix.";
> > }
> >
> > What is the (canonical) format of the allowed values? (There are
> more of
> > these.)
> >
> > /js
> >
> > On Wed, Jan 09, 2019 at 12:52:07PM +,
> stephane.litkow...@orange.com
> > wrote:
> > > Hi Tom,
> > >
> > > If you agree, I will set a length restriction on each string (ops
> and
> > cfg). It looks clearer for me rather than setting it in the
> description.
> > >
> > > For the references, I'm working on it.
> > >
> > > Brgds,
> > >
> > >
> > > -Original Message-
> > > From: tom petch [mailto:ie...@btconnect.com]
> > > Sent: Wednesday, January
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
Hi Andy,
On 1/10/19, 7:38 AM, "Andy Bierman" wrote:
On Thu, Jan 10, 2019 at 12:34 AM wrote:
> Hi Andy,
>
>
>
> What I’m still not catching is the difference you make between having a
> description statement telling :” A server MUST accept a string up to 64
> characters in length” and a type string with length “0..64” ?
>
> There is probably something that I’m missing here.
>
>
>
A server MAY accept a string longer than 64 characters.
A range 0..64 means a server MUST NOT accept a string longer than 64
Characters
I don't think we should set the string range unless the range in specified in
the protocol RFCs. In some cases, it may be beneficial to provide guidance in
the description. I believe this is similar to Juergen's position.
Thanks,
Acee
> Brgds,
>
>
>
Andy
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Wednesday, January 09, 2019 18:06
> *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
>
>
> Hi,
>
>
>
> I agree with Juergen.
>
> The protocol has a "too-big" error is the server will not accept a big
> string.
>
> There should not be a false choice between an arbitrary maximum and
> "terabytes".
>
>
>
> You cannot use a range-stmt to specify the minimum required length that
> must be supported.
>
> length "3..max" does not allow strings of length 0 - 2.
>
>
>
> The description-stmt can have "A server MUST accept a string up to 64
> characters in length"
>
> which lets the client choose a length from 0 to 64, and this will work on
> all server implementations.
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> Hi,
>
> please see my other email about the distinction I make between a hard
> length restriction and the minimum length expected to be supported. I
> wonder how you can sensibly pick a limit for things like non-best-reason:
>
> leaf non-best-reason {
> type string;
> description
> "Information field to describe why the alternate
> is not best.";
> }
>
> You are simply creating an arbitrary restriction. And humble server is
> not likely to send you an jpg image (and a bogus server will do so
> anyway). (There are other similar objects.)
>
> Since I am searching for 'type string', I wonder whether these are
> clear enough definitions.
>
> leaf prefix {
> type string;
> description
> "Protected prefix.";
> }
> leaf alternate {
> type string;
> description
> "Alternate nexthop for the prefix.";
> }
>
> What is the (canonical) format of the allowed values? (There are more of
> these.)
>
> /js
>
> On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com
> wrote:
> > Hi Tom,
> >
> > If you agree, I will set a length restriction on each string (ops and
> cfg). It looks clearer for me rather than setting it in the description.
> >
> > For the references, I'm working on it.
> >
> > Brgds,
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Wednesday, January 09, 2019 12:38
> > To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> >
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage
Re: [Lsr] [yang-doctors] Yangdoctors last call review of draft-ietf-isis-yang-is-is-cfg-29
On Thu, Jan 10, 2019 at 12:34 AM wrote:
> Hi Andy,
>
>
>
> What I’m still not catching is the difference you make between having a
> description statement telling :” A server MUST accept a string up to 64
> characters in length” and a type string with length “0..64” ?
>
> There is probably something that I’m missing here.
>
>
>
A server MAY accept a string longer than 64 characters.
A range 0..64 means a server MUST NOT accept a string longer than 64
characters
> Brgds,
>
>
>
Andy
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Wednesday, January 09, 2019 18:06
> *To:* Juergen Schoenwaelder; LITKOWSKI Stephane OBS/OINIS; tom petch;
> Ebben Aries; yang-doct...@ietf.org;
> draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> *Subject:* Re: [yang-doctors] [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
>
>
>
> Hi,
>
>
>
> I agree with Juergen.
>
> The protocol has a "too-big" error is the server will not accept a big
> string.
>
> There should not be a false choice between an arbitrary maximum and
> "terabytes".
>
>
>
> You cannot use a range-stmt to specify the minimum required length that
> must be supported.
>
> length "3..max" does not allow strings of length 0 - 2.
>
>
>
> The description-stmt can have "A server MUST accept a string up to 64
> characters in length"
>
> which lets the client choose a length from 0 to 64, and this will work on
> all server implementations.
>
>
>
> Andy
>
>
>
>
>
> On Wed, Jan 9, 2019 at 5:10 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> Hi,
>
> please see my other email about the distinction I make between a hard
> length restriction and the minimum length expected to be supported. I
> wonder how you can sensibly pick a limit for things like non-best-reason:
>
> leaf non-best-reason {
> type string;
> description
> "Information field to describe why the alternate
> is not best.";
> }
>
> You are simply creating an arbitrary restriction. And humble server is
> not likely to send you an jpg image (and a bogus server will do so
> anyway). (There are other similar objects.)
>
> Since I am searching for 'type string', I wonder whether these are
> clear enough definitions.
>
> leaf prefix {
> type string;
> description
> "Protected prefix.";
> }
> leaf alternate {
> type string;
> description
> "Alternate nexthop for the prefix.";
> }
>
> What is the (canonical) format of the allowed values? (There are more of
> these.)
>
> /js
>
> On Wed, Jan 09, 2019 at 12:52:07PM +, stephane.litkow...@orange.com
> wrote:
> > Hi Tom,
> >
> > If you agree, I will set a length restriction on each string (ops and
> cfg). It looks clearer for me rather than setting it in the description.
> >
> > For the references, I'm working on it.
> >
> > Brgds,
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Wednesday, January 09, 2019 12:38
> > To: LITKOWSKI Stephane OBS/OINIS; Ebben Aries; yang-doct...@ietf.org
> > Cc: draft-ietf-isis-yang-isis-cfg@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Yangdoctors last call review of
> draft-ietf-isis-yang-is-is-cfg-29
> >
> > Stephane
> >
> > Thanks for persisting.
> >
> > On string lengths, I take your point about no user input to Operational
> > State; there, my concern is more about giving guidance to implementors
> > as to what they should cater for - as I said, this has been a topic of
> > lively discussion in other WG. Even before that, whenever I see a
> > string, I think is there an implicit length restriction and if not,
> > should there be an explicit one which, as Juergen suggested, could be in
> > the description clause. My experience is that those working with
> > networks think about size, about length; those coming from applications
> > tend to think 'What is a few terabytes between friends?' and are unaware
> > that sizes that may be commonplace in servers and associated storage can
> > create difficulties over a network. Whatever, I leave this one up to
> > you.
> >
> > On references, I would like a change; you say this information is in the
> > base ISO spec. Well, yes, to me that means that it should be a
> > Normative Reference. I could not understand the description of e.g.
> > 'i/e' and needed to look it up but seemingly cannot do so with the
> > listed references of the I-D. Note that RFC such as RFC5305 and RFC6119
> > do reference International Standard 10589 and I think that this one
> > should too, perhaps in s.2.7 and s.5.
> >
> > Tom Petch
> >
> > - Original Message -
> > From:
> > Sent: Wednesday, January 09, 2019 9:18 AM
> >
> > Hi Tom,
> >
> > Please find inline answers.
> >
> >
> > -Original Message-
> > From: tom petch [mailto:ie...@btconnect.com]
> > Sent: Tuesday, January 08, 2019 18:45
> >
> > Ok.
