[Lsr] Warren Kumari's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)

[Warren Kumari via Datatracker]

Warren Kumari has entered the following ballot position for
draft-ietf-ospf-mpls-elc-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



--
COMMENT:
--

Nit: “ When an OSPF Autonomous System Boundary Router (ASBR) redistributes a  
prefix from another instance of the OSPF or from some other protocol,   it
SHOULD preserve the ELC signaling for the prefix.“

S/the /OSPF/OSPF/.

S/for the prefix/for the prefix (if it exists)/ — some protocols will not have
/ carry the ELC.

Apologies if I missed it, but I didn’t see discussion on *exporting* ELC into
other protocols...



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

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Acee Lindem (acee)]

Hi Les,
Good point – I don’t believe any modifications are necessary.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Thursday, May 14, 2020 at 5:46 PM
To: Alvaro Retana , Acee Lindem , 
"Peter Psenak (ppsenak)" , Elwyn Davies 
, "gen-...@ietf.org" 
Cc: "lsr@ietf.org" , "last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
Subject: RE: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Elwyn’s comment was:


I was trying to understand
why a router that satisfies the previous condition so that it is
legitimate for it to announce ELC with any IP address prefix might wish
to only announce it with some prefixes and not others.


The answer to that is clearly stated in the draft (emphasis added):

“If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.”


What is needed is to know whether traffic routed via a particular node can 
depend upon that node supporting EL.  That info is communicated by advertising 
ELC for the local host prefixes only.
No need to do so for other prefixes.

HTH

   Les


From: Lsr  On Behalf Of Alvaro Retana
Sent: Thursday, May 14, 2020 12:46 PM
To: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; Elwyn Davies ; gen-...@ietf.org
Cc: lsr@ietf.org; last-c...@ietf.org; draft-ietf-ospf-mpls-elc@ietf.org
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only 
obviously applies to implementations that support it — in that case I would 
think that if a router supports ELs on all of its interfaces then it would 
always advertise the ELC, right?


Thanks!

Alvaro.


On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue?
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Les Ginsberg (ginsberg)]

Elwyn’s comment was:


I was trying to understand
why a router that satisfies the previous condition so that it is
legitimate for it to announce ELC with any IP address prefix might wish
to only announce it with some prefixes and not others.


The answer to that is clearly stated in the draft (emphasis added):

“If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.”


What is needed is to know whether traffic routed via a particular node can 
depend upon that node supporting EL.  That info is communicated by advertising 
ELC for the local host prefixes only.
No need to do so for other prefixes.

HTH

   Les


From: Lsr  On Behalf Of Alvaro Retana
Sent: Thursday, May 14, 2020 12:46 PM
To: Acee Lindem (acee) ; Peter Psenak (ppsenak) 
; Elwyn Davies ; gen-...@ietf.org
Cc: lsr@ietf.org; last-c...@ietf.org; draft-ietf-ospf-mpls-elc@ietf.org
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only 
obviously applies to implementations that support it — in that case I would 
think that if a router supports ELs on all of its interfaces then it would 
always advertise the ELC, right?


Thanks!

Alvaro.


On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue?
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Acee Lindem (acee)]

Hi Alvaro, Elwyn,

From: Alvaro Retana 
Date: Thursday, May 14, 2020 at 3:46 PM
To: Acee Lindem , "Peter Psenak (ppsenak)" , 
Elwyn Davies , "gen-...@ietf.org" 
Cc: "last-c...@ietf.org" , 
"draft-ietf-ospf-mpls-elc@ietf.org" 
, "lsr@ietf.org" 
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13

Hi!

Yes, we cannot specify something that routers unaware of this specification 
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this specification* 
then when would it not advertise the ELC?  IOW, the specification only 
obviously applies to implementations that support it — in that case I would 
think that if a router supports ELs on all of its interfaces then it would 
always advertise the ELC, right?

That’s true – but not advertising the OSPF capability could imply that either 
ELC MSD or advertisement of the OSPF capability is not supported. Although I 
might not have worded it as such, that was clear to me from the text. Feel free 
to recommend alternate text if you feel it is necessary.

Thanks,
Acee

Thanks!

Alvaro.


On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) 
(a...@cisco.com) wrote:
Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support 
multipath forwarding entropy using MPLS entropy labels but do not signal that 
capability in OSPF. We can't have a document that retroactively mandates that 
they signal it. This wouldn't be backward compatible. How can you possibly see 
this as a serious issue?
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Alvaro Retana]

Hi!

Yes, we cannot specify something that routers unaware of this specification
should or shouldn’t do.

I believe that Elwyn’s point is this: *if a router supports this
specification* then when would it not advertise the ELC?  IOW, the
specification only obviously applies to implementations that support it —
in that case I would think that if a router supports ELs on all of its
interfaces then it would always advertise the ELC, right?


Thanks!

Alvaro.

On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (a...@cisco.com) wrote:

Note that the optionality of ERLD-MSD advertisements appears on
reflection to be a more serious issue than just an editorial nit.

So what would you suggest? There are existing implementations that support
multipath forwarding entropy using MPLS entropy labels but do not signal
that capability in OSPF. We can't have a document that retroactively
mandates that they signal it. This wouldn't be backward compatible. How can
you possibly see this as a serious issue?
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Last Call: (OSPF Link Traffic Engineering Attribute Reuse) to Proposed Standard

[The IESG]

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'OSPF Link Traffic Engineering Attribute
Reuse'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Traffic Engineering, Loop Free Alternate) have been
   defined which also make use of the link attribute advertisements.  In
   cases where multiple applications wish to make use of these link
   attributes the current advertisements do not support application
   specific values for a given attribute nor do they support indication
   of which applications are using the advertised value for a given
   link.  This document introduces new link attribute advertisements in
   OSPFv2 and OSPFv3 which address both of these shortcomings.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/



No IPR declarations have been submitted directly on this I-D.





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

[Lsr] Last Call: (IS-IS TE Attributes per application) to Proposed Standard

[The IESG]

The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS TE Attributes per application'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Existing traffic engineering related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Traffic Engineering, Loop Free Alternate) have been
   defined which also make use of the link attribute advertisements.  In
   cases where multiple applications wish to make use of these link
   attributes the current advertisements do not support application
   specific values for a given attribute nor do they support indication
   of which applications are using the advertised value for a given
   link.  This document introduces new link attribute advertisements
   which address both of these shortcomings.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/



No IPR declarations have been submitted directly on this I-D.





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

[Lsr] Considerations for Extended TE Metrics (draft-ietf-isis-te-app)

[Alvaro Retana]

Dear authors:


When reviewing the updates to draft-ietf-ospf-te-link-attr-reuse-11, I
noticed the following difference with respect to
draft-ietf-isis-te-app-12:


[] draft-ietf-isis-te-app-12:

437 4.2.3.  Considerations for Extended TE Metrics

439    [RFC8570] defines a number of dynamic performance metrics associated
440    with a link.  It is conceivable that such metrics could be measured
441    specific to traffic associated with a specific application.
442    Therefore this document includes support for advertising these link
443    attributes specific to a given application.  However, in practice it
444    may well be more practical to have these metrics reflect the
445    performance of all traffic on the link regardless of application.  In
446    such cases, advertisements for these attributes will be associated
447    with all of the applications utilizing that link.


[] draft-ietf-ospf-te-link-attr-reuse-11:

449 8.  Considerations for Extended TE Metrics

451    [RFC7471] defines a number of dynamic performance metrics associated
452    with a link.  It is conceivable that such metrics could be measured
453    specific to traffic associated with a specific application.
454    Therefore this document includes support for advertising these link
455    attributes specific to a given application.  However, in practice it
456    may well be more practical to have these metrics reflect the
457    performance of all traffic on the link regardless of application.  In
458    such cases, advertisements for these attributes can be associated
459    with all of the applications utilizing that link, for example, by
460    listing all applications in the Application Bit-Mask.



The difference is in the last sentence: the OSPF draft points at how
the user can associate the attributes with all the
applications...while the ISIS draft just says that the "attributes
will be associated with all of the applications".

I'm assuming that the ISIS operation is similar: the new sub-TLV would
have to include all the appropriate bits in the Application Bit-Mask.
Is that a correct assumption, or will ISIS behave differently?

Please clarify the text in the ISIS draft.


As I mentioned in the thread about draft-ietf-ospf-te-link-attr-reuse,
I am starting the IETF Last Call for both documents.  We can work on
this clarification during that time.


Thanks!

Alvaro.

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

Re: [Lsr] AD Review of draft-ietf-ospf-te-link-attr-reuse-10

[Alvaro Retana]

On May 5, 2020 at 6:08:27 AM, Peter Psenak wrote:


Peter:

Hi!


...
> I tried to address all of them, some have been resolved during ISIS
> draft review, in which case I took the same resolution for this draf.
>
> Please see inline, look for ##PP


There's only one outstanding comment that I don't think was answered
-- or at least I missed the meaning of the answer.  Please see below.


I am also including some comments based on -11.  Except for the
Normative language in §12.1, all the comments are basically
nits/suggestions.


I am starting the IETF Last Call for this document and
draft-ietf-isis-te-app.  We can work on these remaining comments while
we do that.

Thanks!

Alvaro.



...
> 434 6. Local Interface IPv6 Address Sub-TLV
>
> [major] The Local/Remote Interface IPv6 Address Sub-TLVs (rfc5329) can
> include multiple addresses for a link. It seems to me that it could
> be possible for different applications to use different addresses. If
> that is the case, then it seems that these sub-TLVs should not be
> application independent. Why are they not considered to be
> application specific?
>
> [minor] Why are IPv4 addresses not considered?
>
> ##PP
> IPv4 local address is part of the basic spec.
> IPv6 remote address has been added in rfc8379.

For IPv4: what basic spec?

For IPv6: rfc8379 doesn’t seem to relate to the questions — am I
missing something?





[Line numbers from idnits]

draft-ietf-ospf-te-link-attr-reuse-11

...
168 4.1.  OSPFv2 Extended Link Opaque LSA and OSPFv3 E-Router-LSA
...
184    3.  There is clear distinction between link attributes used by RSVP-
185        TE and link attributes used by other OSPFv2 or OSPFv3
186        applications.

[nit] s/is clear distinction/is a clear distinction


...
203    TE link attributes used for RSVP-TE/GMPLS continue use OSPFv2 TE
204    Opaque LSA [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329].

[nit] s/continue use/continue to use


...
213 5.  Advertisement of Application Specific Values
...
252       SABM Length: Standard Application Identifier Bit-Mask Length in
253       octets.  The legal values are 0, 4 or 8.  If the Standard
254       Application Bit-Mask is not present, the Standard Application Bit-
255       Mask Length MUST be set to 0.

257       UDABM Length: User Defined Application Identifier Bit-Mask Length
258       in octets.  The legal values are 0, 4 or 8.  If the User Defined
259       Application Bit-Mask is not present, the User Defined Application
260       Bit-Mask Length MUST be set to 0.

[minor] "The legal values are 0, 4 or 8."  Should the statement be
Normative ("MUST be...")?  I know there is a sentence below about
ignoring the sub-TLV if a different value is received -- IOW, just a
suggestion.


...
319       - Unidirectional Link Dela [RFC7471]

321       - Min/Max Unidirectional Link Delay [RFC7471]
322       - Unidirectional Delay Variation [RFC7471]

[nit] There seems to be a line missing...


...
532 12.1.  Use of Legacy RSVP-TE LSA Advertisements

534    Bit Identifiers for Standard Applications are defined in Section 5.
535    All of the identifiers defined in this document are associated with
536    applications which were already deployed in some networks prior to
537    the writing of this document.  Therefore, such applications have been
538    deployed using the RSVP-TE LSA advertisements.  The Standard
539    Applications defined in this document MAY continue to use RSVP-TE LSA
540    advertisements for a given link so long as at least one of the
541    following conditions is true:

[major] s/MAY/may


...
651 12.3.4.  Use of Application Specific Advertisements for RSVP-TE

653    The extensions defined in this document support RSVP-TE as one of the
654    supported applications.  It is however RECOMMENDED to advertise all
655    link-attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA
656    [RFC3630] and OSPFv3 Intra-Area-TE-LSA [RFC5329] to maintain backward
657    compatibility.  RSVP-TE can eventually utilize the application
658    specific advertisements for newly defined link attributes, which are
659    defined as application specific.

[minor] "It is however RECOMMENDED to advertise all link-attributes
for RSVP-TE in the existing..."  The application specific
advertisements can be used and result in duplicate information.  The
ISIS draft includes some sample steps to eliminate redundancy and get
rid of the legacy advertisements -- can we add something similar here?

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