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?

<Shraddha>  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.
<Shraddha> 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.
<Shraddha>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.
<Shraddha>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)
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

_______________________________________________
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

Reply via email to