Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Acee,

I am OK with changing the wording as you suggested. Will do it in next revision.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Friday, April 21, 2017 7:35 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt



On 4/21/17, 6:37 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Acee,
>
>
>> I don’t see any need to reference RFC 4203 since the Sub-TLV is 
>>sufficiently defined here. This is completely orthogonal to the 
>>definition in this draft.
>
>I do not agree with this point. The sub-TLV, local/remote interface id 
>requires the  remote interface-id to be filled and the draft refers to 
>an existing standard on getting this remote interface id. This is the 
>standard mechanism we follow in every draft.

I think we’re back to the circular argument with respect to the gratuitous 
repurposing of TE LSAs standardized under to satisfy GMPLS requirements for 
every purpose. Even in support of your position, the blanket statement is not 
germane to the draft. I might be ok with “One mechanism to learn the remote-id 
is described in ….” However, it appears now that we have broached the subject 
of WG last call, there is much discussion on the draft. 

Thanks,
Acee 

>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 7:07 PM
>To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem 
><acee.lin...@gmail.com>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha,
>
>On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>Hi Acee,
>>
>>The draft does not mandate use of RFC 4203. There are no MUST 
>>statements associated with the recommendation.
>
>I don’t see any need to reference RFC 4203 since the Sub-TLV is 
>sufficiently defined here. This is completely orthogonal to the 
>definition in this draft.
>>
>>
>>RFC 4203 is a standard and has been around for a while. I do not 
>>understand why there is concern being raised over Referencing an RFC 
>>which has been a standard and deployed in the field for many years.
>>
>>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is 
>>still an independent draft and it does not make sense to refer this 
>>draft in draft-ietf-ospf-link-overload-06 which is ready for WG last 
>>call.
>
>I wasn’t suggesting to reference either document.
>
>Thanks,
>Acee
>
>
>>
>>Rgds
>>Shraddha
>>
>>-Original Message-
>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>Sent: Thursday, April 20, 2017 4:02 AM
>>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde 
>><shrad...@juniper.net>
>>Cc: ospf@ietf.org
>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>
>>Hi Shraddha,
>>
>>The only non-editorial comment that I have is that the draft 
>>references RFC 4203 as the way to learn the remote interface ID on an 
>>unnumbered link 
>>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt).
>>As you know, this is a very controversial topic with some of us 
>>wanting this to be in the hello packets consistent with OSPFv3 and 
>>IS-IS as opposed to using a link-scoped TE Opaque LSA as suggested in 
>>the OSPF GMPLS Extensions RFC 
>>(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
>>reference.
>>
>>Thanks,
>>Acee
>>
>>
>>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>>
>>>Hi Shraddha,
>>>
>>>I think this version addresses all my comments. I will do a detailed 
>>>review this week and, most likely, start the WG last call. I 
>>>encourage other WG members to do the same.
>>>
>>>Thanks,
>>>Acee
>>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>>wrote:
>>>> 
>>>> Hi Acee,
>>>> 
>>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>>remote-ipv4 addr is moved to a new sub-TLV.
>>>> Pls review.
>>>> 
>>>> The authors of the draft believe that draft has undergone multiple 
>>>>revisions/reviews and is ready for WG last call.
>>>> 
>>>> Rgds
>>>> Shraddha
>>>> 
>>>> 
>>>> 

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Alexander Okonnikov]

Hi Christian,

See inline.

Thank you.

On 23 апр. 2017 г., 18:17 +0300, Christian Hopps , wrote:
>
> Alexander Okonnikov  writes:
>
> > Hi Christian,
> >
> > See inline.
> >
> > Thank you.
> >
> > -- Best regards, Alexander Okonnikov
> >
> > On 21 апр. 2017 г., 18:36 +0300, Christian Hopps , wrote:
> >
> > Alexander Okonnikov  writes:
> >
> > no argument about the need of area level flooding - Router LSA with
> > the max metric will be flooded within the area.
> >
> > I have read the section 7.2 several times, but I still do not
> > understand what is the purpose of the Link-Overload sub-TLV there.
> > What is the controller going to do when it receives the area scoped
> > Link-Overload sub-TLV and how it is different to the case where the
> > link is advertised in the Router LSA with max-metric in both directions?
> >
> > The fact that link metric has been maximized could not be a trigger for
> > LSP recalculation. Some implementations consider IGP topology change as
> > a trigger for LSP recalculation, but others - don't. Also, max metric
> >
> > But you have to change the code anyway to make a new TLV work, right? So
> > what old code does isn't really relevant, unless I misunderstand things.
> >
> > Not sure that understood your point. Yes, implementation that supports this 
> > feature will trigger LSP recalculation on receiving Link-overload sub-TLV, 
> > but will not necessary do so in response to max
> > metric. Former signals that physical/logical link maintenance is planned, 
> > latter - that IGP link property is modified (may be due to planned IGP link 
> > or IGP process maintenance). Two are not always
> > correlate. Ignorance of IGP topology changes from LSP recalculation 
> > perspective could be design intent, and not unsupported feature or 
> > deficiency of particular implementation. In some implementations
> > it could be enabled/disabled by configuration knob. So, even with 
> > introducing support of link-overload implementation is not obligated to 
> > react to IGP topology changes with LSP recalculation. With 'max
> > metric only' approach it is not possible to distinguish whether link metric 
> > was increased due to link overload mode, or due to some other reason.
>
> Are these actual scenarios that really matter or would actually be used
> by an operator? Do you know of operators that wish to perform "IGP link
> maintenance" (not sure how that is different from "link maintenance") on
> a link, that doesn't involve simply removing the link from service?
Yes, I has my own experience with migrating IGP for some operator. We migrated 
from using of single IS-IS instance to multiple instances of IS-IS. As part of 
migration we was moving IGP links (not IP links themselves) from one instance 
to another ones. From IGP point of view this is losing and establishing of 
adjacencies. If other routers trigger RSVP LSP recalculation, their RSVP LSPs 
would be rerouted around maintained router. Fortunately, the implementation 
doesn't consider IGP topology changes as a trigger to make RSVP LSPs 
recalculation, and data plane worked as if there was no IGP maintaining. Notice 
that re-establishing RSVP LSPs (even with MBB procedure) has some negative 
effects, like put additional traffic load on some links (detoured traffic), 
stress CPU on routers, and out-of-ordering (new path is shorter) or delaying 
(new path is longer) packets.
>
> > itself doesn't tell about exact reason for what link metric was
> > increased. It could be result of IGP-LDP synchronization, for example,
> > which is irrespective to TE LSPs. From the other hand, when
> > head-end/controller receives explicit indication (Link-overload), it
> > could interpret it safely as a trigger to reroute LSP, even if
> > overloaded link is only link that satisfies constrains (from CSPF
> > perspective). Otherwise, increased metric could not be enough reason to
> > relax constrains for LSP.
> >
> > But IGP-LDP synchronization happens when a link initially comes up. Is
> > the point then of the new TLV to simply avoid this slight delay on
> > link-up in using the link for TE?
> >
> > Yes, but it is only one of cases. Enabling LDP on link or restarting LDP 
> > process, for example, are other viable triggers for 'max metric'. Also, it 
> > could be that other usage of 'max metric' will be invented in the
> > future.
>
> Max-metric is meant to signal "don't use link if at all possible" nothing
> else, there won't be future use that doesn't mean that as well. You're
> adding another TLV to signal the exact same intent. I don't see the need
> is all.
RFC 5443 states that suboptimal IP traffic forwarding is a consequence of using 
this mechanism. I.e. while we use max-metric to avoid blackholing of traffic on 
LDP LSPs, we are facing unavoidable side effect in that native IP traffic will 
be needlessly rerouted as well. If other routers 

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Christian Hopps]

Alexander Okonnikov  writes:

> Hi Christian,
>
> See inline.
>
> Thank you.
>
> -- Best regards, Alexander Okonnikov
>
> On 21 апр. 2017 г., 18:36 +0300, Christian Hopps , wrote:
>
>  Alexander Okonnikov  writes:
>
>  no argument about the need of area level flooding - Router LSA with
>  the max metric will be flooded within the area.
>
>  I have read the section 7.2 several times, but I still do not
>  understand what is the purpose of the Link-Overload sub-TLV there.
>  What is the controller going to do when it receives the area scoped
>  Link-Overload sub-TLV and how it is different to the case where the
>  link is advertised in the Router LSA with max-metric in both directions?
>
>  The fact that link metric has been maximized could not be a trigger for
>  LSP recalculation. Some implementations consider IGP topology change as
>  a trigger for LSP recalculation, but others - don't. Also, max metric
>
>  But you have to change the code anyway to make a new TLV work, right? So
>  what old code does isn't really relevant, unless I misunderstand things.
>
> Not sure that understood your point. Yes, implementation that supports this 
> feature will trigger LSP recalculation on receiving Link-overload sub-TLV, 
> but will not necessary do so in response to max
> metric. Former signals that physical/logical link maintenance is planned, 
> latter - that IGP link property is modified (may be due to planned IGP link 
> or IGP process maintenance). Two are not always
> correlate. Ignorance of IGP topology changes from LSP recalculation 
> perspective could be design intent, and not unsupported feature or deficiency 
> of particular implementation. In some implementations
> it could be enabled/disabled by configuration knob. So, even with introducing 
> support of link-overload implementation is not obligated to react to IGP 
> topology changes with LSP recalculation. With 'max
> metric only' approach it is not possible to distinguish whether link metric 
> was increased due to link overload mode, or due to some other reason.

Are these actual scenarios that really matter or would actually be used
by an operator? Do you know of operators that wish to perform "IGP link
maintenance" (not sure how that is different from "link maintenance") on
a link, that doesn't involve simply removing the link from service?

>  itself doesn't tell about exact reason for what link metric was
>  increased. It could be result of IGP-LDP synchronization, for example,
>  which is irrespective to TE LSPs. From the other hand, when
>  head-end/controller receives explicit indication (Link-overload), it
>  could interpret it safely as a trigger to reroute LSP, even if
>  overloaded link is only link that satisfies constrains (from CSPF
>  perspective). Otherwise, increased metric could not be enough reason to
>  relax constrains for LSP.
>
>  But IGP-LDP synchronization happens when a link initially comes up. Is
>  the point then of the new TLV to simply avoid this slight delay on
>  link-up in using the link for TE?
>
> Yes, but it is only one of cases. Enabling LDP on link or restarting LDP 
> process, for example, are other viable triggers for 'max metric'. Also, it 
> could be that other usage of 'max metric' will be invented in the
> future.

Max-metric is meant to signal "don't use link if at all possible" nothing
else, there won't be future use that doesn't mean that as well. You're
adding another TLV to signal the exact same intent. I don't see the need
is all.

Thanks,
Chris.

>
>  Thanks,
>  Chris.


signature.asc
Description: PGP signature
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Alexander Okonnikov]

Hi Christian,

See inline.

Thank you.

-- Best regards, Alexander Okonnikov

On 21 апр. 2017 г., 18:36 +0300, Christian Hopps , wrote:
>
> Alexander Okonnikov  writes:
>
> > > no argument about the need of area level flooding - Router LSA with
> > > the max metric will be flooded within the area.
> > >
> > > I have read the section 7.2 several times, but I still do not
> > > understand what is the purpose of the Link-Overload sub-TLV there.
> > > What is the controller going to do when it receives the area scoped
> > > Link-Overload sub-TLV and how it is different to the case where the
> > > link is advertised in the Router LSA with max-metric in both directions?
>
> > The fact that link metric has been maximized could not be a trigger for
> > LSP recalculation. Some implementations consider IGP topology change as
> > a trigger for LSP recalculation, but others - don't. Also, max metric
>
> But you have to change the code anyway to make a new TLV work, right? So
> what old code does isn't really relevant, unless I misunderstand things.
Not sure that understood your point. Yes, implementation that supports this 
feature will trigger LSP recalculation on receiving Link-overload sub-TLV, but 
will not necessary do so in response to max metric. Former signals that 
physical/logical link maintenance is planned, latter - that IGP link property 
is modified (may be due to planned IGP link or IGP process maintenance). Two 
are not always correlate. Ignorance of IGP topology changes from LSP 
recalculation perspective could be design intent, and not unsupported feature 
or deficiency of particular implementation. In some implementations it could be 
enabled/disabled by configuration knob. So, even with introducing support of 
link-overload implementation is not obligated to react to IGP topology changes 
with LSP recalculation. With 'max metric only' approach it is not possible to 
distinguish whether link metric was increased due to link overload mode, or due 
to some other reason.
>
> > itself doesn't tell about exact reason for what link metric was
> > increased. It could be result of IGP-LDP synchronization, for example,
> > which is irrespective to TE LSPs. From the other hand, when
> > head-end/controller receives explicit indication (Link-overload), it
> > could interpret it safely as a trigger to reroute LSP, even if
> > overloaded link is only link that satisfies constrains (from CSPF
> > perspective). Otherwise, increased metric could not be enough reason to
> > relax constrains for LSP.
>
> But IGP-LDP synchronization happens when a link initially comes up. Is
> the point then of the new TLV to simply avoid this slight delay on
> link-up in using the link for TE?
Yes, but it is only one of cases. Enabling LDP on link or restarting LDP 
process, for example, are other viable triggers for 'max metric'. Also, it 
could be that other usage of 'max metric' will be invented in the future.
>
> Thanks,
> Chris.
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Christian Hopps]

Alexander Okonnikov  writes:

>> no argument about the need of area level flooding - Router LSA with
>> the max metric will be flooded within the area.
>>
>> I have read the section 7.2 several times, but I still do not
>> understand what is the purpose of the Link-Overload sub-TLV there.
>> What is the controller going to do when it receives the area scoped
>> Link-Overload sub-TLV and how it is different to the case where the
>> link is advertised in the Router LSA with max-metric in both directions?

> The fact that link metric has been maximized could not be a trigger for
> LSP recalculation. Some implementations consider IGP topology change as
> a trigger for LSP recalculation, but others - don't. Also, max metric

But you have to change the code anyway to make a new TLV work, right? So
what old code does isn't really relevant, unless I misunderstand things.

> itself doesn't tell about exact reason for what link metric was
> increased. It could be result of IGP-LDP synchronization, for example,
> which is irrespective to TE LSPs. From the other hand, when
> head-end/controller receives explicit indication (Link-overload), it
> could interpret it safely as a trigger to reroute LSP, even if
> overloaded link is only link that satisfies constrains (from CSPF
> perspective). Otherwise, increased metric could not be enough reason to
> relax constrains for LSP.

But IGP-LDP synchronization happens when a link initially comes up. Is
the point then of the new TLV to simply avoid this slight delay on
link-up in using the link for TE?

Thanks,
Chris.


signature.asc
Description: PGP signature
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Acee Lindem (acee)]

On 4/21/17, 6:37 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Acee,
>
>
>> I don’t see any need to reference RFC 4203 since the Sub-TLV is
>>sufficiently defined here. This is completely orthogonal to the
>>definition in this draft.
>
>I do not agree with this point. The sub-TLV, local/remote interface id
>requires the  remote interface-id to be filled and the draft refers to an
>existing standard on getting this remote interface id. This is the
>standard mechanism we follow in every draft.

I think we’re back to the circular argument with respect to the gratuitous
repurposing of TE LSAs standardized under to satisfy GMPLS requirements
for every purpose. Even in support of your position, the blanket statement
is not germane to the draft. I might be ok with “One mechanism to learn
the remote-id is described in ….” However, it appears now that we have
broached the subject of WG last call, there is much discussion on the
draft. 

Thanks,
Acee 

>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 7:07 PM
>To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem
><acee.lin...@gmail.com>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha, 
>
>On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>Hi Acee,
>>
>>The draft does not mandate use of RFC 4203. There are no MUST
>>statements associated with the recommendation.
>
>I don’t see any need to reference RFC 4203 since the Sub-TLV is
>sufficiently defined here. This is completely orthogonal to the
>definition in this draft.
>>
>>
>>RFC 4203 is a standard and has been around for a while. I do not
>>understand why there is concern being raised over Referencing an RFC
>>which has been a standard and deployed in the field for many years.
>>
>>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is
>>still an independent draft and it does not make sense to refer this
>>draft in draft-ietf-ospf-link-overload-06 which is ready for WG last
>>call.
>
>I wasn’t suggesting to reference either document.
>
>Thanks,
>Acee
>
>
>>
>>Rgds
>>Shraddha
>>
>>-Original Message-
>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>Sent: Thursday, April 20, 2017 4:02 AM
>>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde
>><shrad...@juniper.net>
>>Cc: ospf@ietf.org
>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>
>>Hi Shraddha,
>>
>>The only non-editorial comment that I have is that the draft references
>>RFC 4203 as the way to learn the remote interface ID on an unnumbered
>>link 
>>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt).
>>As you know, this is a very controversial topic with some of us wanting
>>this to be in the hello packets consistent with OSPFv3 and IS-IS as
>>opposed to using a link-scoped TE Opaque LSA as suggested in the OSPF
>>GMPLS Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I
>>would suggest removing the reference.
>>
>>Thanks,
>>Acee
>>
>>
>>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>>
>>>Hi Shraddha,
>>>
>>>I think this version addresses all my comments. I will do a detailed
>>>review this week and, most likely, start the WG last call. I encourage
>>>other WG members to do the same.
>>>
>>>Thanks,
>>>Acee
>>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>>wrote:
>>>> 
>>>> Hi Acee,
>>>> 
>>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>>remote-ipv4 addr is moved to a new sub-TLV.
>>>> Pls review.
>>>> 
>>>> The authors of the draft believe that draft has undergone multiple
>>>>revisions/reviews and is ready for WG last call.
>>>> 
>>>> Rgds
>>>> Shraddha
>>>> 
>>>> 
>>>> -Original Message-
>>>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>>>(acee)
>>>> Sent: Saturday, March 18, 2017 2:28 AM
>>>> Cc: ospf@ietf.org
>>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>>> 
>>>> Hi Shraddha, et al,
>>>> 
>>>> With respect to section 4.1, I ag

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Peter Psenak]

Hi Alex,

please see inline:

On 21/04/17 14:29 , Alexander Okonnikov wrote:

Hi Peter,

See my comments inline.

Thanks.

21.04.2017 14:17, Peter Psenak пишет:

Hi Shraddha,

please see inline:

On 21/04/17 12:53 , Shraddha Hegde wrote:

Hi Peter,

Thanks for the detailed review. Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee)
<a...@cisco.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to
advertise the link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is
to let "LSP ingress routers/controllers can learn of the impending
maintenance activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a)
results in link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the
treatment of a link that has the Link-Overload sub-TLV? I would
understand the difference if you say that the link having the
Link-Overload sub-TLV must not be used during SPF, but nothing like
that is mentioned in the draft and I understand why.

Is (b) needed to cover the case, where the signaling defined in (a)
is not understood by the neighbor on the other side of the link? If
yes, please state it in the draft.
 Metric alone cannot be used as an indication for impending
maintenance activity. When other nodes like ingress/controller need
to understand the impending maintenance activity, area level
advertisement would be needed. Application specific to this is
described in sec 7.2


no argument about the need of area level flooding - Router LSA with
the max metric will be flooded within the area.

I have read the section 7.2 several times, but I still do not
understand what is the purpose of the Link-Overload sub-TLV there.
What is the controller going to do when it receives the area scoped
Link-Overload sub-TLV and how it is different to the case where the
link is advertised in the Router LSA with max-metric in both directions?

The fact that link metric has been maximized could not be a trigger for
LSP recalculation. Some implementations consider IGP topology change as
a trigger for LSP recalculation, but others - don't. Also, max metric
itself doesn't tell about exact reason for what link metric was
increased. It could be result of IGP-LDP synchronization, for example,
which is irrespective to TE LSPs. From the other hand, when
head-end/controller receives explicit indication (Link-overload), it
could interpret it safely as a trigger to reroute LSP, even if
overloaded link is only link that satisfies constrains (from CSPF
perspective). Otherwise, increased metric could not be enough reason to
relax constrains for LSP.


fair enough.
I would propose authors to include the above reasoning in the draft.

thanks,
Peter






2. For the signaling defined in (a)-  using the Router Information
LSA for signaling something to the direct neighbor is a very dirty
hack. As the name of the LSA says, it has been defined to signal
capability of the node, which has nothing to do with what you are
trying to use it for. We have to stop polluting the protocol with
such hacks. RFC5613 defines a Link-Local Signaling mechanism for OSPF
and that is the one we should use for siganling between neighbors.
  LLS is a good mechanism to use for signaling link level
information that are useful before the adjacency is established.
Section 2 RFC 5613  states that the LLS is not expected to be used
for use-cases which cause routing changes. Link-overload does result
into routing changes and is best handled using link local scope LSAs.


- LLS can be used to signal information prior to adjacency bringup as
well as when the adjacency is FULL state. There are existing LLS TLVs
that are send when adjacency is in FULL state.

- in your case the use of LLS would be to change the metric on the
link in the reverse direction. That is not resulting in any routing
changes directly (look at it as the remote configuration request).
It's the max-metric in the Router LSA that is going to change the
routing. So using LLS to signal what you need is perfectly valid.

I just can not see how we can standardize the use of RI LSA for what
you are proposing to use it - it's completely wrong IMHO.

thanks,
Peter



thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:

Hi Acee,

New version draft-ietf-ospf-link-overload-06 is posted where the
remote-ipv4 addr is moved to a new sub-TLV.
Pls review.

The authors of the draft believe that draft has undergone multiple
revisions/reviews and is ready for WG last call.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Alexander Okonnikov]

Hi Peter,

See my comments inline.

Thanks.

21.04.2017 14:17, Peter Psenak пишет:

Hi Shraddha,

please see inline:

On 21/04/17 12:53 , Shraddha Hegde wrote:

Hi Peter,

Thanks for the detailed review. Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) 
<a...@cisco.com>

Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to 
advertise the link with max-metric from both directions.


b) flooding the Link-Overload sub-TLV inside the area. The purpose is 
to let "LSP ingress routers/controllers can learn of the impending 
maintenance activity"


1. Why do we need two mechanisms? Why is (b) needed, given that (a) 
results in link being advertised with max-metric in both directions?


How is treatement of remote link having max-metric different to the 
treatment of a link that has the Link-Overload sub-TLV? I would 
understand the difference if you say that the link having the 
Link-Overload sub-TLV must not be used during SPF, but nothing like 
that is mentioned in the draft and I understand why.


Is (b) needed to cover the case, where the signaling defined in (a) 
is not understood by the neighbor on the other side of the link? If 
yes, please state it in the draft.
 Metric alone cannot be used as an indication for impending 
maintenance activity. When other nodes like ingress/controller need 
to understand the impending maintenance activity, area level 
advertisement would be needed. Application specific to this is 
described in sec 7.2


no argument about the need of area level flooding - Router LSA with 
the max metric will be flooded within the area.


I have read the section 7.2 several times, but I still do not 
understand what is the purpose of the Link-Overload sub-TLV there. 
What is the controller going to do when it receives the area scoped 
Link-Overload sub-TLV and how it is different to the case where the 
link is advertised in the Router LSA with max-metric in both directions?
The fact that link metric has been maximized could not be a trigger for 
LSP recalculation. Some implementations consider IGP topology change as 
a trigger for LSP recalculation, but others - don't. Also, max metric 
itself doesn't tell about exact reason for what link metric was 
increased. It could be result of IGP-LDP synchronization, for example, 
which is irrespective to TE LSPs. From the other hand, when 
head-end/controller receives explicit indication (Link-overload), it 
could interpret it safely as a trigger to reroute LSP, even if 
overloaded link is only link that satisfies constrains (from CSPF 
perspective). Otherwise, increased metric could not be enough reason to 
relax constrains for LSP.




2. For the signaling defined in (a)-  using the Router Information 
LSA for signaling something to the direct neighbor is a very dirty 
hack. As the name of the LSA says, it has been defined to signal 
capability of the node, which has nothing to do with what you are 
trying to use it for. We have to stop polluting the protocol with 
such hacks. RFC5613 defines a Link-Local Signaling mechanism for OSPF 
and that is the one we should use for siganling between neighbors.
  LLS is a good mechanism to use for signaling link level 
information that are useful before the adjacency is established. 
Section 2 RFC 5613  states that the LLS is not expected to be used 
for use-cases which cause routing changes. Link-overload does result 
into routing changes and is best handled using link local scope LSAs.


- LLS can be used to signal information prior to adjacency bringup as 
well as when the adjacency is FULL state. There are existing LLS TLVs 
that are send when adjacency is in FULL state.


- in your case the use of LLS would be to change the metric on the 
link in the reverse direction. That is not resulting in any routing 
changes directly (look at it as the remote configuration request). 
It's the max-metric in the Router LSA that is going to change the 
routing. So using LLS to signal what you need is perfectly valid.


I just can not see how we can standardize the use of RI LSA for what 
you are proposing to use it - it's completely wrong IMHO.


thanks,
Peter



thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:

Hi Acee,

New version draft-ietf-ospf-link-overload-06 is posted where the 
remote-ipv4 addr is moved to a new sub-TLV.

Pls review.

The authors of the draft believe that draft has undergone multiple 
revisions/reviews and is ready for WG last call.


Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
(acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Peter Psenak]

Hi Shraddha,

please see inline:

On 21/04/17 12:53 , Shraddha Hegde wrote:

Hi Peter,

Thanks for the detailed review. Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to advertise the 
link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to let "LSP 
ingress routers/controllers can learn of the impending maintenance activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) results in 
link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the treatment 
of a link that has the Link-Overload sub-TLV? I would understand the difference 
if you say that the link having the Link-Overload sub-TLV must not be used 
during SPF, but nothing like that is mentioned in the draft and I understand 
why.

Is (b) needed to cover the case, where the signaling defined in (a) is not 
understood by the neighbor on the other side of the link? If yes, please state 
it in the draft.
 Metric alone cannot be used as an indication for impending 
maintenance activity. When other nodes like ingress/controller need to understand the 
impending maintenance activity, area level advertisement would be needed. Application 
specific to this is described in sec 7.2


no argument about the need of area level flooding - Router LSA with the 
max metric will be flooded within the area.


I have read the section 7.2 several times, but I still do not understand 
what is the purpose of the Link-Overload sub-TLV there. What is the 
controller going to do when it receives the area scoped Link-Overload 
sub-TLV and how it is different to the case where the link is advertised 
in the Router LSA with max-metric in both directions?




2. For the signaling defined in (a)-  using the Router Information LSA for 
signaling something to the direct neighbor is a very dirty hack. As the name of 
the LSA says, it has been defined to signal capability of the node, which has 
nothing to do with what you are trying to use it for. We have to stop polluting 
the protocol with such hacks. RFC5613 defines a Link-Local Signaling mechanism 
for OSPF and that is the one we should use for siganling between neighbors.
  LLS is a good mechanism to use for signaling link level information 
that are useful before the adjacency is established. Section 2 RFC 5613  states that 
the LLS is not expected to be used for use-cases which cause routing changes. 
Link-overload does result into routing changes and is best handled using link local 
scope LSAs.


- LLS can be used to signal information prior to adjacency bringup as 
well as when the adjacency is FULL state. There are existing LLS TLVs 
that are send when adjacency is in FULL state.


- in your case the use of LLS would be to change the metric on the link 
in the reverse direction. That is not resulting in any routing changes 
directly (look at it as the remote configuration request). It's the 
max-metric in the Router LSA that is going to change the routing. So 
using LLS to signal what you need is perfectly valid.


I just can not see how we can standardize the use of RI LSA for what you 
are proposing to use it - it's completely wrong IMHO.


thanks,
Peter



thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:

Hi Acee,

New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 
addr is moved to a new sub-TLV.
Pls review.

The authors of the draft believe that draft has undergone multiple 
revisions/reviews and is ready for WG last call.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
(acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, et al,

With respect to section 4.1, I agree that matching link endpoints in
OSPFv2 requires more information. However, this is a general problem
and the remote address should be a separate OSPFv2 Link Attribute LSA
TLV rather than overloading the link overload TLV ;^)

Thanks,
Acee

On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
<ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Shortest Path First IGP of the IETF.

 Title   : OSPF Link Overload
 Authors : Shraddha Hegde
   Pushpasis Sarkar
   Hannes Gr

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Hi Peter,

Thanks for the detailed review. Pls see inline..

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com] 
Sent: Friday, April 21, 2017 1:38 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to advertise the 
link with max-metric from both directions.

b) flooding the Link-Overload sub-TLV inside the area. The purpose is to let 
"LSP ingress routers/controllers can learn of the impending maintenance 
activity"

1. Why do we need two mechanisms? Why is (b) needed, given that (a) results in 
link being advertised with max-metric in both directions?

How is treatement of remote link having max-metric different to the treatment 
of a link that has the Link-Overload sub-TLV? I would understand the difference 
if you say that the link having the Link-Overload sub-TLV must not be used 
during SPF, but nothing like that is mentioned in the draft and I understand 
why.

Is (b) needed to cover the case, where the signaling defined in (a) is not 
understood by the neighbor on the other side of the link? If yes, please state 
it in the draft.
 Metric alone cannot be used as an indication for impending 
maintenance activity. When other nodes like ingress/controller need to 
understand the impending maintenance activity, area level advertisement would 
be needed. Application specific to this is described in sec 7.2

2. For the signaling defined in (a)-  using the Router Information LSA for 
signaling something to the direct neighbor is a very dirty hack. As the name of 
the LSA says, it has been defined to signal capability of the node, which has 
nothing to do with what you are trying to use it for. We have to stop polluting 
the protocol with such hacks. RFC5613 defines a Link-Local Signaling mechanism 
for OSPF and that is the one we should use for siganling between neighbors.
  LLS is a good mechanism to use for signaling link level information 
that are useful before the adjacency is established. Section 2 RFC 5613  states 
that the LLS is not expected to be used for use-cases which cause routing 
changes. Link-overload does result into routing changes and is best handled 
using link local scope LSAs.

thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:
> Hi Acee,
>
> New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 
> addr is moved to a new sub-TLV.
> Pls review.
>
> The authors of the draft believe that draft has undergone multiple 
> revisions/reviews and is ready for WG last call.
>
> Rgds
> Shraddha
>
>
> -Original Message-
> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem 
> (acee)
> Sent: Saturday, March 18, 2017 2:28 AM
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
> Hi Shraddha, et al,
>
> With respect to section 4.1, I agree that matching link endpoints in
> OSPFv2 requires more information. However, this is a general problem 
> and the remote address should be a separate OSPFv2 Link Attribute LSA 
> TLV rather than overloading the link overload TLV ;^)
>
> Thanks,
> Acee
>
> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Open Shortest Path First IGP of the IETF.
>>
>> Title   : OSPF Link Overload
>> Authors : Shraddha Hegde
>>   Pushpasis Sarkar
>>   Hannes Gredler
>>   Mohan Nanduri
>>   Luay Jalil
>>  Filename: draft-ietf-ospf-link-overload-05.txt
>>  Pages   : 13
>>  Date: 2017-02-23
>>
>> Abstract:
>>When a link is being prepared to be taken out of service, the traffic
>>needs to be diverted from both ends of the link.  Increasing the
>>metric to the highest metric on one side of the link is not
>>sufficient to divert the traffic flowing in the other direction.
>>
>>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>>able to advertise a link being in an overload state to indicate
>>impending maintenance activity on the link.  This information can be
>>used by the network devices to re-route the traffic effectively.
>>
>>This document describes the protocol extensions to di

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Acee,


> I don’t see any need to reference RFC 4203 since the Sub-TLV is sufficiently 
> defined here. This is completely orthogonal to the definition in this draft.

I do not agree with this point. The sub-TLV, local/remote interface id requires 
the  remote interface-id to be filled and the draft refers to an existing 
standard on getting this remote interface id. This is the standard mechanism we 
follow in every draft.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, April 20, 2017 7:07 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Hi Acee,
>
>The draft does not mandate use of RFC 4203. There are no MUST 
>statements associated with the recommendation.

I don’t see any need to reference RFC 4203 since the Sub-TLV is sufficiently 
defined here. This is completely orthogonal to the definition in this draft. 
>
>
>RFC 4203 is a standard and has been around for a while. I do not 
>understand why there is concern being raised over Referencing an RFC 
>which has been a standard and deployed in the field for many years.
>
>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is 
>still an independent draft and it does not make sense to refer this 
>draft in draft-ietf-ospf-link-overload-06 which is ready for WG last call.

I wasn’t suggesting to reference either document.

Thanks,
Acee


>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 4:02 AM
>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde 
><shrad...@juniper.net>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha,
>
>The only non-editorial comment that I have is that the draft references 
>RFC 4203 as the way to learn the remote interface ID on an unnumbered 
>link 
>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). 
>As you know, this is a very controversial topic with some of us wanting 
>this to be in the hello packets consistent with OSPFv3 and IS-IS as 
>opposed to using a link-scoped TE Opaque LSA as suggested in the OSPF 
>GMPLS Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I 
>would suggest removing the reference.
>
>Thanks,
>Acee
>
>
>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>
>>Hi Shraddha,
>>
>>I think this version addresses all my comments. I will do a detailed 
>>review this week and, most likely, start the WG last call. I encourage 
>>other WG members to do the same.
>>
>>Thanks,
>>Acee
>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>wrote:
>>> 
>>> Hi Acee,
>>> 
>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>remote-ipv4 addr is moved to a new sub-TLV.
>>> Pls review.
>>> 
>>> The authors of the draft believe that draft has undergone multiple 
>>>revisions/reviews and is ready for WG last call.
>>> 
>>> Rgds
>>> Shraddha
>>> 
>>> 
>>> -Original Message-
>>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>>(acee)
>>> Sent: Saturday, March 18, 2017 2:28 AM
>>> Cc: ospf@ietf.org
>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>> 
>>> Hi Shraddha, et al,
>>> 
>>> With respect to section 4.1, I agree that matching link endpoints in
>>> OSPFv2 requires more information. However, this is a general problem 
>>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>>TLV rather than overloading the link overload TLV ;^)
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>>directories.
>>>> This draft is a work item of the Open Shortest Path First IGP of 
>>>>the IETF.
>>>> 
>>>>   Title   : OSPF Link Overload
>>>>   Authors : Shraddha Hegde
>>>> Pushpasis Sarkar
>>>> Hannes Gredl

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Peter Psenak]

Hi Shraddha,

please find my comments below:

The draft defines two mechanisms:

a) signaling the link overload to the neighbor. The purpose is to 
advertise the link with max-metric from both directions.


b) flooding the Link-Overload sub-TLV inside the area. The purpose is to 
let "LSP ingress routers/controllers can learn of the impending 
maintenance activity"


1. Why do we need two mechanisms? Why is (b) needed, given that (a) 
results in link being advertised with max-metric in both directions?


How is treatement of remote link having max-metric different to the 
treatment of a link that has the Link-Overload sub-TLV? I would 
understand the difference if you say that the link having the 
Link-Overload sub-TLV must not be used during SPF, but nothing like that 
is mentioned in the draft and I understand why.


Is (b) needed to cover the case, where the signaling defined in (a) is 
not understood by the neighbor on the other side of the link? If yes, 
please state it in the draft.



2. For the signaling defined in (a)-  using the Router Information LSA 
for signaling something to the direct neighbor is a very dirty hack. As 
the name of the LSA says, it has been defined to signal capability of 
the node, which has nothing to do with what you are trying to use it 
for. We have to stop polluting the protocol with such hacks. RFC5613 
defines a Link-Local Signaling mechanism for OSPF and that is the one we 
should use for siganling between neighbors.


thanks,
Peter



On 19/04/17 15:08 , Shraddha Hegde wrote:

Hi Acee,

New version draft-ietf-ospf-link-overload-06 is posted where the remote-ipv4 
addr is moved to a new sub-TLV.
Pls review.

The authors of the draft believe that draft has undergone multiple 
revisions/reviews and is ready for WG last call.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, March 18, 2017 2:28 AM
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, et al,

With respect to section 4.1, I agree that matching link endpoints in
OSPFv2 requires more information. However, this is a general problem and the 
remote address should be a separate OSPFv2 Link Attribute LSA TLV rather than 
overloading the link overload TLV ;^)

Thanks,
Acee

On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
<ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Shortest Path First IGP of the IETF.

Title   : OSPF Link Overload
Authors : Shraddha Hegde
  Pushpasis Sarkar
  Hannes Gredler
  Mohan Nanduri
  Luay Jalil
Filename: draft-ietf-ospf-link-overload-05.txt
Pages   : 13
Date: 2017-02-23

Abstract:
   When a link is being prepared to be taken out of service, the traffic
   needs to be diverted from both ends of the link.  Increasing the
   metric to the highest metric on one side of the link is not
   sufficient to divert the traffic flowing in the other direction.

   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
   able to advertise a link being in an overload state to indicate
   impending maintenance activity on the link.  This information can be
   used by the network devices to re-route the traffic effectively.

   This document describes the protocol extensions to disseminate link-
   overload information in OSPFv2 and OSPFv3.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05


Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
.



___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Ketan Talaulikar Talaulikar (ketant)]

Hi Shraddha,

The well-defined mechanism of getting interface-ids in RFC 4203 that you refer 
to is specific to TE applications since it is defined for the GMPLS/TE use-case 
in that RFC. It is not a generic mechanism since it requires use of TE LSAs and 
hence not clean option for use-cases where TE is not in the picture.

The link-overload draft is generic and applicable to both TE and other generic 
use-cases and hence the objection to its referring to a mechanism that is TE 
specific in this draft.

The draft-ppsenak-ospf-lls-interface-id tries to provide a generic option for 
doing the link-id signalling. It does not preclude any implementation from 
using the RFC 4203 based mechanism for doing the same.

I think, I've made my point and will now stop going around in circles on this 
one.

Thanks,
Ketan 

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: 20 April 2017 13:27
To: Ketan Talaulikar Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

OSPF link overload has relevance for TE based applications as well as non-TE 
applications.
So what's the problem in referring a  well-defined mechanism of getting the 
interface-ids?

Can you explain why you are so concerned with referencing a standard RFC 
 which is out there and deployed for so many years?

Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 12:31 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Shraddha,

There are also other applications that your draft lists which are TE 
independent and hence the case for not referring to a specific way for 
signalling interface-ids which is TE specific.

I don't understand why you would be so reluctant to remove a reference which is 
not even central to the topic of the draft?

Thanks,
Ketan

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: 20 April 2017 12:11
To: Ketan Talaulikar Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-ll

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Acee Lindem (acee)]

Hi Shraddha, 

On 4/20/17, 12:46 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Hi Acee,
>
>The draft does not mandate use of RFC 4203. There are no MUST statements
>associated with the recommendation.

I don’t see any need to reference RFC 4203 since the Sub-TLV is
sufficiently defined here. This is completely orthogonal to the definition
in this draft. 
>
>
>RFC 4203 is a standard and has been around for a while. I do not
>understand why there is concern being raised over
>Referencing an RFC which has been a standard and deployed in the field
>for many years.
>
>https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is
>still an independent draft and it does not make sense to refer this draft
>in draft-ietf-ospf-link-overload-06 which is ready for WG last call.

I wasn’t suggesting to reference either document.

Thanks,
Acee


>
>Rgds
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, April 20, 2017 4:02 AM
>To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde
><shrad...@juniper.net>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>
>Hi Shraddha, 
>
>The only non-editorial comment that I have is that the draft references
>RFC 4203 as the way to learn the remote interface ID on an unnumbered
>link 
>(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As
>you know, this is a very controversial topic with some of us wanting this
>to be in the hello packets consistent with OSPFv3 and IS-IS as opposed to
>using a link-scoped TE Opaque LSA as suggested in the OSPF GMPLS
>Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I would
>suggest removing the reference.
>
>Thanks,
>Acee 
>
>
>On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:
>
>>Hi Shraddha,
>>
>>I think this version addresses all my comments. I will do a detailed
>>review this week and, most likely, start the WG last call. I encourage
>>other WG members to do the same.
>>
>>Thanks,
>>Acee
>>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>>wrote:
>>> 
>>> Hi Acee,
>>> 
>>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>>remote-ipv4 addr is moved to a new sub-TLV.
>>> Pls review.
>>> 
>>> The authors of the draft believe that draft has undergone multiple
>>>revisions/reviews and is ready for WG last call.
>>> 
>>> Rgds
>>> Shraddha
>>> 
>>> 
>>> -Original Message-
>>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>>(acee)
>>> Sent: Saturday, March 18, 2017 2:28 AM
>>> Cc: ospf@ietf.org
>>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>>> 
>>> Hi Shraddha, et al,
>>> 
>>> With respect to section 4.1, I agree that matching link endpoints in
>>> OSPFv2 requires more information. However, this is a general problem
>>>and the remote address should be a separate OSPFv2 Link Attribute LSA
>>>TLV rather than overloading the link overload TLV ;^)
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>directories.
>>>> This draft is a work item of the Open Shortest Path First IGP of the
>>>>IETF.
>>>> 
>>>>   Title   : OSPF Link Overload
>>>>   Authors : Shraddha Hegde
>>>> Pushpasis Sarkar
>>>> Hannes Gredler
>>>> Mohan Nanduri
>>>> Luay Jalil
>>>>Filename: draft-ietf-ospf-link-overload-05.txt
>>>>Pages   : 13
>>>>Date: 2017-02-23
>>>> 
>>>> Abstract:
>>>>  When a link is being prepared to be taken out of service, the
>>>> traffic  needs to be diverted from both ends of the link.
>>>> Increasing the  metric to the highest metric on one side of the link
>>>> is not  sufficient to divert the traffic flowing in the other
>>>>direction.
>>>> 
>>>>  It is useful for routers in an OSPFv2 or OSPFv3 routing dom

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

OSPF link overload has relevance for TE based applications as well as non-TE 
applications.
So what's the problem in referring a  well-defined mechanism of getting the 
interface-ids?

Can you explain why you are so concerned with referencing a standard RFC 
 which is out there and deployed for so many years?

Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 12:31 PM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Shraddha,

There are also other applications that your draft lists which are TE 
independent and hence the case for not referring to a specific way for 
signalling interface-ids which is TE specific.

I don't understand why you would be so reluctant to remove a reference which is 
not even central to the topic of the draft?

Thanks,
Ketan

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: 20 April 2017 12:11
To: Ketan Talaulikar Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Peter Psenak]

Hi Shraddha,

please see inline:

On 20/04/17 08:46 , Shraddha Hegde wrote:

Ketan,

Pls see inline..

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com]
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>; 
Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha/Authors,

I would like to share the following comments and feedback on this draft.

1) I did not understand the motivation for the use of link-local scoped RI LSA 
for the link-overload signalling when we have the ability to do so via the TLV 
in the area-scoped Extended Link Attribute LSA. I think it may be a good idea 
(an optimization) to use the TLV in an area-scoped RI LSA to indicate link 
overload for all the router links instead of signalling individually for all 
its links in the Extended Link Attribute LSA - but this is not what the draft 
proposes. So could you explain the reason for the link-local scoped RI LSA TLV 
usage?

  There are many application which may not need an area wide  
indication and a link level indication would be sufficient.
Pls refer section for the applications.

2) The Link Overload TLV is defined with a remote IP address field now. This 
does not seem like a good idea. We have had traditionally certain TLVs in OSPF 
LSAs that describe links i.e. Remote Interface IP address and Link Local/Remote 
Identifiers and cover both numbered and unnumbered links. The 
draft-ppsenak-ospf-te-link-attr-reuse proposed to specifically re-use these 
TLVs so that links may be described correctly in the new extended link 
attribute LSA for generic use-cases such as the Link Overload TLV here. It 
seems rather odd that we are now introducing these fields like remote address 
in individual TLVs and proposing *hacky* encoding of link-ids in the remote IP 
address field for unnumbered links instead of re-using existing well defined 
generic TLVs.
 Pls refer the latest draft draft-ietf-ospf-link-overload-06. New 
sub-tlvs defined for generic use.


these TLVs have been previously defined in 
https://www.ietf.org/id/draft-ppsenak-ospf-te-link-attr-reuse-04.txt, 
please see section 4.1 and 4.2.


thanks,
Peter



3) I am not sure why the reference to use of OSPFv3 extended LSAs for link 
level area-scoped signalling was removed from this version of the draft.
Since OSPFv3 entended LSA hasn't progressed, the WG has decided to 
progress other draft and defer any dependency to a separate document.

4) I also have an objection to the reference of RFC4203 for the procedures for 
obtaining the remote interface-id since that mechanism is outside the scope of 
what this draft is trying to standardize. Specifically, I have a problem since 
it gives an impression that the mechanism described in RFC4203 is *the* 
procedure for obtaining the remote interface-id since that specification is 
very specific to the GMPLS/TE use-cases and it is not a generic/based OSPF 
protocol mechanism. We have proposed an alternate mechanism for doing this in a 
manner consistent with OSPFv3 and ISIS in draft-ppsenak-ospf-lls-interface-id. 
We can debate the need for this mechanism in a separate thread, but the 
reference to RFC4203 does not seem necessary here to me.
This is discussed in other threads.
Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:


Hi Shraddha,

I think this version addresses all my comments. I will do a detailed
review this week and, most likely, start the WG last call. I encourage
other WG members to do the same.

Thanks,
Acee

On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
wrote:

Hi Acee,

New version draft-ietf-ospf-link-overload-06 is posted where the
remote-ipv4 addr is moved to a new sub-TLV.
Pls review.

The authors of the draft believe that draft has undergone multiple
revisions/reviews and is ready for WG last call.

Rgds
Shraddha


-Original Message-
From: OSPF [mailto:ospf-boun...@ietf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Ketan Talaulikar Talaulikar (ketant)]

Shraddha,

There are also other applications that your draft lists which are TE 
independent and hence the case for not referring to a specific way for 
signalling interface-ids which is TE specific.

I don't understand why you would be so reluctant to remove a reference which is 
not even central to the topic of the draft?

Thanks,
Ketan

-Original Message-
From: Shraddha Hegde [mailto:shrad...@juniper.net] 
Sent: 20 April 2017 12:11
To: Ketan Talaulikar Talaulikar (ketant) <ket...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -----Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem 
>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

Pls see inline..

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 10:06 AM
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>; 
Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha/Authors,

I would like to share the following comments and feedback on this draft.

1) I did not understand the motivation for the use of link-local scoped RI LSA 
for the link-overload signalling when we have the ability to do so via the TLV 
in the area-scoped Extended Link Attribute LSA. I think it may be a good idea 
(an optimization) to use the TLV in an area-scoped RI LSA to indicate link 
overload for all the router links instead of signalling individually for all 
its links in the Extended Link Attribute LSA - but this is not what the draft 
proposes. So could you explain the reason for the link-local scoped RI LSA TLV 
usage?

  There are many application which may not need an area wide  
indication and a link level indication would be sufficient.
Pls refer section for the applications.

2) The Link Overload TLV is defined with a remote IP address field now. This 
does not seem like a good idea. We have had traditionally certain TLVs in OSPF 
LSAs that describe links i.e. Remote Interface IP address and Link Local/Remote 
Identifiers and cover both numbered and unnumbered links. The 
draft-ppsenak-ospf-te-link-attr-reuse proposed to specifically re-use these 
TLVs so that links may be described correctly in the new extended link 
attribute LSA for generic use-cases such as the Link Overload TLV here. It 
seems rather odd that we are now introducing these fields like remote address 
in individual TLVs and proposing *hacky* encoding of link-ids in the remote IP 
address field for unnumbered links instead of re-using existing well defined 
generic TLVs.
 Pls refer the latest draft draft-ietf-ospf-link-overload-06. New 
sub-tlvs defined for generic use.

3) I am not sure why the reference to use of OSPFv3 extended LSAs for link 
level area-scoped signalling was removed from this version of the draft.
Since OSPFv3 entended LSA hasn't progressed, the WG has decided to 
progress other draft and defer any dependency to a separate document.

4) I also have an objection to the reference of RFC4203 for the procedures for 
obtaining the remote interface-id since that mechanism is outside the scope of 
what this draft is trying to standardize. Specifically, I have a problem since 
it gives an impression that the mechanism described in RFC4203 is *the* 
procedure for obtaining the remote interface-id since that specification is 
very specific to the GMPLS/TE use-cases and it is not a generic/based OSPF 
protocol mechanism. We have proposed an alternate mechanism for doing this in a 
manner consistent with OSPFv3 and ISIS in draft-ppsenak-ospf-lls-interface-id. 
We can debate the need for this mechanism in a separate thread, but the 
reference to RFC4203 does not seem necessary here to me.
This is discussed in other threads.
Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-----
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
&g

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Ketan,

We do have traffic engineering applications that require link-overload 
functionality.
Pls refer section 7.2.


Rgds
Shraddha

-Original Message-
From: Ketan Talaulikar Talaulikar (ketant) [mailto:ket...@cisco.com] 
Sent: Thursday, April 20, 2017 10:46 AM
To: Shraddha Hegde <shrad...@juniper.net>; Acee Lindem (acee) <a...@cisco.com>; 
Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: RE: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha,

The RFC 4203 describes the usage and application of TE LSAs for GMPLS/TE use 
cases. The OSPF link overload RFC is independent of TE and hence it is a 
concern that an implementation needs to use TE LSAs with link-local scope just 
for signalling the interface-ids for unnumbered links.

Not asking for reference to draft-ppsenak-ospf-lls-interface-id. Just asking to 
remove reference to RFC 4203 since the mechanism for signalling interface-ids 
is orthogonal to the subject of the draft which is generic to OSPF and 
independent of any TE/GMPLS use-case(s).

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: 20 April 2017 10:17
To: Acee Lindem (acee) <a...@cisco.com>; Acee Lindem <acee.lin...@gmail.com>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over Referencing an RFC which has been a standard 
and deployed in the field for many years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft in 
draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -----Original Message-----
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem 
>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>directories.
>>> This draft is a work item of the Open Shortest Path First IGP of the 
>>>IETF.
>>> 
>>>   Title   : OSPF Link Overload
>>>   Authors : Shraddha Hegde
>>> Pushpasis Sarkar
>>> Hannes Gredler
>>> Mohan Nanduri
>>>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Shraddha Hegde]

Hi Acee,

The draft does not mandate use of RFC 4203. There are no MUST statements 
associated with the recommendation.


RFC 4203 is a standard and has been around for a while. I do not understand why 
there is concern being raised over
Referencing an RFC which has been a standard and deployed in the field for many 
years.

https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt is still an 
independent draft and it does not make sense to refer this draft
in draft-ietf-ospf-link-overload-06 which is ready for WG last call.

Rgds
Shraddha

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Thursday, April 20, 2017 4:02 AM
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references RFC 
4203 as the way to learn the remote interface ID on an unnumbered link 
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As you 
know, this is a very controversial topic with some of us wanting this to be in 
the hello packets consistent with OSPFv3 and IS-IS as opposed to using a 
link-scoped TE Opaque LSA as suggested in the OSPF GMPLS Extensions RFC 
(https://www.rfc-editor.org/rfc/rfc4203.txt). I would suggest removing the 
reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha,
>
>I think this version addresses all my comments. I will do a detailed 
>review this week and, most likely, start the WG last call. I encourage 
>other WG members to do the same.
>
>Thanks,
>Acee
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple 
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem 
>>and the remote address should be a separate OSPFv2 Link Attribute LSA 
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts  
>>>directories.
>>> This draft is a work item of the Open Shortest Path First IGP of the 
>>>IETF.
>>> 
>>>   Title   : OSPF Link Overload
>>>   Authors : Shraddha Hegde
>>> Pushpasis Sarkar
>>> Hannes Gredler
>>> Mohan Nanduri
>>> Luay Jalil
>>> Filename: draft-ietf-ospf-link-overload-05.txt
>>> Pages   : 13
>>> Date: 2017-02-23
>>> 
>>> Abstract:
>>>  When a link is being prepared to be taken out of service, the 
>>> traffic  needs to be diverted from both ends of the link.  
>>> Increasing the  metric to the highest metric on one side of the link 
>>> is not  sufficient to divert the traffic flowing in the other direction.
>>> 
>>>  It is useful for routers in an OSPFv2 or OSPFv3 routing domain to 
>>> be  able to advertise a link being in an overload state to indicate  
>>> impending maintenance activity on the link.  This information can be  
>>> used by the network devices to re-route the traffic effectively.
>>> 
>>>  This document describes the protocol extensions to disseminate 
>>> link-  overload information in OSPFv2 and OSPFv3.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05
>>> 
>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Ketan Talaulikar Talaulikar (ketant)]

Hi Shraddha/Authors,

I would like to share the following comments and feedback on this draft.

1) I did not understand the motivation for the use of link-local scoped RI LSA 
for the link-overload signalling when we have the ability to do so via the TLV 
in the area-scoped Extended Link Attribute LSA. I think it may be a good idea 
(an optimization) to use the TLV in an area-scoped RI LSA to indicate link 
overload for all the router links instead of signalling individually for all 
its links in the Extended Link Attribute LSA - but this is not what the draft 
proposes. So could you explain the reason for the link-local scoped RI LSA TLV 
usage?

2) The Link Overload TLV is defined with a remote IP address field now. This 
does not seem like a good idea. We have had traditionally certain TLVs in OSPF 
LSAs that describe links i.e. Remote Interface IP address and Link Local/Remote 
Identifiers and cover both numbered and unnumbered links. The 
draft-ppsenak-ospf-te-link-attr-reuse proposed to specifically re-use these 
TLVs so that links may be described correctly in the new extended link 
attribute LSA for generic use-cases such as the Link Overload TLV here. It 
seems rather odd that we are now introducing these fields like remote address 
in individual TLVs and proposing *hacky* encoding of link-ids in the remote IP 
address field for unnumbered links instead of re-using existing well defined 
generic TLVs.

3) I am not sure why the reference to use of OSPFv3 extended LSAs for link 
level area-scoped signalling was removed from this version of the draft.

4) I also have an objection to the reference of RFC4203 for the procedures for 
obtaining the remote interface-id since that mechanism is outside the scope of 
what this draft is trying to standardize. Specifically, I have a problem since 
it gives an impression that the mechanism described in RFC4203 is *the* 
procedure for obtaining the remote interface-id since that specification is 
very specific to the GMPLS/TE use-cases and it is not a generic/based OSPF 
protocol mechanism. We have proposed an alternate mechanism for doing this in a 
manner consistent with OSPFv3 and ISIS in draft-ppsenak-ospf-lls-interface-id. 
We can debate the need for this mechanism in a separate thread, but the 
reference to RFC4203 does not seem necessary here to me.

Thanks,
Ketan

-Original Message-
From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 April 2017 04:02
To: Acee Lindem <acee.lin...@gmail.com>; Shraddha Hegde <shrad...@juniper.net>
Cc: ospf@ietf.org
Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references
RFC 4203 as the way to learn the remote interface ID on an unnumbered link
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As
you know, this is a very controversial topic with some of us wanting this
to be in the hello packets consistent with OSPFv3 and IS-IS as opposed to
using a link-scoped TE Opaque LSA as suggested in the OSPF GMPLS
Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I would
suggest removing the reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha, 
>
>I think this version addresses all my comments. I will do a detailed
>review this week and, most likely, start the WG last call. I encourage
>other WG members to do the same.
>
>Thanks,
>Acee 
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem
>>and the remote address should be a separate OSPFv2 Link Attribute LSA
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Acee Lindem (acee)]

Hi Shraddha, 

The only non-editorial comment that I have is that the draft references
RFC 4203 as the way to learn the remote interface ID on an unnumbered link
(https://www.ietf.org/id/draft-ppsenak-ospf-lls-interface-id-00.txt). As
you know, this is a very controversial topic with some of us wanting this
to be in the hello packets consistent with OSPFv3 and IS-IS as opposed to
using a link-scoped TE Opaque LSA as suggested in the OSPF GMPLS
Extensions RFC (https://www.rfc-editor.org/rfc/rfc4203.txt). I would
suggest removing the reference.

Thanks,
Acee 


On 4/19/17, 9:11 AM, "Acee Lindem" <acee.lin...@gmail.com> wrote:

>Hi Shraddha, 
>
>I think this version addresses all my comments. I will do a detailed
>review this week and, most likely, start the WG last call. I encourage
>other WG members to do the same.
>
>Thanks,
>Acee 
>> On Apr 19, 2017, at 9:08 AM, Shraddha Hegde <shrad...@juniper.net>
>>wrote:
>> 
>> Hi Acee,
>> 
>> New version draft-ietf-ospf-link-overload-06 is posted where the
>>remote-ipv4 addr is moved to a new sub-TLV.
>> Pls review.
>> 
>> The authors of the draft believe that draft has undergone multiple
>>revisions/reviews and is ready for WG last call.
>> 
>> Rgds
>> Shraddha
>> 
>> 
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
>> Sent: Saturday, March 18, 2017 2:28 AM
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt
>> 
>> Hi Shraddha, et al,
>> 
>> With respect to section 4.1, I agree that matching link endpoints in
>> OSPFv2 requires more information. However, this is a general problem
>>and the remote address should be a separate OSPFv2 Link Attribute LSA
>>TLV rather than overloading the link overload TLV ;^)
>> 
>> Thanks,
>> Acee
>> 
>> On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
>> <ospf-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Open Shortest Path First IGP of the
>>>IETF.
>>> 
>>>   Title   : OSPF Link Overload
>>>   Authors : Shraddha Hegde
>>> Pushpasis Sarkar
>>> Hannes Gredler
>>> Mohan Nanduri
>>> Luay Jalil
>>> Filename: draft-ietf-ospf-link-overload-05.txt
>>> Pages   : 13
>>> Date: 2017-02-23
>>> 
>>> Abstract:
>>>  When a link is being prepared to be taken out of service, the traffic
>>>  needs to be diverted from both ends of the link.  Increasing the
>>>  metric to the highest metric on one side of the link is not
>>>  sufficient to divert the traffic flowing in the other direction.
>>> 
>>>  It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>>>  able to advertise a link being in an overload state to indicate
>>>  impending maintenance activity on the link.  This information can be
>>>  used by the network devices to re-route the traffic effectively.
>>> 
>>>  This document describes the protocol extensions to disseminate link-
>>>  overload information in OSPFv2 and OSPFv3.
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> OSPF mailing list
>>> OSPF@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ospf
>> 
>> ___
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>> 
>> ___
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www.ietf.org/mailman/listinfo/ospf
>

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-05.txt

[Acee Lindem (acee)]

Hi Shraddha, et al,

With respect to section 4.1, I agree that matching link endpoints in
OSPFv2 requires more information. However, this is a general problem and
the remote address should be a separate OSPFv2 Link Attribute LSA TLV
rather than overloading the link overload TLV ;^)

Thanks,
Acee

On 2/23/17, 11:18 AM, "OSPF on behalf of internet-dra...@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Open Shortest Path First IGP of the IETF.
>
>Title   : OSPF Link Overload
>Authors : Shraddha Hegde
>  Pushpasis Sarkar
>  Hannes Gredler
>  Mohan Nanduri
>  Luay Jalil
>   Filename: draft-ietf-ospf-link-overload-05.txt
>   Pages   : 13
>   Date: 2017-02-23
>
>Abstract:
>   When a link is being prepared to be taken out of service, the traffic
>   needs to be diverted from both ends of the link.  Increasing the
>   metric to the highest metric on one side of the link is not
>   sufficient to divert the traffic flowing in the other direction.
>
>   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be
>   able to advertise a link being in an overload state to indicate
>   impending maintenance activity on the link.  This information can be
>   used by the network devices to re-route the traffic effectively.
>
>   This document describes the protocol extensions to disseminate link-
>   overload information in OSPFv2 and OSPFv3.
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-ospf-link-overload-05
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-link-overload-05
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf