Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: (with COMMENT)

[Rob Wilton (rwilton)]

> -Original Message-
> From: Peter Psenak 
> Sent: 05 June 2023 12:46
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-ip-flexa...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
> acee.i...@gmail.com; a...@cisco.com
> Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: 
> (with
> COMMENT)
> 
> fair comment.
> I will make it clear that algo outside of the flex-algo range MUST be
> ignored and state the same for OSPF.
[Rob Wilton (rwilton)] 

Sounds good.  Thanks.

Rob


> 
> thanks,
> Peter
> 
> >
> > Regards,
> > Rob
> >
> >
> >
> >

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-rfc8920bis-04: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Les,

My bad, I missed that paragraph when reviewing diff - despite explicitly 
looking for it.

Yes, what you have in -04 looks good to me.

Regards,
Rob


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: 25 May 2023 15:37
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-rfc8920...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
> cho...@chopps.org
> Subject: RE: Robert Wilton's No Objection on draft-ietf-lsr-rfc8920bis-04:
> (with COMMENT)
> 
> Rob -
> 
> Thanx for the review.
> Yes, the update to the Introduction was done in response to Warren's
> comment. Some offline discussion resulted in adding this to the Introduction
> rather than the Abstract.
> 
>Les
> 
> > -Original Message-
> > From: Robert Wilton via Datatracker 
> > Sent: Thursday, May 25, 2023 1:13 AM
> > To: The IESG 
> > Cc: draft-ietf-lsr-rfc8920...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
> > cho...@chopps.org; cho...@chopps.org
> > Subject: Robert Wilton's No Objection on draft-ietf-lsr-rfc8920bis-04: (with
> > COMMENT)
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-lsr-rfc8920bis-04: 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/about/groups/iesg/statements/handling-ballot-
> > positions/
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-rfc8920bis/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks for this update.
> >
> > I reviewed the diff for -04, and then saw Warren's ballot comment against -
> 02.
> > I don't know if the intent is that Warren's comment has already been
> > addressed,
> > but I would give a +1 to a sentence in the introduction briefly explaining
> the
> > update and forward referencing section 15.
> >
> > Regards,
> > Rob
> >
> >

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Hi Dhruv,

Sorry for being slow.  Yes, these changes look fine.  Thanks for accommodating 
my concerns.  I’ve cleared my discuss.

Regards,
Rob


From: iesg  On Behalf Of Dhruv Dhody
Sent: 05 October 2022 14:03
To: Rob Wilton (rwilton) 
Cc: The IESG ; 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; Acee Lindem (acee) ; p...@ietf.org
Subject: Re: Robert Wilton's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

Hi Robert,

Thanks for your review. The working copy is at -

TXT - 
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt
DIFF - 
https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt

On Tue, Oct 4, 2022 at 10:17 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-pce-discovery-security-support-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/



--
DISCUSS:
--

Hi,

Sorry for the discuss, but I find a couple of specification aspects of this
draft to be unclear enough that I think that they probably warrant a discuss,
hopefully easy to explain or resolve:

In section 3.2, it wasn't clear to me exactly where I find what the Key-Id is.
I suspect that this is probably referring to "KeyId" in rfc5925.  If so, I
think that would be emphasizing.

Dhruv: Made this change -

   The KEY-ID sub-TLV specifies an identifier that can be used by the
   PCC to identify the TCP-AO key [RFC5925] (referred to as KeyID).



In section 3.3, it wasn't clear to me what the Key chain name is, or what
exactly it refers to.  Is this referring to a local key-chain name installed in
a YANG Keystore (given that there is a reference to RFC8177) or something else.
 Either way, I think that expanding on the description here would probably be
very beneficial.

Dhruv: Here is the updated text -

   The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used
   by the PCC to identify the keychain.  The keychain name could be
   manually configured via CLI or installed in the YANG datastore (see
   [RFC8177]) at the PCC.



--
COMMENT:
--

One minor comment.  I noted that the description of the Key-Id slightly
differed for the OSPF encoding vs ISIS encoding and I wanted to check that the
difference was intentional.

Dhruv: Yes, this is intentional as padding rules are different between OSPF and 
IS-IS. See this email - 
https://mailarchive.ietf.org/arch/msg/lsr/T9OLjPkjcvOViHXOZGCJYsi8OJ4/

Thanks!
Dhruv


Regards,
Rob


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Ketan,

I’ve cleared my discuss.

Regards,
Rob


From: iesg  On Behalf Of Ketan Talaulikar
Sent: 10 October 2022 14:34
To: Rob Wilton (rwilton) 
Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 

Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Please check inline below for responses with KT2 to the open comments.

We have also posted an update with the changes as discussed below: 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12

On Mon, Oct 10, 2022 at 6:18 PM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Ketan,

Please see inline …

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: 06 October 2022 12:58
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>; 
draft-ietf-lsr-ospf-reverse-met...@ietf.org<mailto:draft-ietf-lsr-ospf-reverse-met...@ietf.org>;
 lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
lsr@ietf.org<mailto:lsr@ietf.org>; cho...@chopps.org<mailto:cho...@chopps.org>; 
Acee Lindem (acee) mailto:a...@cisco.com>>
Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Thanks for your review and comments/suggestions. Please check inline below for 
responses.

Will update these changes (and further changes, if required) in the next 
version once we conclude.

On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-09: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
DISCUSS:
--

Thanks for this document.

I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
ballot comments it seems to be some what closely related, but I am also
balloting discuss because I find the operational guidelines to be unclear.

(1) p 8, sec 7.  Operational Guidelines

   Implementations MUST NOT signal reverse metric to neighbors by
   default and MUST provide a configuration option to enable the
   signaling of reverse metric on specific links.  Implementations
   SHOULD NOT accept the RM from its neighbors by default and SHOULD
   provide a configuration option to enable the acceptance of the RM
   from neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I'm not really sure that I properly understand how this feature works from a
manageability perspective.  Particularly for your first use case, when
considering that the proposal is for per link configuration for the acceptance
of RM from neighbours.  This would seem to suggest that before you can make use
of reverse-metric you have to already have determined the links on the affected
devices to then configure them to accept the reverse-metrics, at which point,
doesn't this partially defeat the use case?

KT> If the operator is using this feature, then it needs to be enabled first. 
This is a one-time/initial config.

Sure.   Presumably you mean both on the devices that will transmit the RM and 
also devices that will receive them?

KT2> Correct.


Or is the main goal to simplify
the coordination of changing the metric at both ends of the link at the same
time?

KT> Correct. The advertisement of reverse metric is applied/triggered on the 
sending side on-need basis.


Or is the intention that during the maintenance window the operators would
enable the "allow receipt of reverse-metrics" on all links within, say, an
area?  If so, would hierarchical device and area specific configuration be more
appropriate?  E.g., allow it to be enabled/disbaled on individual links, but
also allow more coarse grained configuration.

KT> I would expect the feature enablement (specifically the receiving part) to 
be on multiple hierarchical levels (instance/area/link). The RM value config 
for sending is on the link, but for some use cases, it would perhaps be also 
hierarchical.

Okay, it is only the feature enablement that I am concerned with, with my 
reading of the text implying that the feature to accept RM values must (perhaps 
only) be configurable on a per interface basis.

KT2> The "only" part is not there. The point was that the operator nee

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Ketan,

Please see inline …

From: Ketan Talaulikar 
Sent: 06 October 2022 12:58
To: Rob Wilton (rwilton) 
Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; 
lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 

Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: 
(with DISCUSS)

Hi Rob,

Thanks for your review and comments/suggestions. Please check inline below for 
responses.

Will update these changes (and further changes, if required) in the next 
version once we conclude.

On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-reverse-metric-09: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/



--
DISCUSS:
--

Thanks for this document.

I support Alvaro's discuss.  Having read Alvaro's discuss after writing my
ballot comments it seems to be some what closely related, but I am also
balloting discuss because I find the operational guidelines to be unclear.

(1) p 8, sec 7.  Operational Guidelines

   Implementations MUST NOT signal reverse metric to neighbors by
   default and MUST provide a configuration option to enable the
   signaling of reverse metric on specific links.  Implementations
   SHOULD NOT accept the RM from its neighbors by default and SHOULD
   provide a configuration option to enable the acceptance of the RM
   from neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I'm not really sure that I properly understand how this feature works from a
manageability perspective.  Particularly for your first use case, when
considering that the proposal is for per link configuration for the acceptance
of RM from neighbours.  This would seem to suggest that before you can make use
of reverse-metric you have to already have determined the links on the affected
devices to then configure them to accept the reverse-metrics, at which point,
doesn't this partially defeat the use case?

KT> If the operator is using this feature, then it needs to be enabled first. 
This is a one-time/initial config.

Sure.   Presumably you mean both on the devices that will transmit the RM and 
also devices that will receive them?

Or is the main goal to simplify
the coordination of changing the metric at both ends of the link at the same
time?

KT> Correct. The advertisement of reverse metric is applied/triggered on the 
sending side on-need basis.


Or is the intention that during the maintenance window the operators would
enable the "allow receipt of reverse-metrics" on all links within, say, an
area?  If so, would hierarchical device and area specific configuration be more
appropriate?  E.g., allow it to be enabled/disbaled on individual links, but
also allow more coarse grained configuration.

KT> I would expect the feature enablement (specifically the receiving part) to 
be on multiple hierarchical levels (instance/area/link). The RM value config 
for sending is on the link, but for some use cases, it would perhaps be also 
hierarchical.

Okay, it is only the feature enablement that I am concerned with, with my 
reading of the text implying that the feature to accept RM values must (perhaps 
only) be configurable on a per interface basis.

Specifically, it is this text that I have an issue with:

   Implementations MUST
   NOT accept the RM from its neighbors by default and MUST provide a
   configuration option to enable the acceptance of the RM from
   neighbors on specific links.  This is to safeguard against
   inadvertent use of RM.

I think that this text should be changed to explicitly acknowledge or allow 
hierarchical configuration.  E.g., something along the lines of:


 Implementations MUST NOT accept the RM from neighbors by default.

  Implementations MAY provide configuration to accept the RM globally on the 
device, or per area, but
  Implementations MUST support configuration to enable/disable acceptance of 
the RM from neighbors on specific links.
  This is to safeguard against inadvertent use of RM.






Not as an update for this document, but I am assuming that the LSR working
group with eventually update or augment the OSPF YANG module with standard
configuration to support this feature.

KT> Ack. Will include the same reference and text that we have discussed for 
the OSPF L2

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Peter,

Thanks.  I think that John has already followed up and flagged the IPR, so 
probably nothing more that needs to be done from your side on that.

Thanks,
Rob


> -Original Message-
> From: Peter Psenak 
> Sent: 06 October 2022 12:33
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-flex-a...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
> Christian
> Hopps ; Acee Lindem (acee) ;
> j...@juniper.net
> Subject: Re: [Lsr] Robert Wilton's No Objection on 
> draft-ietf-lsr-flex-algo-24:
> (with COMMENT)
> 
> Hi Robert,
> 
> please see inline:
> 
> 
> On 05/10/2022 18:12, Robert Wilton via Datatracker wrote:
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-lsr-flex-algo-24: 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/about/groups/iesg/statements/handling-ballot-
> positions/
> > for more information about how to handle DISCUSS and COMMENT
> positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Hi,
> >
> > Thanks for this document.  I don't really have much to say.
> >
> > I was slightly surprised by the IPR declaration 3910, which unless I am
> > misreading it, seems to be asserting possible IPR on the BCP 14 text (i.e.,
> > section 2 of revision 03)!  Perhaps worth flagging to see if an update to 
> > the
> > IPR declaration is needed?
> 
> will try to get that fixed, it's a mistake likely.
> 
> >
> > One minor nit:
> >
> > (1) p 3, sec 1.  Introduction
> >
> > This document also specifies a way for a router to use IGPs to
> > associate one or more Segment Routing with the MPLS Data Plane (SR-
> > MPLS) Prefix-SIDs [RFC8660], or Segment Routing over IPv6 (SRv6)
> > locators [RFC8986] with a particular Flex-Algorithm.
> >
> > I found this sentence clunky to parse/understand - possibly putting quotes
> > around "Segment Routing with the MPLS Data Plane" and "Segment
> Routing over
> > IPv6 (SRv6) locators" would help.
> 
> done.
> 
> thanks,
> Peter
> >
> > Regards,
> > Rob
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee, Ketan,

One other alternative could be to add an Informative reference to the base OSPF 
YANG module (that is about to be an RFC), and indicate that the configuration 
is expected to be an update or augmentation to that base OSPF YANG module?

Is there somewhere for these new config knobs are being tracked - so that they 
don’t get forgotten?

Thanks,
Rob



From: Acee Lindem (acee) 
Sent: 04 October 2022 16:13
To: Ketan Talaulikar 
Cc: Rob Wilton (rwilton) ; The IESG ; 
draft-ietf-lsr-ospf-l2bund...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
cho...@chopps.org
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Ketan,

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Tuesday, October 4, 2022 at 10:44 AM
To: Acee Lindem mailto:a...@cisco.com>>
Cc: "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>, The 
IESG mailto:i...@ietf.org>>, 
"draft-ietf-lsr-ospf-l2bund...@ietf.org<mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>>,
 "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Christian Hopps 
mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Resent-Date: Tuesday, October 4, 2022 at 10:44 AM

Hi Acee,

Thanks for your quick response.

My question was : Can we put an informative reference to  
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/  (of 
which you are co-author) in the OSPF L2 Bundles draft?

This assumes that an upcoming version of this augmentation-v1 draft will cover 
the configuration/enablement of this feature.

We also would need to update the Link State Database for the advertisement of 
the individual links. I think you can just say a future YANG draft as the 
reference Is not mandatory.

Thanks,
Acee



Thanks.
Ketan


On Tue, Oct 4, 2022 at 8:07 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Ketan,

See inlie.

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Tuesday, October 4, 2022 at 10:23 AM
To: "Rob Wilton (rwilton)" mailto:rwil...@cisco.com>>
Cc: The IESG mailto:i...@ietf.org>>, 
"draft-ietf-lsr-ospf-l2bund...@ietf.org<mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>"
 
mailto:draft-ietf-lsr-ospf-l2bund...@ietf.org>>,
 "lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Christian Hopps mailto:cho...@chopps.org>>, Acee Lindem 
mailto:a...@cisco.com>>
Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: 
(with COMMENT)

Hi Rob,

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

The updates as discussed below will be included in the next update.


On Tue, Oct 4, 2022 at 3:14 PM Robert Wilton via Datatracker 
mailto:nore...@ietf.org>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospf-l2bundles-06: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/



--
COMMENT:
--

Hi,

I support Lars's discuss.

I don't really object to publishing this document, although I don't really like
the fact that the LAG member information that is being propagated isn't of any
relevance to OSPF routing itself, and OSPF is being used only as a generic
information propagation mechanism.  However, I acknowledge that horse has
probably bolted long ago.

KT> What we are doing here is adding more information for use in the TE-DB that 
is related to OSPF adjacencies. Originally, Opaque LSAs were introduced in OSPF 
for carrying additional info for TE-DB - even though that info was not really 
consumed by OSPF protocol. I can understand that "the line" may be blurred in 
this respect.


One point that is not clear to me, is the configuration/management of this
feature:  Is the expectation that OSPF implementations that support this

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[Rob Wilton (rwilton)]

Les,

Thanks for accommodating.

Regards,
Rob


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: 21 September 2022 14:32
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> cho...@chopps.org; t...@ietf.org
> Subject: RE: Robert Wilton's No Objection on 
> draft-ietf-lsr-isis-rfc5316bis-04:
> (with COMMENT)
> 
> Rob -
> 
> Inline.
> 
> > -Original Message-
> > From: Rob Wilton (rwilton) 
> > Sent: Wednesday, September 21, 2022 1:32 AM
> > To: Les Ginsberg (ginsberg) ; The IESG
> 
> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> > lsr@ietf.org;
> > cho...@chopps.org; t...@ietf.org
> > Subject: RE: Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-
> 04:
> > (with COMMENT)
> >
> > Hi Les,
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: Les Ginsberg (ginsberg) 
> > > Sent: 21 September 2022 05:49
> > > To: Rob Wilton (rwilton) ; The IESG 
> > > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> > > lsr@ietf.org;
> > > cho...@chopps.org; t...@ietf.org
> > > Subject: RE: Robert Wilton's No Objection on 
> > > draft-ietf-lsr-isis-rfc5316bis-
> > 04:
> > > (with COMMENT)
> > >
> > > Rob -
> > >
> > > Please see inline.
> > >
> > > > -Original Message-
> > > > From: Robert Wilton via Datatracker 
> > > > Sent: Tuesday, September 20, 2022 2:07 AM
> > > > To: The IESG 
> > > > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org;
> > > > cho...@chopps.org; t...@ietf.org; cho...@chopps.org
> > > > Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-
> 04:
> > > > (with COMMENT)
> > > >
> > > > Robert Wilton has entered the following ballot position for
> > > > draft-ietf-lsr-isis-rfc5316bis-04: 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/about/groups/iesg/statements/handling-ballot-
> > > > positions/
> > > > for more information about how to handle DISCUSS and COMMENT
> > > > positions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be found here:
> > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> > > >
> > > >
> > > >
> > > > --
> > > > COMMENT:
> > > > --
> > > >
> > > > I support Alvaro's discuss.
> > > >
> > > [LES:] I have responded to Alvaro - please let me know if my response
> > > addresses your concern.
> >
> > Not really.
> >
> > For this scenario having a SHOULD is okay, but it would then be helpful to
> > describe the exact conditions when that SHOULD isn't effectively a MUST.
> > But personally, I would find it clearer if the constraint was something like
> > MUST be the same as TLV 134 when TLV 134 is also advertised.
> >
> > But I will let Alvaro carry the Discuss.  I.e., if you get agreement from 
> > him
> (as
> > a RTG AD) then that will be sufficient for me as well.
> >
> > >
> > > > I would like to thank Menachem for the OPSDIR review.
> > > >
> > > [LES:] I addressed Menachem's comments in V4 of the draft. Please let
> me
> > > know if those changes are satisfactory.
> >
> > Yes, they look fine, thanks.
> >
> > >
> > > > I also have a few minor nits for the authors to consider:
> > > >
> > > > (1) p 3, sec 2.  Problem Statement
> > > >
> > > >Two methods for determining inter-AS paths are currently being
> > > >discussed.
> > > >
> > > > It was unclear what is meant by this, please clarify.  I.e., Do you mean
> > > > described in this document?  Or there is ongonig discussion in the WG?
> > Or
> > > ...
> > >
> > > [LES

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Les,

Please see inline ...

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: 21 September 2022 05:49
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> lsr@ietf.org;
> cho...@chopps.org; t...@ietf.org
> Subject: RE: Robert Wilton's No Objection on 
> draft-ietf-lsr-isis-rfc5316bis-04:
> (with COMMENT)
> 
> Rob -
> 
> Please see inline.
> 
> > -Original Message-
> > From: Robert Wilton via Datatracker 
> > Sent: Tuesday, September 20, 2022 2:07 AM
> > To: The IESG 
> > Cc: draft-ietf-lsr-isis-rfc5316...@ietf.org; lsr-cha...@ietf.org; 
> > lsr@ietf.org;
> > cho...@chopps.org; t...@ietf.org; cho...@chopps.org
> > Subject: Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04:
> > (with COMMENT)
> >
> > Robert Wilton has entered the following ballot position for
> > draft-ietf-lsr-isis-rfc5316bis-04: 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/about/groups/iesg/statements/handling-ballot-
> > positions/
> > for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I support Alvaro's discuss.
> >
> [LES:] I have responded to Alvaro - please let me know if my response
> addresses your concern.

Not really.

For this scenario having a SHOULD is okay, but it would then be helpful to 
describe the exact conditions when that SHOULD isn't effectively a MUST.  But 
personally, I would find it clearer if the constraint was something like MUST 
be the same as TLV 134 when TLV 134 is also advertised.

But I will let Alvaro carry the Discuss.  I.e., if you get agreement from him 
(as a RTG AD) then that will be sufficient for me as well.

> 
> > I would like to thank Menachem for the OPSDIR review.
> >
> [LES:] I addressed Menachem's comments in V4 of the draft. Please let me
> know if those changes are satisfactory.

Yes, they look fine, thanks.

> 
> > I also have a few minor nits for the authors to consider:
> >
> > (1) p 3, sec 2.  Problem Statement
> >
> >Two methods for determining inter-AS paths are currently being
> >discussed.
> >
> > It was unclear what is meant by this, please clarify.  I.e., Do you mean
> > described in this document?  Or there is ongonig discussion in the WG?  Or
> ...
> 
> [LES:] I am unclear as to what is causing your confusion. The text in Section 
> 2
> states:
> 
> "Two methods for determining inter-AS paths are currently being discussed.
> The per-domain method [RFC5152] determines the path one domain at a
> time. The backward recursive method [RFC5441] uses cooperation between
> PCEs to determine an optimum inter-domain path. The sections that follow
> examine how inter-AS TE link information could be useful in both cases."
> 
> The two methods are explicitly named and an RFC reference provided for
> each. Section 2.2 then discusses the per-domain method in more detail and
> Section 2.3 discusses the backward recursive method in more detail.
> 
> Please help me understand why you find this confusing.

Perhaps it is a difference in interpretation between UK vs US English.  As I 
said in my comment, I naturally read that sentence to mean that there is 
current discussion occurring somewhere (e.g., in a WG), not that the document 
is describing two methods.  I would find this clearer as "Two methods for 
determining inter-AS paths are supported: The per-domain ...", or something 
similar.  But all my ballot comments are just comments are hence you are free 
to ignore it if you wish.

Thanks,
Rob

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Randy,



Thanks for summarizing, but I don't really agree with your categorization for 
(1) or (3).



My interpretation of ip-address and the related v4/v6 types, based on RFC 7950, 
is that implementations MUST allow clients to configure zoned IP addresses to 
be fully complaint with the module definition.  If a server implementation does 
not support zoned ip-addresses then it is expected to use a deviation (e.g., to 
replace the type with ip-address-no-zone) to indicate how it does not conform 
to the model.  I don't see that is being any different than an integer datatype 
with a range "1..255" and the server only supporting the client configuring 
values in the range "1..100".



The "may include a zone index" in the ip-address definitions relates to the 
client when writing a value (or server when returning a value), i.e., they 
don't have to always provide zones for all IP addresses.  They can leave them 
out, and when the zone is left out the "default zone of the device will be 
used".



E.g., considering the RFC 6991 and the IP RIB YANG model,


 typedef ipv6-address {
   type string {
 pattern '...'
   }
   description
"The ipv6-address type represents an IPv6 address in full,
 mixed, shortened, and shortened-mixed notation.  The IPv6
 address may include a zone index, separated by a % sign.

 The zone index is used to disambiguate identical address
 values.  For link-local addresses, the zone index will
 typically be the interface index number or the name of an
 interface.  If the zone index is not present, the default
 zone of the device will be used.



 The canonical format of IPv6 addresses uses the textual

 representation defined in Section 4 of RFC 
5952.  The

 canonical format for the zone index is the numerical

 format as described in Section 11.2 of RFC 
4007.";




 |  |+--rw v6ur:ipv6
 |  |   +--rw v6ur:route* [destination-prefix]
 |  |  +--rw v6ur:destination-prefix
 |  |  |   inet:ipv6-prefix
 |  |  +--rw v6ur:description?  string
 |  |  +--rw v6ur:next-hop
 |  | +--rw (v6ur:next-hop-options)
 |  |+--:(v6ur:simple-next-hop)
 |  ||  +--rw v6ur:outgoing-interface?
 |  ||  |   if:interface-ref
 |  ||  +--rw v6ur:next-hop-address?
 |  ||  inet:ipv6-address



So, considering the model above, if a link local IP address was provided as the 
next-hop-address without a zone, then according to the type definition, that 
link-local IP address is associated with the default zone of the device, not 
the "outgoing interface" for the next hop!  If a zone is returned with a 
link-local address (e.g., for a get request) then my expectation is that 
servers return the data using the "interface index number" (since that is the 
canonical form, this should be returned even if it was configured using an 
interface name to identify the zone).  Further, as far as I can tell, 
"interface index number" isn't really well specified in a YANG management API 
and is probably far less meaningful that the interface name in a YANG context.  
I presume that this is if-index in RFC 8343 but that doesn't need to be 
supported if the server doesn't also support SNMP's if-mib.



I suspect that the reason why ip-address (and the v4/v6) variants haven't 
caused any problems in practice is because implementations are mostly wrongly 
treating them as ip-address-no-zone, and assuming that the scope information is 
being provided by other context (e.g., outgoing-interface in the example 
above), or perhaps most operators just configure their devices using global IP 
addresses.



Some further comments inline ...



> -Original Message-

> From: netmod  On Behalf Of Randy Presuhn

> Sent: 15 April 2022 20:25

> To: lsr@ietf.org; net...@ietf.org

> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-

> 10.txt

>

> Hi -

>

> I took a fresh look at RFC 6991, and a couple of things that have

> already been mentioned in this thread bear repetition.

>

> (1) in both the ipv4-address and ipv6-address typdefs, the zone

> is only optionally present.  This is made clear both in the

> string patterns as well as the descriptions, which state that

> it "may" be present, and clearly specify how its absence is

> to be understood.  Thus it's no surprise that their use has not

> caused any problems.  If the definitions go unchanged, there's

> no demonstrated need for any of the existing uses of these typedefs

> to be revised to employ something else, even if other typedefs

> are available that are more precisely 

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Martin,

I have several concerns with this approach:

(1) I still think that the ip-address type name still ends up being 
non-intuitive (especially for zoned IPv4 addresses - I would be surprised to 
find that there is any deployment for these at all).  I.e., the evidence seems 
to suggest that when engineers think of IP addresses, they don't seem to 
generally think of zoned IP addresses.  I doubt that any fiddling of the type 
description is going to change that perception, not least when the definition 
is different for OpenConfig and in vendors models and ip-address is widely used 
in many published YANG models.

(2) It means that clients of YANG models using the ip-address type have no idea 
whether the server will support zones without either trying the configuration 
(which could subsequently become unsupported in the future) or requiring an 
out-of-band discussion with the device vendor.  For such as basic type this 
doesn't seem great.

(3) For IETF models, does that mean that new models should use 
ip-address-no-zone, and that we should change the approx. 200 usages in 40-50 
published RFCs?  As mentioned previously, this doesn't seem pragmatic, or it 
will take the best part of a decade to happen.  During that time the difference 
between ip-address , ip-address-with-zone, and ip-address-no-zone will probably 
cause even further confusion due to the ambiguity, and differences in 
implementations.

(4) For NMDA models, it means that clients could (but probably never will) 
receive zoned ip addresses back from .  Further, if zoned IP 
addresses are returned, then they are expected to use numerical IDs for the 
zones, which seem to be effectively opaque to the client (other than 
uniqueness).  Clients seem to have a few choices: ignore (error?) on zoned IP 
addresses, ignore the zone (does that make sense), or have additional code to 
handle a case that for 99% of users will probably never happen.  My point being 
that these is also a cost to keeping support for zones in the base ip-address 
types.

Regards,
Rob



> -Original Message-
> From: Martin Björklund 
> Sent: 12 April 2022 08:26
> To: Rob Wilton (rwilton) 
> Cc: net...@ietf.org; lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-
> 10.txt
> 
> Hi,
> 
> Here's another suggestion.  We keep the ip-address pattern as is, but
> document in the description that implementations do not have to
> support the optional zone index.  This would essentially document the
> behavior of most current implementations.  (This is actually what I
> suggested in the earliest thread on this topic that I could find:
> https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-
> fRb2hVsf4sPuCU)
> 
> 
> 
> /martin
> 
> 
> "Rob Wilton \(rwilton\)"  wrote:
> > Hi all,
> >
> > Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> >
> > I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> >
> > Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> > 86 uses of ip-address
> > 68 uses of ipv4-address
> > 66 uses of ipv6-address
> >
> > 1 use of ip-address-no-zone
> > 4 uses of ipv4-address-no-zone
> > 4 uses of ipv6-address-no-zone
> >
> > These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in 40-
> 50 RFCs.
> >
> > As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> > They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> > There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of those
> 58 entries could still intentionally be supporting zoned IP addresses, but I
> would expect that the vast majority would not.
> > I do see some strong benefit if this basic type being defined in the same 
> > way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> d

[Lsr] IP address zones in YANG

[Rob Wilton (rwilton)]

Spinning off part of the discussion into a separate thread, but keeping lsr 
cc'ed on the discussion.



I'm trying to get a better understand of how and where zoned IP addresses 
should be used in YANG data models.



RFC 4007 defines zones for IPv6 addresses, but not for IPv4.  Even though RFC 
6991 bis has support for a zoned IPv4 address, I'm struggling to see where 
zoned IPv4 addresses would ever really be used.  Does anyone know of any usage 
or deployments anywhere?



For IPv6, my understanding is that the use of the zone is to add the extra 
interface context for IPv6 link-local addresses.  Is there any use of zones 
outside of this interface context?



The current definition of ipv6-address type and the ip-address nodes in 
ietf-ip.yang seem to make zoned IP addresses hard to use.  The canonical zone 
definition in RFC 6991 is for an (presumably unique) numeric zone identifier, 
but in the YANG management layer it is unclear to me how one maps from this 
numeric id back to the interface name (e.g., for a client to construct a 
suitable zoned IP address in configuration).   ietf-ip.yang uses 
ipv6-address-no-zone for interface IP addresses so it isn't possible to get the 
zone id associated with the link local address.  This feels underspecified to 
me to tie these together and make this work robustly.



I also have a general question about what is the best way of modelling this in 
YANG.  Using a zoned ip address is one choice to link an IP address and 
interface together.  Another choice is to have a separate leaf to scope an IP 
address to a specific interface, wherever that is appropriate and required.



E.g., considering the IP RIB YANG model,



 |  |+--rw v6ur:ipv6

 |  |   +--rw v6ur:route* [destination-prefix]

 |  |  +--rw v6ur:destination-prefix

 |  |  |   inet:ipv6-prefix

 |  |  +--rw v6ur:description?  string

 |  |  +--rw v6ur:next-hop

 |  | +--rw (v6ur:next-hop-options)

 |  |+--:(v6ur:simple-next-hop)

 |  ||  +--rw v6ur:outgoing-interface?

 |  ||  |   if:interface-ref

 |  ||  +--rw v6ur:next-hop-address?

 |  ||  inet:ipv6-address





Given that an outgoing-interface is already provided then it seems that using a 
zoned IP address as a next hop address here would potentially be confusing, or 
at least not required because it is effectively already scoped to the 
outgoing-interface anyway?  It seems like it provides redundant information.



Considering another arbitrary protocol YANG module RFC, this time TWAMP, rfc 
8913, it seems that some of the ip-address fields in the model could in theory 
support link local addresses (e.g., the test-session ones), but it is unclear 
to me whether that was ever the intent, or whether that even makes sense.  For 
the other uses of IP addresses that identify a client or server, it feels like 
using link local addresses is much less compelling.  Modelling these all with 
the same type seems confusing.



 | +--rw test-session-request* [name]

 |+--rw name  string

 |+--rw sender-ip?inet:ip-address

 |+--rw sender-udp-port?  union

 |+--rw reflector-ip  inet:ip-address

 |+--rw reflector-udp-port?   inet:port-number

 |+--rw timeout?  uint64

 |+--rw padding-length?   uint32

 |+--rw test-packet-dscp? inet:dscp

 |+--rw start-time?   uint64

 |+--rw repeat?   uint32

 |+--rw repeat-interval?  uint32

 |+--rw pm-reg-list* [pm-index]

 ||  +--rw pm-indexuint16

 |+--ro state?test-session-state

 |+--ro sid?  string





E.g., I guess that you could use a zoned IP address for the reflector-ip, but I 
suspect that most implementations would not anticipate/support this.  It feels 
to me that a cleaner way of modelling this would be to not use a zoned IP 
address type at all and have a separate egress-interface if:-interface-ref 
(perhaps under an if-feature, to enable and indicate support for test sessions 
over link-local addresses).



My overriding concern here, if we don't change/fix the ip-address type, is that 
we will end up with a set of YANG models that:

  1.  Models this behaviour in different ways for different protocols/features.
  2.  Are entirely ambiguous to clients and implementations as to whether it 
makes sense to support zoned IP addresses and/or whether zoned link-local 
addresses are supported for each leaf.
  3.  We are creating models for a hypothetical use case rather than how these 
protocols are actually being deployed/implemented today.  I.e., I am more 

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Tom,

Please see inline ...

> -Original Message-
> From: tom petch 
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; net...@ietf.org;
> lsr@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
> 
> From: netmod  on behalf of Rob Wilton
> (rwilton) 
> Sent: 11 April 2022 18:06
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> 86 uses of ip-address
> 68 uses of ipv4-address
> 66 uses of ipv6-address
> 
> 1 use of ip-address-no-zone
> 4 uses of ipv4-address-no-zone
> 4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At
> a quick guess/check it looks like these 49 YANG modules may appear in 40-50
> RFCs.
> 
> 
> 
> 
> As is sometimes the case with the processes of the IETF, this ignores any
> issues of transition.  I have pointed out a significant number of WG that have
> modules in I-D which include no-zone, in various states, perhaps increasing
> your figures by an order of magnitude.  What are you going to do with I-D
> e.g. in the RFC Editor queue?  Haul them back?

I think that depends on what consensus is reached.

I have no desire of trying to republish existing RFCs to either change 
"ip-address" to "ip-address-no-zone" or to change "ip-address-no-zone" to 
"ip-address".  I think the pragmatic thing to do would be to potentially flag 
these as errata so that they are hopefully fixed if/when the YANG module is 
eventually updated.

Entirely separately from this specific discussion, it would be good if we (the 
IETF) could come up with a better long-term plan for maintaining and evolving 
IETF YANG modules.


> 
> I think that the plan below is a bad one.  I would introduce types with zone -
> that is a no-brainer - but would deprecate the existing types.

Why is deprecating an existing type a problem?  It is deprecated, not obsolete.

It does not mean that modules can't use "ip-address-no-zone", it would just 
indicate that "ip-address" is the recommended type, if we get to a consensus 
where ip-address should migrate to meaning exactly the same as 
ip-address-no-zone.

There are APIs in Java that have been deprecated for 10+ years that are still 
available for use, but where the recommended is to not use them, or use a 
replacement API instead.

Regards,
Rob


> 
> Tom Petch
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of
> those 58 entries could still intentionally be supporting zoned IP addresses,
> but I would expect that the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference 
> between
> a type defined with an incomplete regex that may allow some invalid values
> and a type that is explicitly defined to included additional values in the
> allowable value space.  Further, I believe that a client just looking at the
> YANG module could reasonably expect a server that implements a data node
> using ip-address would be expected to support IP zones, where they are
> meaningful, or otherwise they should deviate that data node to indicate that
> they don't conform to the model.
> 
>

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.

Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do.  They are not 
going to start writing code to support zones just because they are in the 
model.  They will mostly reject IP addresses with zone information.  Perhaps 
some will deviate the type to ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
appealing.  This would take a significant amount of time/effort and I think 
that we will struggle to find folks who are willing to do this.  Although 
errata could be used to point out the bug, then can't be used to fix it, all 
the errata would be "hold for document update" at best.  Further, during the 
time that it would take us to fix it, it is plausible that more incorrect 
usages of ip-address will likely occur (but perhaps could be policed via 
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state where the 
"ip-address" type means what 99% of people expect it to mean, i.e., excluding 
zone information.

Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are 
unlikely to accept zone information in most scenarios (i.e., so the description 
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP 
addresses are required/useful, and models that use ip-address with the 
intention of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
- In the future (at least 2 years after RFC 6991 bis is published), the 
expectation is that the definition of ip-address will change to match that of 
ip-address-no-zone.

(2) Then in 2 years time, we publish RFC 6991-bis-bis to change the definition 
of ip-address to match ip-address-no-zone and deprecate the "-no-zone" version 
at the same time.

My reasoning as to why to take this path is:
(1) It is a phased migration, nothing breaks, 3rd parties have time to migrate.
(2) It ends up 

Re: [Lsr] [netmod] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

I basically agree with Acee, and I think that we should do (b):

b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.

I appreciate that this is an NBC change, but I believe that this is the most 
intuitive definition and is the best choice longer term.  I also note that the 
base ipv4-address/ipv6-address types in OpenConfig (where they use the OC 
copy/version of inet-types and not ietf-inet-types) don't allow a zone to be 
specified and assumes the default zone.  They have separate types in cases 
where a zone is allowed to be specified, i.e., aligned to what (b) proposes.

For modules that are using/wanting zones (if any), then they can migrate to the 
new explicit zone type.   draft-ietf-netmod-yang-module-versioning, if it keeps 
its import "revision-or-derived" extension, would also allow such modules to 
indicate the dependency on the updated revision/definition of 
ietf-inet-types.yang.

Of course, the description associated with the updated ietf-inet-types.yang 
revision should clearly highly the non-backwards-compatible change to the types.

Rob


-Original Message-
From: iesg  On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) 
Cc: lsr@ietf.org; The IESG ; net...@ietf.org
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Here is roughly what happened:

- RFC 6020 (published ~12 years ago) introduced the ip-address
  type. It included an optional zone index part since zone indexes
  are necessary in certain situations (e.g., configuring services
  listening on link-local addresses or clients connecting to services
  listening on link-local addresses).

- RFC 6991 (published ~9 years ago) added the ip-address-no-zone types
  since people felt that it is useful to also an ip address type
  without the optional zone part for situations where a zone is not
  applicable. The name 'ip-address-no-zone' was picked since the name
  ip-address was already taken.

I understand that the names resulting from this evolution of the YANG
module confuse people not looking up the type definitions. Let me note
that using a type allowing for an optional zone for a leaf that never
needs a zone is not a fatal error (its like using an int where a short
is sufficient) while using a type not allowing for a zone for a leaf
that may need zones is a fatal error (using a short where an int is
required) requiring an update of the definition of the leaf to fix.

What are our options?

a) Do nothing and accept that types are called as they are.
b) Change the types as suggested and accept that doing so breaks
   modules where zone indexes are meaningful.
c) Deprecate the types and create a new module defining new types
   so that modules can opt-in to use better names.
d) Deprecate the -no-zone types and move back to have a single
   type for IP addresses.

Any other options?

How are we going to pick between them?

/js

On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote:
> Jürgen and netmod WG,  +IESG,
> 
> It is not just the IETF models that are using the inet:ip-address for the 
> standard IPv4/IPv6 addresses without zones. Every vendor’s native models and 
> the OpenConfig models use the base types and expect the standard IP address 
> notation. If we don’t fix this, it is something that people can point to as 
> another example of the IETF being out of touch with reality.
> 
> I thought about more, and it might make the backward compatibility easier if 
> we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and 
> ipv6-address-no-zone types and add *-zone types for the remote possibility 
> that someone actually wants to include the zone.  In the existing RFC 6991 
> BIS document, we could merely remove the zone from the ip-address, 
> ipv4-address, and ipv6-address types and classify this as we would any other 
> bug fix. While including the zone was the original intent of the base types, 
> this is what those of us who work on software products would classify as a 
> requirements bug.
> 
> Thanks,
> Acee
> 
> From: Andy Bierman 
> Date: Tuesday, April 5, 2022 at 3:21 PM
> To: Juergen Schoenwaelder , Andy 
> Bierman , Acee Lindem , "lsr@ietf.org" 
> , "net...@ietf.org" 
> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> 
> 
> 
> On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote:
> > >
> > > The best outcome would be to fix ip-address to not include the zone,
> > > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> > > the is that all the existing usages do not require zone and this would be 
> > > a
> > > fix as opposed to a change.
> > >
> > >
> > I don't think this will harm our implementations.
> > The type is still string. The pattern will change but 

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Chris,

All good.  Thanks for the updates and the confirmation.

Regards,
Rob


-Original Message-
From: iesg  On Behalf Of Christian Hopps
Sent: 01 January 2022 09:25
To: Rob Wilton (rwilton) 
Cc: draft-ietf-lsr-yang-isis-reverse-met...@ietf.org; lsr-cha...@ietf.org; The 
IESG ; j...@juniper.net; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: Robert Wilton's No Objection on 
draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)


Hi Robert,

tl;dr all comments addressed :)

new version published:

  Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-yang-isis-reverse-metric-06
  URL: 
https://www.ietf.org/archive/id/draft-ietf-lsr-yang-isis-reverse-metric-06.txt

Comments inline as well...

Robert Wilton via Datatracker  writes:

> --
> COMMENT:
> --
>
> Hi Chris,
>
> Thanks for this YANG module.
>
> Nit:
> - Copyright statement in the YANG module should presumably be updated to 2021,
> to match the revision entry.

Updated to 2022.

> A few comments on the YANG model:
> - For the interface config, reverse-metric turns up twice in the path.  You
> could perhaps drop it from the
>   grouping so that it only appears once?

Dropped from grouping.

> - Would it be helpful to make the top level reverse-metric container have
> presence?  This might make more
>   sense if constraints are ever added to validate that a metric is specified 
> at
>   the top level, or under at least one of the levels.

This would require specifying a default reverse metric metric value, and there 
would be no way to enable reverse metric at only 1 of 2 levels on a level-1-2 
interface. I have expanded the description under the interface config augment 
container node to the following:

container reverse-metric {
  description
"Announce a reverse metric to neighbors. The configuration
 is hierarchical and follows the same behavior as defined
 for 'Per-Level' values in the augmented base module.

 Reverse metric operation is enabled by the configuration of
 a reverse-metric metric value at either the top level or
 under a level-specific container node. If a reverse-metric
 metric value is only specified under a level-specific
 container node then operation is only enabled at the
 specified level.";

> - Am I right in assuming that that the level-1/level-2 config is effectively
> hierarchical and would override
>   the config under the reverse-metric grouping?  E.g., is it allowed to 
> specify
>   a metric at the top level, and the whole-lan flag only under the level-1?  
> If
>   so, would it be helpful to document this hierarchical behaviour in the
>   description for the fields?

This hierarchical structure is documented in the base model. In addition to the 
text added in the description noted in the previous question, I've added the 
following text under "YANG Module" section as well:

  This YANG module uses the same "Per-Level" hierarchical configuration
  structure as is defined in the augmented base module.

> - There is a default assigned to exclude-te-metric, but no default assigned to
> whole-lan and allow-unreachable.

>   If the config is not hierarchical, then should these all have defaults? If
>   the config is hierarchical then perhaps they should not have any defaults,
>   and the use statement for the top level reverse-metric grouping should 
> refine
>   them with default values?  Assuming that the descriptions make their
>   hierarchical nature clear?

I have added a top level refinement to add default false for both flags.

> Security Considerations:
> Would it also be helpful to include a reference back to the security
> considerations of the base ISIS YANG module, since the concerns that apply to
> metrics there would seem to mostly also apply here.

Added a reference to the base YANG I-D.

> References:
> - Probably need to add XML and JSON references or otherwise change the 
> requests
> to edit-config or RESTCONF requests. - XML reference can be as per RFC 8342,
> JSON should probably be to RFC 7951.

Done.

> A.1.  Example Enable XML
> Suggest retitling to: Enablement Example Using XML YANG Instance Data"

Done.

> A.2.  Example Use XML
> Suggest retitling to: "Usage Example using XML YANG Instance Data"

Done.

> A.3.  Example JSON
> Suggest retitling to: "Usage Example using JSON YANG Instance Data"

Done.

Thanks,
Chris.

> Thanks,
> Rob

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

I don't disagree, but I believe that your comment generally applies to all AD 
review comments received during a telechat.

But notwithstanding, when reviewing this draft, and YANG model, I found aspects 
of its behaviour potentially unclear that I think could raise 
questions/problems to those implementing it, hence why I raised the comments 
that I did.  I would rather that those are clarified now, if necessary, before 
it becomes an RFC.  But at the end of the day, I considered balloting discuss, 
but decided to ballot no-obj on this draft, leaving it to the authors to 
consider the points that I raised and decide whether or not to act on them.

It is also the case that I have not read/reviewed the base ISIS YANG model, and 
some of my questions may be implicit in the design of that YANG model that this 
one is augmenting.

Thanks,
Rob


-Original Message-
From: Acee Lindem (acee)  
Sent: 29 November 2021 14:36
To: Rob Wilton (rwilton) ; The IESG 
Cc: draft-ietf-lsr-yang-isis-reverse-met...@ietf.org; lsr-cha...@ietf.org; 
lsr@ietf.org; j...@juniper.net
Subject: Re: Robert Wilton's No Objection on 
draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)

Hi Rob, 
Seems it would be better to get modeling suggestions earlier in the cycle than 
IESG telechat. 
Thanks,
Acee

On 11/29/21, 6:05 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-yang-isis-reverse-metric-04: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/



--
COMMENT:
--

Hi Chris,

Thanks for this YANG module.

Nit:
- Copyright statement in the YANG module should presumably be updated to 
2021,
to match the revision entry.

A few comments on the YANG model:
- For the interface config, reverse-metric turns up twice in the path.  You
could perhaps drop it from the
  grouping so that it only appears once?
- Would it be helpful to make the top level reverse-metric container have
presence?  This might make more
  sense if constraints are ever added to validate that a metric is 
specified at
  the top level, or under at least one of the levels.
- Am I right in assuming that that the level-1/level-2 config is effectively
hierarchical and would override
  the config under the reverse-metric grouping?  E.g., is it allowed to 
specify
  a metric at the top level, and the whole-lan flag only under the level-1? 
 If
  so, would it be helpful to document this hierarchical behaviour in the
  description for the fields?
- There is a default assigned to exclude-te-metric, but no default assigned 
to
whole-lan and allow-unreachable.
  If the config is not hierarchical, then should these all have defaults? If
  the config is hierarchical then perhaps they should not have any defaults,
  and the use statement for the top level reverse-metric grouping should 
refine
  them with default values?  Assuming that the descriptions make their
  hierarchical nature clear?

Security Considerations:
Would it also be helpful to include a reference back to the security
considerations of the base ISIS YANG module, since the concerns that apply 
to
metrics there would seem to mostly also apply here.

References:
- Probably need to add XML and JSON references or otherwise change the 
requests
to edit-config or RESTCONF requests. - XML reference can be as per RFC 8342,
JSON should probably be to RFC 7951.

A.1.  Example Enable XML
Suggest retitling to: Enablement Example Using XML YANG Instance Data"

A.2.  Example Use XML
Suggest retitling to: "Usage Example using XML YANG Instance Data"

A.3.  Example JSON
Suggest retitling to: "Usage Example using JSON YANG Instance Data"

Thanks,
Rob




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 20 May 2021 11:28
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com
> Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Hi Rob,
> 
> On 5/20/21, 5:11 AM, "Robert Wilton via Datatracker" 
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-isis-srv6-extensions-14: 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 DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Thanks for this document.
> 
> In various places, this document references lists of numerical
> algorithm
> numbers, or TLV Ids without any associated human names.  I would have
> found
> this document to be a bit more readable if the names of the algorithms
> and TLVs
> were also used alongside their numerical ids.
> 
> You mean like OSPF __?  For better or worse, IS-IS has always referred to
> TLVs by their numeric code point.
[RW] 

Ah, you can see that I haven't read many IS-IS specs.  If the convention is to 
always refer to them by their code points then that is fine, I just find the 
doc harder to read/understand.

Thanks,
Rob



> 
> Thanks,
> Acee
> 
> Thanks,
> Rob
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

Great.  Thank you for confirming.

Rob


> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 05 April 2021 14:46
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr-cha...@ietf.org;
> lsr@ietf.org; Christian Hopps ; aretana.i...@gmail.com
> Subject: Re: Robert Wilton's No Objection on draft-ietf-lsr-ospf-prefix-
> originator-10: (with COMMENT)
> 
> Hi Rob,
> 
> On 4/5/21, 9:41 AM, "Robert Wilton via Datatracker" 
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospf-prefix-originator-10: 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-lsr-ospf-prefix-
> originator/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for this.
> 
> Not a comment that requires addressing in the text, but considering
> section 5
> on the operational impact:  Is there an OSPF YANG model that is being
> updated
> to cover any additional configuration required to enable this
> functionality on
> a subset of prefixes, and/or are any changes to the operational YANG
> data model
> required to express the prefix source?
> 
> Yes - we will add an augmentation in
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
> 
> Thanks,
> Acee
> 
> Regards,
> Rob
> 
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Hi Yingzhen,

Just commenting for a YANG configuration perspective, I think that the YANG you 
propose is a reasonable approach.

In future, when it is clear the default behaviour should be app-specific, then 
the YANG could be changed to remove the mandatory true and add a default.  The 
combination of these changes would be classified as a backwards compatible 
change.  Note, a server implementation could also use deviations to equivalent 
effect to assign a default for a given implementation.

I don’t know whether this YANG would be configured per routing protocol 
instance, or something more specific (area or interface), but a hierarchical 
configuration model could be used if this configuration would otherwise be 
repetitive.

Regards,
Rob


From: iesg  On Behalf Of Yingzhen Qu
Sent: 18 June 2020 07:29
To: Les Ginsberg (ginsberg) ; BRUNGARD, 
DEBORAH A ; The IESG 
Cc: lsr@ietf.org; lsr-cha...@ietf.org; Acee Lindem (acee) ; 
draft-ietf-isis-te-...@ietf.org; aretana.i...@gmail.com
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the 
protocol definition and it is optional. For this case, if there is no default 
value the following could be an example YANG definition:

  choice te-app-op-mode {
mandatory "true";
leaf legacy {
  type empty;
}
leaf transition {
  type empty;
}
leaf app-specific{
  type empty;
}
description
  "Link attributes mode.";
  }

“mandatory true” is used here to make this configuration mandatory, which means 
implementations supporting this draft need to explicitly config the operation 
mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the 
next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

BTW, I’m now wondering whether the title of the draft is precise? Instead of 
“IS-IS TE Attributes per application”, maybe something like “IS-IS per 
application link attributes”? considering more applications will be using the 
sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of "Les 
Ginsberg (ginsberg)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" mailto:db3...@att.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "lsr-cha...@ietf.org" 
mailto:lsr-cha...@ietf.org>>, 
"aretana.i...@gmail.com" 
mailto:aretana.i...@gmail.com>>, "Acee Lindem (acee)" 
mailto:a...@cisco.com>>, 
"draft-ietf-isis-te-...@ietf.org" 
mailto:draft-ietf-isis-te-...@ietf.org>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: 
(with DISCUSS and COMMENT)
Resent-From: mailto:yingzhen...@huawei.com>>

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those 

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Rob Wilton (rwilton)]

Les,

Thanks for being accommodating.

Regards,
Rob


> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: 17 June 2020 15:57
> To: Rob Wilton (rwilton) ; Peter Psenak
> ; Benjamin Kaduk 
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; last-c...@ietf.org; Scott O. Bradner 
> Subject: RE: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> link-attr-reuse-14
> 
> Rob -
> 
> IS-IS draft currently states:
> 
> "User Defined Application Identifier Bits have no relationship to
>Standard Application Identifier Bits and are not managed by IANA or
>any other standards body."
> 
> (OSPF has this text also.)
> 
> I am happy enough to include an additional statement similar to the OSPF
> text below in Section 4.
> 
> Scott can speak for himself of course - but not clear to me that this
> really satisfies him since his comment was on the OSPF draft that already
> had this text.
> 
> And not clear that this would make Ben (copied) any more comfortable since
> his concern (clarified in his most recent post) is about discussing
> allocation of the UDA bit space.
> 
> But I will add the text - it makes the two drafts closer in content -
> which has been an ongoing goal during the review process.
> 
> Thanx.
> 
>Les
> 
> 
> > -Original Message-
> > From: Rob Wilton (rwilton) 
> > Sent: Wednesday, June 17, 2020 5:09 AM
> > To: Peter Psenak ; Les Ginsberg
> > (ginsberg) 
> > Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> > d...@ietf.org; last-c...@ietf.org; Scott O. Bradner 
> > Subject: RE: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> link-attr-
> > reuse-14
> >
> > Hi Les,
> >
> > Would you be opposed to adding text similar to the OSPF paragraph below
> to
> > the ISIS draft?
> >
> > I think that the OSPF draft does a better job of first introducing UDAs.
> Having
> > just looked at the ISIS draft, it does seem to somewhat assume that the
> > reader will just know what they are ...
> >
> > I understand that this should resolve Scott's concerns.
> >
> > Regards,
> > Rob
> >
> >
> > > -Original Message-
> > > From: last-call  On Behalf Of Scott O.
> Bradner
> > > Sent: 15 June 2020 11:17
> > > To: Peter Psenak 
> > > Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org;
> ops-
> > > d...@ietf.org; last-c...@ietf.org
> > > Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> > > link-attr-reuse-14
> > >
> > > that looks just fine to me - thanks
> > >
> > > Scott
> > >
> > > > On Jun 15, 2020, at 5:14 AM, Peter Psenak
> > >  wrote:
> > > >
> > > > Hi Scott.
> > > >
> > > > there is a following text in the OSPF draft:
> > > >
> > > >  "On top of advertising the link attributes for standardized
> > > >   applications, link attributes can be advertised for the purpose of
> > > >   applications that are not standardized.  We call such an
> > > >   application a "User Defined Application" or "UDA".  These
> > > >   applications are not subject to standardization and are outside of
> > > >   the scope of this specification."
> > > >
> > > > Feel free to propose an additional text if you feel above is not
> > > sufficient.
> > > >
> > > > thanks,
> > > > Peter
> > > >
> > > >
> > > >
> > > > On 14/06/2020 21:22, Scott Bradner via Datatracker wrote:
> > > >> Reviewer: Scott Bradner
> > > >> Review result: Ready
> > > >> I have reviewed the latest version of this document and my earlier
> > > issues have
> > > >> been resolved at least well enough for teh document to be
> considered
> > > ready for
> > > >> publication.
> > > >> that said I still do not see where "User Defined Application
> > > Identifier" is
> > > >> actually cleanly defined - one can read carefully and determine but
> it
> > > would be
> > > >> easier on the reader to just say that it is a field that can be
> used to
> > > >> indicate the use of one or more non-standard applications within
> some
> > > scope
> > > >> (network, subnet, link, organization, ... not sure what scopes are
> > > meaningful
> > > >> here but it does not seem that a User Defined Application
> Identifier
> > > would be a
> > > >> global (between network operators) value
> > > >> Scott
> > > >
> > > > --
> > > > last-call mailing list
> > > > last-c...@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/last-call
> > >
> > > --
> > > last-call mailing list
> > > last-c...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/last-call

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-link-attr-reuse-14

[Rob Wilton (rwilton)]

Hi Les,

Would you be opposed to adding text similar to the OSPF paragraph below to the 
ISIS draft?

I think that the OSPF draft does a better job of first introducing UDAs.  
Having just looked at the ISIS draft, it does seem to somewhat assume that the 
reader will just know what they are ...

I understand that this should resolve Scott's concerns.

Regards,
Rob


> -Original Message-
> From: last-call  On Behalf Of Scott O. Bradner
> Sent: 15 June 2020 11:17
> To: Peter Psenak 
> Cc: lsr@ietf.org; draft-ietf-ospf-te-link-attr-reuse@ietf.org; ops-
> d...@ietf.org; last-c...@ietf.org
> Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-ospf-te-
> link-attr-reuse-14
> 
> that looks just fine to me - thanks
> 
> Scott
> 
> > On Jun 15, 2020, at 5:14 AM, Peter Psenak
>  wrote:
> >
> > Hi Scott.
> >
> > there is a following text in the OSPF draft:
> >
> >  "On top of advertising the link attributes for standardized
> >   applications, link attributes can be advertised for the purpose of
> >   applications that are not standardized.  We call such an
> >   application a "User Defined Application" or "UDA".  These
> >   applications are not subject to standardization and are outside of
> >   the scope of this specification."
> >
> > Feel free to propose an additional text if you feel above is not
> sufficient.
> >
> > thanks,
> > Peter
> >
> >
> >
> > On 14/06/2020 21:22, Scott Bradner via Datatracker wrote:
> >> Reviewer: Scott Bradner
> >> Review result: Ready
> >> I have reviewed the latest version of this document and my earlier
> issues have
> >> been resolved at least well enough for teh document to be considered
> ready for
> >> publication.
> >> that said I still do not see where "User Defined Application
> Identifier" is
> >> actually cleanly defined - one can read carefully and determine but it
> would be
> >> easier on the reader to just say that it is a field that can be used to
> >> indicate the use of one or more non-standard applications within some
> scope
> >> (network, subnet, link, organization, ... not sure what scopes are
> meaningful
> >> here but it does not seem that a User Defined Application Identifier
> would be a
> >> global (between network operators) value
> >> Scott
> >
> > --
> > last-call mailing list
> > last-c...@ietf.org
> > https://www.ietf.org/mailman/listinfo/last-call
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Peter,

Cutting the response to just the text in question.


> -Original Message-
> From: Peter Psenak 
> Sent: 12 June 2020 09:25
> To: Rob Wilton (rwilton) ; Alvaro Retana
> 
> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> ; The IESG 
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> reuse-14: (with DISCUSS)
> 
> Hi Rob,
> 
> >
> > Probably this paragraph could be improved to make its intent more clear?
> I.e. the attributes values in the default ASLA apply for all applications,
> unless that are overridden by application specific definitions of
> particular attributes, and all other default attribute value still apply.
> 
> 
> ##PP
> ok, I see.
> 
> What about this:
> 
> 
> If link attributes are advertised associated with zero length
> Application Identifier Bit Masks for both standard applications and
> user defined applications, then any Standard Application and/or any
> User Defined Application is permitted to use that set of link
> attributes. If support for a new application is introduced
> on any node in a network in the presence of such advertisements,
> these advertisements are permitted to be used by the new application.
> If this is not what is intended, then existing advertisements MUST be
> readvertised with an explicit set of applications specified before a
> new application is introduced.
> 
> An application specific advertisement (Application Identifier Bit
> Mask with a matching Application Identifier Bit set) for an attribute
> MUST always be preferred over the advertisement of the same attribute
> with the zero length Application Identifier Bit Masks for both
> standard applications and user defined applications on the same link.
> 
> thanks,
> Peter
> 

[RW] 

This is okay, but could potentially still be improved by giving a name to the 
wildcard attributes (e.g. wildcard, common, or default).  Possibly splitting 
the text regarding new applications from the preceding part of the paragraph 
would help.  I would then also reorder the paragraphs.  Perhaps something along 
the lines of:

Wildcard link attributes can be advertised using zero length
Application Identifier Bit Masks for both standard applications and
user defined applications.  All Standard and User Defined
Applications are permitted to use any of the wildcard link attributes.

An application specific advertisement (Application Identifier Bit
Mask with a matching Application Identifier Bit set) for a link
Attribute MUST always be preferred over any wildcard advertisement of
the link attribute on the same link.

If support for a new application is introduced on any node in a
network in the presence of wildcard advertisements, these wildcard
advertisements are permitted to be used by the new application.
If this is not what is intended, then existing advertisements MUST be
re-advertised with an explicit set of applications specified before
the new application is introduced.

If you prefer your proposed text, or want to wordsmith my proposed text that is 
fine with me ...

One further comment:  I presume that it is allowed to split the advertisement 
of wildcard link attributes into multiple ASLA TLVs, as long as they don't 
overlap.  I don't think that you need to say anything about this, unless my 
presumption is wrong.

Regards,
Rob

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Peter,

Please see inline ...

I think that there is probably just one point of confusion/ambiguity that needs 
to be resolved.

> -Original Message-
> From: Peter Psenak 
> Sent: 11 June 2020 11:30
> To: Rob Wilton (rwilton) ; Alvaro Retana
> 
> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> ; The IESG 
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> reuse-14: (with DISCUSS)
> 
> Hi Rob,
> 
> 
> thanks for your comments, please see inline (##PP)
> 
> On 10/06/2020 19:18, Rob Wilton (rwilton) wrote:
> > Hi Alvaro,
> >
> >
> >> -Original Message-----
> >> From: Alvaro Retana 
> >> Sent: 10 June 2020 16:49
> >> To: Rob Wilton (rwilton) 
> >> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> >> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> >> ; The IESG 
> >> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> >> reuse-14: (with DISCUSS)
> >>
> >> On June 10, 2020 at 10:32:09 AM, Robert Wilton wrote:
> >>
> >>
> >> Rob:
> >>
> >> Hi!
> >>
> >> Thanks for the review.
> >>
> >> I’m replying for the authors as I think that your
> >> questions/suggestions should be easy to address.  Please see below.
> > [RW]
> >
> > Yes, hopefully.
> >
> >>
> >>
> >> Thanks!
> >>
> >>
> >> Alvaro.
> >>
> >>
> >>> --
> >>> DISCUSS:
> >>> --
> >>>
> >>> I found parts of this document hard to understand, but I'm not
> familiar
> >> with
> >>> the specifics of the protocols.
> >>>
> >>> This discuss is in the vein of "I think that folks might struggle to
> >>> implement this correctly/consistently". In particular I had some
> >>> questions/concerns about section 5 which, if clarified, would probably
> >> help
> >>> this document.
> >>>
> >>> In Section 5:
> >>>
> >>> The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
> >>> in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA
> >>> sub-TLV MUST be used for advertisement of the link attributes listed
> >>> at the end on this section if these are advertised inside OSPFv2
> >>> Extended Link TLV and OSPFv3 Router-Link TLV. It has the following
> >>> format:
> >>>
> >>> I think that it would be useful to clarify when/why the ASLA sub-TLV
> can
> >> be
> >>> included multiple times. I.e. when different applications want to
> >> control
> >>> different link attributes.
> >>
> >> That sounds like a simple addition.
> 
> ##PP
> Updated as:
> 
> 
> The ASLA sub-TLV is an optional sub-TLV of OSPFv2 Extended Link TLV and
> OSPFv3 Router-Link TLV. Multiple ASLA sub-TLVs can be present in its
> parent TLV when different applications want to control different link
> attributes or when different value of the same attribute needs to be
> advertised by multiple applications.
> 
[RW] 

That looks fine.



> >>
> >>
> >>
> >>> Standard Application Identifier Bits are defined/sent starting with
> >>> Bit 0. Undefined bits which are transmitted MUST be transmitted as 0
> >>> and MUST be ignored on receipt. Bits that are not transmitted MUST
> >>> be treated as if they are set to 0 on receipt. Bits that are not
> >>> supported by an implementation MUST be ignored on receipt.
> >>>
> >>> It was not clear to me what it means if the SABM (or UDABM) fields are
> >>> entirely empty. This paragraph states that they are treated as if they
> >> are
> >>> 0, but sections 8 and 11 imply that if the field is omitted then it
> acts
> >> as
> >>> if all applications are allowed. Section 12.2 implies that if the
> field
> >> is
> >>> omitted then it is as if all applications are allowed unless there
> there
> >> is
> >>> another ASLA with the given application bit set, in which case it is
> >> treated
> >>> as being a 0 again. I think that this document would be helped if the
> >>> specific behaviour was defined in 

Re: [Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)

[Rob Wilton (rwilton)]

Hi Alvaro,


> -Original Message-
> From: Alvaro Retana 
> Sent: 10 June 2020 16:49
> To: Rob Wilton (rwilton) 
> Cc: Acee Lindem (acee) ; draft-ietf-ospf-te-link-attr-
> re...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Yingzhen Qu
> ; The IESG 
> Subject: Re: Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-
> reuse-14: (with DISCUSS)
> 
> On June 10, 2020 at 10:32:09 AM, Robert Wilton wrote:
> 
> 
> Rob:
> 
> Hi!
> 
> Thanks for the review.
> 
> I’m replying for the authors as I think that your
> questions/suggestions should be easy to address.  Please see below.
[RW] 

Yes, hopefully.

> 
> 
> Thanks!
> 
> 
> Alvaro.
> 
> 
> > --
> > DISCUSS:
> > --
> >
> > I found parts of this document hard to understand, but I'm not familiar
> with
> > the specifics of the protocols.
> >
> > This discuss is in the vein of "I think that folks might struggle to
> > implement this correctly/consistently". In particular I had some
> > questions/concerns about section 5 which, if clarified, would probably
> help
> > this document.
> >
> > In Section 5:
> >
> > The ASLA sub-TLV is an optional sub-TLV and can appear multiple times
> > in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA
> > sub-TLV MUST be used for advertisement of the link attributes listed
> > at the end on this section if these are advertised inside OSPFv2
> > Extended Link TLV and OSPFv3 Router-Link TLV. It has the following
> > format:
> >
> > I think that it would be useful to clarify when/why the ASLA sub-TLV can
> be
> > included multiple times. I.e. when different applications want to
> control
> > different link attributes.
> 
> That sounds like a simple addition.
> 
> 
> 
> > Standard Application Identifier Bits are defined/sent starting with
> > Bit 0. Undefined bits which are transmitted MUST be transmitted as 0
> > and MUST be ignored on receipt. Bits that are not transmitted MUST
> > be treated as if they are set to 0 on receipt. Bits that are not
> > supported by an implementation MUST be ignored on receipt.
> >
> > It was not clear to me what it means if the SABM (or UDABM) fields are
> > entirely empty. This paragraph states that they are treated as if they
> are
> > 0, but sections 8 and 11 imply that if the field is omitted then it acts
> as
> > if all applications are allowed. Section 12.2 implies that if the field
> is
> > omitted then it is as if all applications are allowed unless there there
> is
> > another ASLA with the given application bit set, in which case it is
> treated
> > as being a 0 again. I think that this document would be helped if the
> > specific behaviour was defined in section 5, retaining the
> > justification/clarification in the subsequent sections.
> 
> Empty is different than omitted.
> 
> Omitted (the length of the field is 0) means: "these attributed apply
> to all applications, so I'm not even going to bother setting the
> bits".
[RW] 

I don’t particularly like this as the solution, since if feels inconsistent to 
me.  I.e. if you don’t advertise a bit always treat it as zero, unless you 
don’t say anything at all, in which case treat it as 1.  I would have preferred 
for it to have an explicit flag bit in the ASLA TLV to indicate that all 
applications are supported ... more below (see *).

> 
> 
> Empty (the field is present, but all the bits are set to 0) means that
> the sender is saying that "no application applies to this set of
> attributes".  I can't think of a circumstance when a sender would do
> this, as it is basically an empty announcement: it doesn't apply to
> anythingbut it is also not wrong and would simply not be used.
[RW] 

I agree.  Arguably, the document could state that at least one bit in the SABM 
or UDABM flags SHOULD be set.



> 
> OTOH, there is a case where the sender can set a bit (or more) for an
> application it supports (maybe a new one) -- if the receiver doesn't
> support that application it will then ignore the bit, and it will look
> as if nothing was set: none of the supported applications (at the
> receiver) match.  Again, the receiver will simply not use the
> information.
[RW] 

This is okay with me.

But it is this text in section 12.2 that seems to define different/complicated 
semantics:

12.2.  Use of Zero Length Application Identifier Bit Masks

   If link attributes are advertised associated with zero length
   Application Identifier 

Re: [Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Acee,

Do you think that it would be helpful to have an informative reference to 
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1?  And 
possibly a comment somewhere in the draft to specify where the manageability 
model will be specified?

The same comment obviously applies to the OSPF draft also ...

Regards,
Rob



-Original Message-
From: Acee Lindem (acee)  
Sent: 19 May 2020 12:17
To: Rob Wilton (rwilton) ; The IESG 
Cc: draft-ietf-isis-mpls-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; 
aretana.i...@gmail.com
Subject: Re: Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with 
COMMENT)

Hi Rob, 

On 5/19/20, 6:00 AM, "Robert Wilton via Datatracker"  wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-isis-mpls-elc-12: 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-isis-mpls-elc/



--
COMMENT:
--

Hi,

Same comment as for equivalent OSPF draft.

Is there any associated YANG module required to manage this protocol
enhancement?  If so, is that already being worked or, or planned work for 
the
WG?

We will add the necessary IS-IS encodings to this module - 
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/

Thanks,
Acee

Regards,
Rob




___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[Rob Wilton (rwilton)]

Fore hierarchical configuration, generally the YANG default statement only 
makes sense for the top level, i.e. the least specific, configuration node.

Hence, I think that it would be better if the level-1 and level-2 containers 
did not use a YANG default statement at all.  Instead, the description should 
explain (perhaps once at the level-1/level-2 container level, or alternatively 
for every leaf) that the configuration is hierarchical, and if not explicitly 
configured for a particular level, it uses whatever value is either explicitly 
configured, or otherwise the default, associated with the top level container.

There is an example of this (but without a top level default) in appendix C.2 
of RFC8342.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Qin Wu
Sent: 10 June 2019 03:37
To: Juergen Schoenwaelder ; Xufeng Liu 

Cc: lsr@ietf.org; NETMOD WG 
Subject: Re: [netmod] A question on the parameter overriding in 
draft-ietf-isis-yang-isis-cfg

I think what they are looking for in RFC7950 is generic overridden rule, i.e., 
a parent node statement can be overridden by its child node substatement.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2019年6月9日 23:28
收件人: Xufeng Liu 
抄送: lsr@ietf.org; NETMOD WG 
主题: Re: [netmod] A question on the parameter overriding in 
draft-ietf-isis-yang-isis-cfg

Hi,

YANG does not have 'levels'. This seems to be an ISIS specific question you 
should ask on the ISIS list.

/js

On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> In Section 2.3. and many other locations, the current IS-IS model 
> applies the parameter overriding rule as below:
> 
> [Quote]:
> 
> 2.3 
> .
> Per-Level Parameters
> 
> 
>Some parameters allow a per level configuration.  In this case, the
>parameter is modeled as a container with three configuration
>locations:
> 
>o  a top-level container: corresponds to level-1-2, so the
>   configuration applies to both levels.
> 
>o  a level-1 container: corresponds to level-1 specific parameters.
> 
>o  a level-2 container: corresponds to level-2 specific parameters.
> 
>+--rw priority
>|  +--rw value? uint8
>|  +--rw level-1
>|  |  +--rw value?   uint8
>|  +--rw level-2
>| +--rw value?   uint8
> 
>Example:
> 
>
>250
>
>100
>
>
>200
>
>
> 
>An implementation SHOULD prefer a level specific parameter over a
>level-all parameter.  As example, if the priority is 100 for the
>level-1, 200 for the level-2 and 250 for the top-level configuration,
>the implementation should use 100 for the level-1 and 200 for the
>level-2.
> 
> [End of Quote]
> 
> 
> In the model, all three value leaves above have a default statement 
> “default 64”, which brings up my question for the following example:
> 
> 
>
>250
>
>100
>
>
> 
> 
> The user does not provide a configured value for level-2. According to 
> Section 7.6.1. of RFC7950, because the default value is in use, “the 
> server MUST operationally behave as if the leaf was present in the 
> data tree with the default value as its value”. This means the 
> priority value for level-2 will be 64 (the default value), so the 
> value 250 can never take effect as intended in the above quoted Section 2.3.
> 
> 
> Is my understanding correct?
> 
> 
> Since this is a generic question, I am CC’ing NETMOD WG too.
> 
> 
> Thanks,
> 
> - Xufeng

> ___
> netmod mailing list
> net...@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
net...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr