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

2020-05-14 Thread 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

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

2020-05-14 Thread 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" ,

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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

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

2020-05-14 Thread 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