Re: [OSPF] [Editorial Errata Reported] RFC2328 (5269)

[Acee Lindem (acee)]

I recommend we reject this Errata as it is very weak even from an editorial 
standpoint. We certainly don't want to clutter the Errata system with such 
minutiae. 

Thanks,
Acee

On 3/1/18, 10:07 AM, "RFC Errata System"  wrote:

The following errata report has been submitted for RFC2328,
"OSPF Version 2".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5269

--
Type: Editorial
Reported by: Angelos Vassiliou 

Section: 9.1

Original Text
-
The interface is to a broadcast or NBMA network on which another router has 
been selected to be the Designated Router.

Corrected Text
--
The interface is connected to a broadcast or NBMA network on which another 
router has been selected to be the Designated Router.

Notes
-


Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC2328 (no draft string recorded)
--
Title   : OSPF Version 2
Publication Date: April 1998
Author(s)   : J. Moy
Category: INTERNET STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG


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

Re: [OSPF] ospf - Cancelling a meeting request for IETF 101

[Acee Lindem (acee)]

Note that we are still meeting at IETF 101 - only under the new LSR WG. 

Thanks,
Acee 

On 2/8/18, 2:39 PM, "IETF Meeting Session Request Tool" 
 wrote:



A request to cancel a meeting session has just been submitted by Cindy 
Morgan, on behalf of the ospf working group.



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

Re: [OSPF] Experimental support of OSPFv2 Segment Routing in Free Range Routing

[Acee Lindem (acee)]

Hi Olivier,

Great news Olivier! I’m hoping you are looking at OSPFv3 Extended LSAs and 
OSPFv3 SR as well.

Thanks,
Acee

From: OSPF  on behalf of Olivier Dugeon 

Date: Tuesday, February 6, 2018 at 3:13 PM
To: SPRING WG List , OSPF WG List 
Subject: [OSPF] Experimental support of OSPFv2 Segment Routing in Free Range 
Routing

Hi all,

We are please to announce that we have added Experimental support of OSPF SR
(draft-ietf-ospf-segment-routing-extensions-24) in Free Range Routing
protocol suite https://frrouting.org

This feature is available on the master branch: https://github.com/FRRouting/frr
and will be part of the future 4.0 release.

Supported Features:

* Automatic computation of Primary and Backup Adjacency SID with
Cisco experimental remote IP address
* SRGB configuration
* Prefix configuration for Node SID with optional NO-PHP flag (Linux
kernel support both mode)
* Node MSD configuration (with Linux Kernel >= 4.10 a maximum of 32 labels
could be stack)
* Automatic provisioning of MPLS table
* Static route configuration with label stack up to 32 labels

Interoperability:
* tested on various topology including point-to-point and LAN interfaces
in a mix of Free Range Routing instance and Cisco IOS-XR 6.0.x
* check OSPF LSA conformity with latest wireshark release 2.5.0-rc

Known limitations

* Runs only within default VRF
* Only single Area is supported. ABR is not yet supported
* Only SPF algorithm is supported
* Extended Prefix Range is not supported
* MPLS table are not flush at startup. Thus, restarting zebra process is
  mandatory to remove old MPLS entries in the data plane after a crash of
  ospfd daemon
* With NO Penultimate Hop Popping, it is not possible to express a Segment
  Path with an Adjacency SID due to the impossibility for the Linux Kernel to
  perform double POP instruction.

For details implementation & instructions on how to use this new feature,
please consult doc/OSPF-SR.rst.

Regards

FRR team




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

Re: [OSPF] I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt

[Acee Lindem (acee)]

Hi Balaji,

I guess you have NOT been following the OSPF mailing list… The whole point of 
the draft is to NOT require OSPF TE LSAs when RSVP traffic engineering in not 
active – fewer LSAs to correlate is better.

Please review the archives.

https://datatracker.ietf.org/wg/ospf/archives/

Hope this helps,
Acee

From: Balaji venkat Venkataswami 
Date: Wednesday, January 31, 2018 at 11:11 AM
To: OSPF WG List , "Peter Psenak (ppsenak)" , 
Acee Lindem 
Subject: Fwd: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt

Hi Peter, Acee,

In section 2 in your proposal, you have specified as follows.



1.  Remote Interface IP address [RFC3630] - OSPFv2 currently cannot

   distinguish between parallel links between two OSPFv2 routers.

   As a result, the two-way connectivity check performed during SPF

   may succeed when the two routers disagree on which of the links

   to use for data traffic.
Though your intention was to say that Remote Interface IP address is a 
Link-attribute that would
be useful to non-MPLS-TE and non-GMPLS applications, it comes across in this 
para that the
parallel-links identification problem still exists in OSPFv2 inspite of RFC 
3630 specs for this
TLV. Its just a cosmetic issue but for a newbie looking at the draft, it takes 
the conclusion too
seriously.

RFC 3630 appropriate extract.

2.5.4.  Remote Interface IP 
Address





   The Remote Interface IP Address sub-TLV specifies the IP address(es)

   of the neighbor's interface corresponding to this link.  This and the

   local address are used to discern multiple parallel links between

   systems.  If the Link Type of the link is Multi-access, the Remote

   Interface IP Address is set to 0.0.0.0; alternatively, an

   implementation MAY choose not to send this sub-TLV.



   The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N

   octets in length, where N is the number of neighbor addresses.


Just a small correction needed. That RFC 3630 got rid of the problem and that 
it still doesnt persist.

thanks and regards,
balaji venkat

-- Forwarded message --
From: >
Date: Tue, Jan 30, 2018 at 6:41 PM
Subject: I-D Action: draft-ietf-ospf-te-link-attr-reuse-03.txt
To: i-d-annou...@ietf.org
Cc: ospf@ietf.org



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 WG of the IETF.

Title   : OSPFv2 Link Traffic Engineering (TE) Attribute Reuse
Authors : Peter Psenak
  Acee Lindem
  Les Ginsberg
  Wim Henderickx
  Jeff Tantsura
  Hannes Gredler
  John Drake
Filename: draft-ietf-ospf-te-link-attr-reuse-03.txt
Pages   : 16
Date: 2018-01-30

Abstract:
   Various link attributes have been defined in OSPFv2 in the context of
   the MPLS Traffic Engineering (TE) and GMPLS.  Many of these link
   attributes can be used for purposes other than MPLS Traffic
   Engineering or GMPLS.  This documents defines how to distribute such
   attributes in OSPFv2 for applications other than MPLS Traffic
   Engineering or GMPLS purposes.
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Acee Lindem (acee)]

Hi Martin,
That works. 
Thanks,
Acee 

On 2/1/18, 5:15 PM, "Martin Bjorklund" <m...@tail-f.com> wrote:

Hi,

The second argument must be a string, so you should add quotes:

  must "derived-from( "
 + "/rt:routing/rt:control-plane-protocols/"
 + "rt:control-plane-protocol[rt:name=current()]/"
 + "rt:type, 'ospf:ospf-protocol')";
-^------^   


/martin


"Acee Lindem (acee)" <a...@cisco.com> wrote:
> Martin, Lada,
> 
> I believe this got lost with all the discussion of schema mount/yang
> library during roughly the same time frame.  You have both advocated
> using derived-from()/dervived-from-or-self() for ietf-ospf.yang
> checking. However, either I have misinterpreted the RFC 7950
> description of these YANG functions or the yangvalidator validation is
> broken. Please see below.
> 
> Thanks,
> Acee 
> 
> On 1/22/18, 1:42 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
> 
> Hi Martin, Lada, 
> 
> In experimenting with this, I get YANGLINT validation errors. I’m not
> sure what I’m missing but the first argument to
> derived-from()/derive-from-or-self() is the schema node and the second
> is the identity – correct?
> For example, the following YANG leaf:
> 
> identity ospf-protocol {
> base "rt:routing-protocol";
> description "Any version the OSPF protocol";
>   }
> 
>   identity ospfv2 {
> base "ospf-protocol";
> description "OSPFv2";
>   }
> 
>   identity ospfv3 {
> base "ospf-protocol";
> description "OSPFv3";
>   }
> 
> leaf routing-protocol-name {
>   type leafref {
> path "/rt:routing/rt:control-plane-protocols/"
>+ "rt:control-plane-protocol/rt:name";
>   }
>   must "derived-from( "
>   + "/rt:routing/rt:control-plane-protocols/"
> + "rt:control-plane-protocol[rt:name=current()]/"
> + "rt:type, ospf:ospf-protocol)";
>   description
>"OSPF routing protocol instance name.";
> }
> 
> Gives me: 
> 
> warn: Schema node "ietf-ospf:ospf-protocol" not found (derived-from(
> 
/ietf-routing:routing/ietf-routing:control-plane-protocols/ietf-routing:control-plane-protocol[ietf-routing:name=current()]/ietf-routing:type,
> ietf-ospf:ospf-protocol) with context node
> "/ietf-ospf:if-state-change/routing-protocol-name".
> 
> Thanks
> Acee 
> 
> On 1/10/18, 4:36 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:
> 
> Hi,
> 
> I think we can agree that the model in this I-D should use
> derived-from-or-self() instead of string comparison, and conclude 
this
> discussion here.  I suggest that if we need to further discuss the
> representation of identityrefs, then we start a new thred on the
> NETMOD ML.
> 
> 
> /martin
> 
> 
> 
> Ladislav Lhotka <lho...@nic.cz> wrote:
> > On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote:
> > > 
> > > > > Hi,
> > > 
    >     > > > > 
> > > 
> > > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > 
> > > > > > Hi Acee,
> > > 
> > > > > 
> > > 
> > > > > > 
> > > 
> > > > > 
> > > 
> > > > > > please see inline.
> > > 
> > > > > 
> > > 
> > > > > > 
> &

Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Acee Lindem (acee)]

P.S. BGP-LS Link Attributes should not be confused with BGP attributes…
Thanks
Acee s

From: Acee Lindem 
Date: Thursday, February 1, 2018 at 5:42 PM
To: Alvaro Retana , Shraddha Hegde 
, The IESG 
Cc: "draft-ietf-ospf-link-overl...@ietf.org" 
, "ospf-cha...@ietf.org" 
, OSPF WG List 
Subject: Re: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

Hi Alvaro,

From: Alvaro Retana 
Date: Thursday, February 1, 2018 at 5:17 PM
To: Shraddha Hegde , The IESG 
Cc: Acee Lindem , "draft-ietf-ospf-link-overl...@ietf.org" 
, "ospf-cha...@ietf.org" 
, OSPF WG List 
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

On January 30, 2018 at 11:43:53 PM, Shraddha Hegde 
(shrad...@juniper.net) wrote:

...
(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is 
defined" for BGP-LS, but there are no details on the format, etc. The IANA 
Considerations section suggests a value, not for a TLV but for an NLRI Type!
 OK. Refered section 3.1 of RFC 7752 and described the contents of 
the TLV
IANA section seems ok to me. Could you be more specific what needs to change?


BGP-LS Link NLRI Registry [RFC7752] >>>Registry

i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>TLV type

Maybe it’s just me and I just don’t understand…which is completely possible.  
There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.  
This TLV (based on the updated description) has no information in it.  How does 
the receiver know which link the sender is referring to?

It is a  BGP-LS link attribute so the link is identified in the link 
identifiers in the corresponding NLRI. This wasn’t apparent until the IANA 
description was fixed.

Thanks,

Acee






Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating 
where to carry them so that there is an obvious indication of which link is 
being shutdown.  I would like to see explicitly specified how the receiver 
associates this TLV with the appropriate link.  Again, I may be missing the 
details.



(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types" registry, 
not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 
Attribute TLVs” register, which is where I would have assumed a modifier to the 
link would reside.  IOW, according to the registry you are defining a new NLRI 
Type, not a new TLV — and, according to the updated description in the document 
there’s no information in this NLRI.

 The TLV code point registration should be in “BGP-LS Node 
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” I have 
corrected this in the document.

Will e-mail to IANA for correction as well.

Does that answer your concerns?

That addresses the concern #2 above.  I still don’t see anywhere how the 
receiver associates this (empty) TLV with the right link.

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

Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

[Acee Lindem (acee)]

Hi Alvaro,

From: Alvaro Retana 
Date: Thursday, February 1, 2018 at 5:17 PM
To: Shraddha Hegde , The IESG 
Cc: Acee Lindem , "draft-ietf-ospf-link-overl...@ietf.org" 
, "ospf-cha...@ietf.org" 
, OSPF WG List 
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: 
(with COMMENT)

On January 30, 2018 at 11:43:53 PM, Shraddha Hegde 
(shrad...@juniper.net) wrote:

...
(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is 
defined" for BGP-LS, but there are no details on the format, etc. The IANA 
Considerations section suggests a value, not for a TLV but for an NLRI Type!
 OK. Refered section 3.1 of RFC 7752 and described the contents of 
the TLV
IANA section seems ok to me. Could you be more specific what needs to change?


BGP-LS Link NLRI Registry [RFC7752] >>>Registry

i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>TLV type

Maybe it’s just me and I just don’t understand…which is completely possible.  
There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.  
This TLV (based on the updated description) has no information in it.  How does 
the receiver know which link the sender is referring to?

It is a  BGP-LS link attribute so the link is identified in the link 
identifiers in the corresponding NLRI. This wasn’t apparent until the IANA 
description was fixed.

Thanks,

Acee





Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating 
where to carry them so that there is an obvious indication of which link is 
being shutdown.  I would like to see explicitly specified how the receiver 
associates this TLV with the appropriate link.  Again, I may be missing the 
details.



(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types" registry, 
not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 
Attribute TLVs” register, which is where I would have assumed a modifier to the 
link would reside.  IOW, according to the registry you are defining a new NLRI 
Type, not a new TLV — and, according to the updated description in the document 
there’s no information in this NLRI.

 The TLV code point registration should be in “BGP-LS Node 
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” I have 
corrected this in the document.

Will e-mail to IANA for correction as well.

Does that answer your concerns?

That addresses the concern #2 above.  I still don’t see anywhere how the 
receiver associates this (empty) TLV with the right link.

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

Re: [OSPF] [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Acee Lindem (acee)]

Hi Martin, 
Please see my example of the yangvalidator not working - we can't use these 
YANG 1.1 functions until this is resolved. 
Thanks,
Acee 

On 1/10/18, 4:36 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:

Hi,

I think we can agree that the model in this I-D should use
derived-from-or-self() instead of string comparison, and conclude this
discussion here.  I suggest that if we need to further discuss the
representation of identityrefs, then we start a new thred on the
NETMOD ML.


/martin



Ladislav Lhotka <lho...@nic.cz> wrote:
> On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote:
> > 
> > > > Hi,
> > 
> > > > 
> > 
> > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > 
> > > > > Hi Acee,
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
    > > 
> > > > > please see inline.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > On Mon, 2018-01-08 at 19:28 +, Acee Lindem (acee) wrote:
> > 
> > > > 
> > 
> > > > > > Hi Lada,
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Apologies for the delay. We somewhat got hung up on 4 and 6. See
> > inline.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > > Reviewer: Ladislav Lhotka
> > 
> > > > 
> > 
> > > > > > > Review result: Ready with Issues
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > ...
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > > > 
> > 
> > > > 
> > 
> > > > > > > 3. Maybe the draft could mention that implementations should 
supply
> > a
> > 
> > > > 
> > 
> > > > > > >   default routing domain as a system-controlled resource.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Isn’t this more of an RFC8022BIS statement? I guess we could 
state
> > this as
> > 
> > > > 
> > 
> > > > > > an assumption.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > Probably, but it is not a YANG issue, so I'd leave it to you 
routing
> > folks
> > 
> > > > to
> > 
> > > > 
> > 
> > > > > decide.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > >  
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > > 4. In "when" expressions, the module uses literal strings for
> > 
> > > > 
> > 
> > > > > > >   identities. This is known to be problematic, the XPath 
functions
> > 
> > > > 
> > 
> > > > > > >   derived-from() or derived-from-or-self() should be used 
instead.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Why is this problematic? Is it because the types can be 
extended?
> > 
> > > > 
> > 
> > > > > 
> > 
> > >

Re: [OSPF] [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Acee Lindem (acee)]

Martin, Lada,

I believe this got lost with all the discussion of schema mount/yang library 
during roughly the same time frame.  You have both advocated using 
derived-from()/dervived-from-or-self() for ietf-ospf.yang checking. However, 
either I have misinterpreted the RFC 7950 description of these YANG functions 
or the yangvalidator validation is broken. Please see below. 

Thanks,
Acee 

On 1/22/18, 1:42 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

Hi Martin, Lada, 

In experimenting with this, I get YANGLINT validation errors. I’m not sure 
what I’m missing but the first argument to derived-from()/derive-from-or-self() 
is the schema node and the second is the identity – correct?
For example, the following YANG leaf:

identity ospf-protocol {
base "rt:routing-protocol";
description "Any version the OSPF protocol";
  }

  identity ospfv2 {
base "ospf-protocol";
description "OSPFv2";
  }

  identity ospfv3 {
base "ospf-protocol";
description "OSPFv3";
  }

leaf routing-protocol-name {
  type leafref {
path "/rt:routing/rt:control-plane-protocols/"
   + "rt:control-plane-protocol/rt:name";
  }
  must "derived-from( "
+ "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol[rt:name=current()]/"
+ "rt:type, ospf:ospf-protocol)";
  description
   "OSPF routing protocol instance name.";
}

Gives me: 

warn: Schema node "ietf-ospf:ospf-protocol" not found (derived-from( 
/ietf-routing:routing/ietf-routing:control-plane-protocols/ietf-routing:control-plane-protocol[ietf-routing:name=current()]/ietf-routing:type,
 ietf-ospf:ospf-protocol) with context node 
"/ietf-ospf:if-state-change/routing-protocol-name".

Thanks
Acee 

On 1/10/18, 4:36 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:

Hi,

I think we can agree that the model in this I-D should use
derived-from-or-self() instead of string comparison, and conclude this
discussion here.  I suggest that if we need to further discuss the
representation of identityrefs, then we start a new thred on the
NETMOD ML.


/martin



Ladislav Lhotka <lho...@nic.cz> wrote:
> On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote:
> > 
> > > > Hi,
> > 
> > > > 
> > 
> > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > 
> > > > > Hi Acee,
    > > 
    > > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > please see inline.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > On Mon, 2018-01-08 at 19:28 +, Acee Lindem (acee) wrote:
> > 
> > > > 
> > 
> > > > > > Hi Lada,
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Apologies for the delay. We somewhat got hung up on 4 and 
6. See
> > inline.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lho...@nic.cz> 
wrote:
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > > Reviewer: Ladislav Lhotka
> > 
> > > > 
> > 
> > > > > > > Review result: Ready with Issues
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > ...
> > 
> > > > 
> > 
> > > > > 
&g

[OSPF] Early Allocations for "OSPFv3 Extensions for Segment Routing" - draft-ietf-ospf-ospfv3-segment-routing-extensions-11

[Acee Lindem (acee)]

Hi Amanda, et al,

The OSPF WG would like to request early allocations for the subject draft.

These are specified in Section 8 of the draft:

8.1.  OSPFv3 Extend-LSA TLV Registry

   Following values are allocated:

   o suggested value 9 - OSPFv3 Extended Prefix Range TLV

8.2.  OSPFv3 Extend-LSA Sub-TLV registry

   o 4 - Prefix SID Sub-TLV

   o 5 - Adj-SID Sub-TLV

   o 6 - LAN Adj-SID Sub-TLV

   o 7 - SID/Label Sub-TLV

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

Re: [OSPF] [IANA #1047782] Protocol Action: 'OSPFv3 LSA Extendibility' to Proposed Standard (draft-ietf-ospf-ospfv3-lsa-extend-23.txt)

[Acee Lindem (acee)]

Hi Peter, 

Good point, we have OSPFv3 SR implementations and don't want the code points 
used. 

Thanks
Acee

On 2/1/18, 4:02 AM, "Peter Psenak (ppsenak)" <ppse...@cisco.com> wrote:

Hi Acee,

as a next step, can you please ask for a early IANA allocation from the 
new registries as specified in section 8 of 
draft-ietf-ospf-ospfv3-segment-routing-extensions-11.txt

thanks,
Peter

On 01/02/18 00:04 , Acee Lindem (acee) wrote:
> Hi Amanda,
>
> This is correct.
>
> Thanks
> Acee
>
> On 1/31/18, 5:12 PM, "Amanda Baber via RT" <drafts-appro...@iana.org> 
wrote:
>
>  Hi Acee,
>
>  I apologize for my oversight. There's no problem with placing the 
registrations in Section 2.
>
>  Can you confirm that this action has been completed correctly?
>
>  ACTION 4
>
>  We've registered the following OSPFv3 LSA Function Codes:
>
>  33   E-Router-LSA[RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  34   E-Network-LSA   [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  35   E-Inter-Area-Prefix-LSA [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  36   E-Inter-Area-Router-LSA [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  37   E-AS-External-LSA   [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  38   Unused (Not to be allocated)
[RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  39   E-Type-7-LSA[RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  40   E-Link-LSA  [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  41   E-Intra-Area-Prefix-LSA [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>
>  Please see
>  https://www.iana.org/assignments/ospfv3-parameters
>
>  thanks,
>  Amanda
>
>
>  On Wed Jan 31 19:29:16 2018, a...@cisco.com wrote:
>  > Hi Amanda,
>  >
>  > The actions below are correct. However, the one (the first) IANA
>  > action from the draft is missing:
>  >
>  > This specification defines nine OSPFv3 Extended LSA types as
>  > described in Section 2.  These are added the existing OSPFv3 LSA
>  > Function Codes registry.
>  >
>  > I guess I should have repeated these in the IANA Considerations
>  > section.
>  >
>  >
>  > LSA function code   LS Type   Description
>  > 
>  > 33  0xA021E-Router-LSA
>  > 34  0xA022E-Network-LSA
>  > 35  0xA023E-Inter-Area-Prefix-LSA
>  > 36  0xA024E-Inter-Area-Router-LSA
>  > 37  0xC025E-AS-External-LSA
>  > 38  N/A   Unused (Not to be allocated)
>  > 39  0xA027E-Type-7-LSA
>  > 40  0x8028E-Link-LSA
>  > 41  0xA029E-Intra-Area-Prefix-LSA
>  >
>  >
>  > OSPFv3 Extended LSA Types
>  >
>  > Thanks,
>  >  Acee
>  >
>  >
>  >
>  >
>  > On 1/31/18, 2:17 PM, "Amanda Baber via RT" 
<drafts-appro...@iana.org>
>  > wrote:
>  >
>  > Dear Authors:
>  >
>  > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED
>  >
>  > We've completed the registry actions for the following RFC-to-be:
>  >
>  > draft-ietf-ospf-ospfv3-lsa-extend-23
>  >
>  > ACTION 1:
>  >
>  > We've added the following entry to the OSPFv3 Prefix Options (8 
bits)
>  > registry:
>  >
>  > 0x20N-bit   [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  >
>  > Please see
>  > https://www.iana.org/assignments/ospfv3-parameters
>  >
>  >
>  > ACTION 2:
>  >
>  > We've created the following registry:
>  >
>  > OSPFv3 Extended-LSA TLVs
>  > Reference: [RFC-ietf-ospf-ospfv3-lsa-extend-23]
>  >
>  > Range   Registration Procedures
>  > 9-32767 IETF Review or IESG Approval
>  > 33024-45055 First Come First Served
>  >
>  > Value   Description Reference
>  > 0   Reserved[RFC-ietf-ospf-ospfv3-l

Re: [OSPF] Immediate Replying Hello

[Acee Lindem (acee)]

From: OSPF <ospf-boun...@ietf.org> on behalf of 
"rui.vala...@tecnico.ulisboa.pt" <rui.vala...@tecnico.ulisboa.pt>
Date: Wednesday, January 31, 2018 at 8:44 AM
To: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Immediate Replying Hello

Hi,

It helps, thanks.

But the Kou draft 
(https://datatracker.ietf.org/doc/draft-kou-ospf-immediately-replying-hello/ ) 
also mentions two other situations where immediate hellos must be sent: after 
state changes from “2-Way” or greater down to “Init” (case 2), and after DR 
election (case 3). Do you know if these cases are also implemented?

While there are other cases where hellos are sent other than on a timer, I 
don’t know of these cases being implemented.

Thanks,
Acee


Thanks.

Rui

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, January 31, 2018 12:47 PM
To: rui.vala...@tecnico.ulisboa.pt; ospf@ietf.org
Subject: Re: [OSPF] Immediate Replying Hello

Hi Rui,

It is not a standard. However, it is a technique used by many implementations 
to speed adjacency formation when a hello packet is received and the neighbor 
state is less than two-way. At least one of the implementations with witch with 
I have been associated would unicast the hello.

Hope this helps,
Acee

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
"rui.vala...@tecnico.ulisboa.pt<mailto:rui.vala...@tecnico.ulisboa.pt>" 
<rui.vala...@tecnico.ulisboa.pt<mailto:rui.vala...@tecnico.ulisboa.pt>>
Date: Wednesday, January 31, 2018 at 3:28 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] Immediate Replying Hello

Hi,

Many OSPF implementations include the Immediate Replying Hello feature, which I 
believe is not standard.

The only reference I found is the draft “Update to OSPF Hello procedure, 
draft-kou-ospf-immediately-replying-hello-02.txt” which has expired.

Are vendors following what is written in this draft? Is there a document from 
any vendor that details this feature?

Thanks.

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

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Acee Lindem (acee)]

I agree with Les about being selective about LSR non-routing usage.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>
Date: Thursday, January 25, 2018 at 1:59 PM
To: Stewart Bryant <stewart.bry...@gmail.com>, Acee Lindem <a...@cisco.com>, 
Alia Atlas <akat...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org>, "isis...@ietf.org" <isis...@ietf.org>
Subject: RE: [Isis-wg] Link-State Routing WG charter

Stewart -

From: Stewart Bryant [mailto:stewart.bry...@gmail.com]
Sent: Thursday, January 25, 2018 4:32 AM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem (acee) 
<a...@cisco.com>; Alia Atlas <akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org>; isis...@ietf.org
Subject: Re: [Isis-wg] Link-State Routing WG charter




Les

I agree wrt L2

Isn't another focus collecting the information to feed into an SDN controller 
via BGP-LS? That is really network layer  state collection rather than routing 
in the traditional sense.



[Les:] Please do not propose such language. This raises the old discussion 
about using the IGPs as a transport for “just about anything”.

We long ago agreed that TE related information was “routing information” – if 
for no other reason than it was grandfathered in. But this does not alter the 
IGP’s focus on routing.

I know we “stretch” the definition with things like MSD and S-BFD 
discriminators, but I see these as carefully considered choices – and ones w 
modest impact.

Institutionalizing the IGPs as an “SDN Distribution Protocol” is not something 
I want in the charter.

   Les



- Stewart

On 24/01/2018 23:09, Les Ginsberg (ginsberg) wrote:
It occurred to me after sending this that perhaps a better statement as regards 
IS-IS would be:

“LSR’s work is focused on IP/IPv6 and Layer 2 routing…”

though admittedly there isn’t much going on as regards Layer2 and IS-IS at the 
moment.

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Les Ginsberg 
(ginsberg)
Sent: Wednesday, January 24, 2018 2:33 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>; 
Acee Lindem (acee) <a...@cisco.com><mailto:a...@cisco.com>; Alia Atlas 
<akat...@gmail.com><mailto:akat...@gmail.com>
Cc: OSPF List <ospf@ietf.org><mailto:ospf@ietf.org>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Since a charter only provides a general definition of the work that falls 
within the purview of the WG it requires some adjunct to keep track of the 
current priorities.
That could be the list of milestones (which OSPF has regularly maintained – but 
IS-IS has not) – or it could simply be the list of active WG documents.
I just don’t see that we should expect the charter to express “work in 
progress” now – or in the future.

Alia – do you think the statement about IS-IS:

“LSR’s work is focused on IP routing…”

Could be improved by saying

“LSR’s work is focused on IP/IPv6 routing…”

???

   Les


From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 24, 2018 10:01 AM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>
Cc: OSPF List <ospf@ietf.org<mailto:ospf@ietf.org>>; 
isis...@ietf.org<mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter


Yes that fixes that.

How about:

s/The following topics are expected to be an initial focus:/ In addition to 
ongoing maintenance, the following topics are expected to be an initial focus:/

I am just concerned that we need not to loose focus on work in progress.

- Stewart

On 24/01/2018 17:54, Acee Lindem (acee) wrote:
How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg <isis-wg-boun...@ietf.org><mailto:isis-wg-boun...@ietf.org> on 
behalf of Alia Atlas <akat...@gmail.com><mailto:akat...@gmail.com>
Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant <stewart.bry...@gmail.com><mailto:stewart.bry...@gmail.com>
Cc: OSPF WG List <ospf@ietf.org><mailto:ospf@ietf.org>, 
"isis...@ietf.org"<mailto:isis...@ietf.org> 
<isis...@ietf.org><mailto:isis...@ietf.org>
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
<stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> wrote:

Alia,
I think that this merger is long overdue, and hopefully it will help new 
features to be written in an aligned way.

I think the remit to 

Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Acee Lindem (acee)]

Hi Alia, Alvaro,
I believe the -23 version clarifies the usage of the N-bit in prefix 
advertisements.
Thanks,
Acee

From: Alia Atlas <akat...@gmail.com>
Date: Wednesday, January 24, 2018 at 6:51 PM
To: Acee Lindem <a...@cisco.com>
Cc: Alvaro Retana <aretana.i...@gmail.com>, The IESG <i...@ietf.org>, OSPF WG 
List <ospf@ietf.org>, "draft-ietf-ospf-ospfv3-lsa-ext...@ietf.org" 
<draft-ietf-ospf-ospfv3-lsa-ext...@ietf.org>, "ospf-cha...@ietf.org" 
<ospf-cha...@ietf.org>, "Peter Psenak (ppsenak)" <ppse...@cisco.com>
Subject: Re: Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with 
COMMENT)

Hi Acee,

Thanks for your quick responses.  On the point about the N-flag, I also found 
it was
a bit underspecified in my AD review.  Could you please spend a bit of time 
thinking
about how to make it clearer.

Thanks,
Alia

On Wed, Jan 24, 2018 at 6:12 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
HI Alvaro,

Thanks for the detailed review.  I've resolved almost all of your comments.  
I'm going to issue a new version.

On 1/24/18, 9:47 AM, "Alvaro Retana" 
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-ospfv3-lsa-extend-21: Yes

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


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


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



--
COMMENT:
--

Thanks for doing this work!!

All my comments (below) are non-blocking, but I would like to see them
addressed before publication.

(1) Please include in an explicit indication of what in rfc5340/rfc5838 is
Updated by this document.

Ok - while it is obvious once the draft has been consumed, I'll state it in the 
Abstract and Introduction explicitly.


(2) It seems to me that the setting of the U-bit is treated too lightly: 
"the
U-bit will be set"; maybe be more prescriptive: "the U-bit MUST be set".

Sure. Although the U-bit is included in the full LSA type so this was really 
more informative than normative. However, I don't have a strong opinion.

(3) I'm confused, why is the N-bit needed?  The description indicates when 
to
suse it, but is also says that the "advertising router MAY choose NOT to set
[it]", so it doesn't sound that important.  Further down, there are other
conditions when it is set...but no other text in the document about checking
it, or what happens if it is not set. Finally, the text gives an application
example: "identifying the prefixes corresponding to Node Segment Identifiers
(SIDs) in Segment Routing" -- I checked the reference, but didn't find a
mention of the N-bit there either.

I'm going to defer this one. However, it should be noted that it is also 
specified RFC 7684 as the Node-Flag with the same description.

(4) s/The IPv4 Forwarding Address TLV is The IPv4 Forwarding Address TLV/The
IPv4 Forwarding Address TLV

Fixed.


(5) s/IPv3/IPv4

Fixed.


(6) The figures in 3.10 and 3.11 have the wrong tittle.

Fixed.


(7) From 4.1:
   Depending on the implementation, it is perfectly valid for an E-
   Router-LSA to not contain any Router-Link TLVs.  However, this would
   imply that the OSPFv3 router doesn't have any active interfaces in
   the corresponding area and such E-Router-LSA would never be flooded
   to other OSPFv3 routers in the area.


I can imagine that a starting/restarting router could have a local 
E-Router-LSA
with no active interfaces, are there other cases?

I was going to say it would never happen. However, if you have a single 
unnumbered interface (no stub link) and an adjacency (>= Exchange state) is 
being formed, you could have an E-Router-LSA with no links. I'll fix the text.

What should a router do if
it receives an E-Router-LSA with no Router-Link TLVs?

 The same thing happens as in OSPFv2 and OSPFv3 today. The OSPFv3 router is not 
reachable via an OSPFv3 route.  Do you want me to add something other than 
fixing the above?


(8) s/Inter-Area-Router-LSAE/Inter-Area-Router-LSA

Fixed.

(9) sparse mode is called "spare mode" in a couple of places...or maybe it's
the other way around. ;-)

Fixed.

(10) In many OSPF-related documents the Appendixes are Normative,

Re: [OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Alia,

From: Alia Atlas 
Date: Thursday, January 25, 2018 at 10:30 AM
To: Deborah Brungard 
Cc: The IESG , OSPF WG List , 
"draft-ietf-ospf-link-overl...@ietf.org" 
, Acee Lindem , 
"ospf-cha...@ietf.org" , "TEAS WG (t...@ietf.org)" 

Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: 
(with DISCUSS and COMMENT)

More specifically, as Deborah pointed out, in RFC 5817 Section 4.1, it says
"Specifically, the node where graceful shutdown of a link is desired originates 
the TE LSA or IS-
   IS-LSP containing a Link TLV for the link under graceful shutdown
   with the Traffic Engineering metric set to 0x, 0 as
   unreserved bandwidth. "

and draft-ietf-ospf-link-overload-14 conflicts with that by using 0xfffe 
instead.

I’ll defer to Shraddha and the other authors on this one. We did discuss the 
RFC 5817 inconsistency once already and the intension is that TE interface 
would still be used as a last resort TE interface.

Thanks,
Acee


Regards,
Alia

On Thu, Jan 25, 2018 at 10:26 AM, Alia Atlas 
> wrote:
Could a look at the changes in draft-ietf-ospf-link-overload-14 happen?

Also, it would be good to get feedback from TEAS on this document and any 
concerns.

Thanks,
Alia

On Tue, Jan 23, 2018 at 12:01 PM, Deborah Brungard 
> wrote:
Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-link-overload-13: Discuss

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


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


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



--
DISCUSS:
--

This document is defining a MAX-TE-METRIC of 0xfffe. But RFC5817 defined
0x to be used for graceful shutdown. I noted an email exchange between
the author and Acee on this where Acee raised the question why RFC5817's value
was not used. Shraddha replied "We can if we have the Working Group Consensus".
There was no further discussion.

This document was not shared with teas which is responsible for TE (or ccamp
which was originally responsible for RFC5817).

Either this value needs to be changed to RFC5817's value or this TE metric
needs to be removed from this document until agreement with TEAS.


--
COMMENT:
--

I found the title of section 7.2 "Controller Based Traffic Engineering
Deployments" confusing as it only is describing a controller controlling a
path. It is not "TE" in the IETF sense e.g. TE signaling. It would be much less
confusing if say "Controller Based Deployments" and "satisfying the traffic
engineering constraints"/s/"satisfying the constraints". Especially as for TE,
procedures already do exist.  I noted in the introduction you did reference
RFC5817 MPLS Graceful Shutdown on the procedures when doing a graceful shutdown
of a TE link.



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

Re: [OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Amazing timing, I have two documents in the IESG telechat today for which I am 
the primary editor and another for which I am the document shepherd (the one in 
the subject line). Please be patient.

Thanks
Acee

From: Alia Atlas 
Date: Thursday, January 25, 2018 at 10:26 AM
To: Deborah Brungard 
Cc: The IESG , OSPF WG List , 
"draft-ietf-ospf-link-overl...@ietf.org" 
, Acee Lindem , 
"ospf-cha...@ietf.org" , "TEAS WG (t...@ietf.org)" 

Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: 
(with DISCUSS and COMMENT)

Could a look at the changes in draft-ietf-ospf-link-overload-14 happen?

Also, it would be good to get feedback from TEAS on this document and any 
concerns.

Thanks,
Alia

On Tue, Jan 23, 2018 at 12:01 PM, Deborah Brungard 
> wrote:
Deborah Brungard has entered the following ballot position for
draft-ietf-ospf-link-overload-13: Discuss

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


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


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



--
DISCUSS:
--

This document is defining a MAX-TE-METRIC of 0xfffe. But RFC5817 defined
0x to be used for graceful shutdown. I noted an email exchange between
the author and Acee on this where Acee raised the question why RFC5817's value
was not used. Shraddha replied "We can if we have the Working Group Consensus".
There was no further discussion.

This document was not shared with teas which is responsible for TE (or ccamp
which was originally responsible for RFC5817).

Either this value needs to be changed to RFC5817's value or this TE metric
needs to be removed from this document until agreement with TEAS.


--
COMMENT:
--

I found the title of section 7.2 "Controller Based Traffic Engineering
Deployments" confusing as it only is describing a controller controlling a
path. It is not "TE" in the IETF sense e.g. TE signaling. It would be much less
confusing if say "Controller Based Deployments" and "satisfying the traffic
engineering constraints"/s/"satisfying the constraints". Especially as for TE,
procedures already do exist.  I noted in the introduction you did reference
RFC5817 MPLS Graceful Shutdown on the procedures when doing a graceful shutdown
of a TE link.


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

Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Acee Lindem (acee)]

HI Alvaro, 

Thanks for the detailed review.  I've resolved almost all of your comments.  
I'm going to issue a new version. 

On 1/24/18, 9:47 AM, "Alvaro Retana"  wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-ospf-ospfv3-lsa-extend-21: Yes

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


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


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



--
COMMENT:
--

Thanks for doing this work!!

All my comments (below) are non-blocking, but I would like to see them
addressed before publication.

(1) Please include in an explicit indication of what in rfc5340/rfc5838 is
Updated by this document.

Ok - while it is obvious once the draft has been consumed, I'll state it in the 
Abstract and Introduction explicitly. 


(2) It seems to me that the setting of the U-bit is treated too lightly: 
"the
U-bit will be set"; maybe be more prescriptive: "the U-bit MUST be set".

Sure. Although the U-bit is included in the full LSA type so this was really 
more informative than normative. However, I don't have a strong opinion. 

(3) I'm confused, why is the N-bit needed?  The description indicates when 
to
suse it, but is also says that the "advertising router MAY choose NOT to set
[it]", so it doesn't sound that important.  Further down, there are other
conditions when it is set...but no other text in the document about checking
it, or what happens if it is not set. Finally, the text gives an application
example: "identifying the prefixes corresponding to Node Segment Identifiers
(SIDs) in Segment Routing" -- I checked the reference, but didn't find a
mention of the N-bit there either.

I'm going to defer this one. However, it should be noted that it is also 
specified RFC 7684 as the Node-Flag with the same description. 

(4) s/The IPv4 Forwarding Address TLV is The IPv4 Forwarding Address TLV/The
IPv4 Forwarding Address TLV

Fixed.


(5) s/IPv3/IPv4

Fixed.


(6) The figures in 3.10 and 3.11 have the wrong tittle.

Fixed. 


(7) From 4.1:
   Depending on the implementation, it is perfectly valid for an E-
   Router-LSA to not contain any Router-Link TLVs.  However, this would
   imply that the OSPFv3 router doesn't have any active interfaces in
   the corresponding area and such E-Router-LSA would never be flooded
   to other OSPFv3 routers in the area.


I can imagine that a starting/restarting router could have a local 
E-Router-LSA
with no active interfaces, are there other cases?  

I was going to say it would never happen. However, if you have a single 
unnumbered interface (no stub link) and an adjacency (>= Exchange state) is 
being formed, you could have an E-Router-LSA with no links. I'll fix the text. 

What should a router do if
it receives an E-Router-LSA with no Router-Link TLVs?

 The same thing happens as in OSPFv2 and OSPFv3 today. The OSPFv3 router is not 
reachable via an OSPFv3 route.  Do you want me to add something other than 
fixing the above? 


(8) s/Inter-Area-Router-LSAE/Inter-Area-Router-LSA

Fixed. 

(9) sparse mode is called "spare mode" in a couple of places...or maybe it's
the other way around. ;-)

Fixed. 

(10) In many OSPF-related documents the Appendixes are Normative, so I'm
assuming they are Normative here too.  Only A and B are referenced from the
main text -- C is titled "Deprecated LSA Extension Backward Compatibility";
deprecated??  Does that mean that C is an old behavior that lived at some 
point
in the history of this document?  The content of C doesn't seem to conflict
with what is in A and B, and there is some important information there -- 
for
example the transition process in C.1.  But C.2. and C.3. clearly overlap 
with
A and B.  Please clarify the role of the Appendixes.

[The following comments are related to the Appendixes and their relevance
depends on my comment above.]

I think I'm going to remove Appendix C. It was made non-normative since we had 
an extended drought on implementation and this was assessed by me to be the 
greatest implementation barrier. I think it would be better to describe this in 
a new draft normatively. I've never been a fan of programmers adding code that 
MAY be used in the future. I'll see if any of the 

Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Acee Lindem (acee)]

Working on too many things at one time. Actually this is already cover in 
section 6.3 so I will reference that section. 

  If a TLV or Sub-TLV is recognized but the length is less than the
   minimum, then the LSA should be considered malformed and it
   SHOULD NOT be acknowledged.  Additionally, the occurrence SHOULD
   be logged with enough information to identify the LSA by type,
   originator, and sequence number and the TLV or Sub-TLV in error.
   Ideally, the log entry would include the hexadecimal or binary
   representation of the LSA including the malformed TLS or Sub-TLV.

For example:

The sub-TLV length must meet minimum length constraints as specified in section 
6.3.  

Thanks
Acee 

On 1/24/18, 3:11 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

Hi Suresh, 

On 1/24/18, 10:20 AM, "Suresh Krishnan" <sur...@kaloom.com> wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-ospfv3-lsa-extend-21: No Objection

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


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


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



--
COMMENT:
--

* Section 3.10 and 3.11

What does the sub-TLV length mean here? Are values other than 4 and 16
permitted? If not, how is the packet treated (sub TLV is ignored?)

My thought was to allow for further sub-TLVs defined recursively. However, 
one would still need a minimum length of 4 or 16 for the forwarding address 
TLVs. I will add this constraint and will indicate that the TLV is treated as 
malformed if it is not at least 4 or 16 octets respectively. Similarly, for the 
Route Tag sub-TLV, I'll indicate that the length must be at least 4 octets. 

Thanks,
Acee









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

Re: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Acee Lindem (acee)]

Hi Suresh, 

On 1/24/18, 10:20 AM, "Suresh Krishnan"  wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-ospfv3-lsa-extend-21: No Objection

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


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


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



--
COMMENT:
--

* Section 3.10 and 3.11

What does the sub-TLV length mean here? Are values other than 4 and 16
permitted? If not, how is the packet treated (sub TLV is ignored?)

My thought was to allow for further sub-TLVs defined recursively. However, one 
would still need a minimum length of 4 or 16 for the forwarding address TLVs. I 
will add this constraint and will indicate that the TLV is treated as malformed 
if it is not at least 4 or 16 octets respectively. Similarly, for the Route Tag 
sub-TLV, I'll indicate that the length must be at least 4 octets. 

Thanks,
Acee







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

Re: [OSPF] [Isis-wg] Link-State Routing WG charter

[Acee Lindem (acee)]

How about:

LSR will coordinate with CCAMP and BIER on their extensions to the LSR IGPs as
applicable to LSV protocol operation and scale.

Thanks,
Acee

From: Isis-wg  on behalf of Alia Atlas 

Date: Wednesday, January 24, 2018 at 12:42 PM
To: Stewart Bryant 
Cc: OSPF WG List , "isis...@ietf.org" 
Subject: Re: [Isis-wg] Link-State Routing WG charter

Hi Stewart,

Thanks for the quick feedback.  Feel free to provide suggestions for text 
changes if you have them.
You've certainly written enough charters :-)

Regards,
Alia

On Wed, Jan 24, 2018 at 12:32 PM, Stewart Bryant 
> wrote:

Alia,
I think that this merger is long overdue, and hopefully it will help new 
features to be written in an aligned way.

I think the remit to perform general maintenance should slightly clarified 
since the way the charter is written they look like they are at a lower 
priority than the enumerated list.

I would have thought that "LSR can coordinate with CCAMP and BIER on their 
extensions " should have been more directive.

- Stewart

On 24/01/2018 17:18, Alia Atlas wrote:
Here is the proposed charter for the LSR working group
that will be created from the SPF and ISIS working groups.

This is scheduled for internal review for the IESG telechat on February 8.

https://datatracker.ietf.org/doc/charter-ietf-lsr/

The Link-State Routing (LSR) Working Group is chartered to document current 
protocol implementation practices and improvements, protocol usage scenarios, 
maintenance and extensions of link-state routing interior gateway protocols 
(IGPs) with a focus on IS-IS, OSPFv2, and OSPFv3.  The LSR Working Group is 
formed by merging the isis and ospf WGs and will take on all their existing 
adopted work at the time of chartering.

IS-IS is an IGP specified and standardized by ISO through ISO 10589:2002 and 
additional RFC standards with extensions to support IP that has been deployed 
in the Internet for decades.  For the IS-IS protocol, LSR’s work is focused on 
IP routing, currently based on the agreement in RFC 3563 with ISO/JTC1/SC6. The 
LSR WG will interact with other standards bodies that have responsible for 
standardizing IS-IS.

OSPFv2 [RFC 2328 and extensions], is an IGP that has been deployed in the 
Internet for decades. OSPFv3 [RFC5340 and extensions] provides OSPF for IPv6 
and IPv4 [RFC5838] which can be delivered over IPv6 or IPv4 [RFC 7949].

The LSR Working Group will generally manage its specific work items by 
milestones agreed with the responsible Area Director.

The following topics are expected to be an initial focus:

1) Improving OSPF support for IPv6 and extensions using OSPFv3 LSA 
Extendibility.
2) Extensions needed for Segment Routing and associated architectural changes
3) YANG models for IS-IS, OSPFv2, and OSPFv3 and extensions
4) Extensions for source-destination routing [draft-ietf-rtgwg-dst-src-routing]
5) Potentially, extensions to better support specific network topologies such as
ones commonly used in data centers.

The Link-State Routing (LSR) Working Group will coordinate with other working 
groups, such as RTGWG, SPRING, MPLS, TEAS, V6OPS, and 6MAN, to understand the 
need for extensions and to confirm that the planned work meets the needs.  LSR 
can coordinate with CCAMP and BIER on their extensions to the LSR IGPs as 
useful.  LSR may coordinate with other WGs as needed.

Regards,
Alia



___

Isis-wg mailing list

isis...@ietf.org

https://www.ietf.org/mailman/listinfo/isis-wg


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

Re: [OSPF] Ben Campbell's No Objection on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Acee Lindem (acee)]

Hi Ben, 

On 1/23/18, 9:47 PM, "Ben Campbell"  wrote:

Ben Campbell has entered the following ballot position for
draft-ietf-ospf-ospfv3-lsa-extend-21: No Objection

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


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


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



--
COMMENT:
--

-1.1: There are instances of lower case 2119 keywords. Please consider using
the boilerplate from RFC 8174.

This is clearly the intent. This change will be in the -22 version with RFC 
8174 as a normative reference. 


1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Thanks,
Acee 






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

Re: [OSPF] [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Acee Lindem (acee)]

Hi Martin, Lada, 

In experimenting with this, I get YANGLINT validation errors. I’m not sure what 
I’m missing but the first argument to derived-from()/derive-from-or-self() is 
the schema node and the second is the identity – correct?
For example, the following YANG leaf:

identity ospf-protocol {
base "rt:routing-protocol";
description "Any version the OSPF protocol";
  }

  identity ospfv2 {
base "ospf-protocol";
description "OSPFv2";
  }

  identity ospfv3 {
base "ospf-protocol";
description "OSPFv3";
  }

leaf routing-protocol-name {
  type leafref {
path "/rt:routing/rt:control-plane-protocols/"
   + "rt:control-plane-protocol/rt:name";
  }
  must "derived-from( "
+ "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol[rt:name=current()]/"
+ "rt:type, ospf:ospf-protocol)";
  description
   "OSPF routing protocol instance name.";
}

Gives me: 

warn: Schema node "ietf-ospf:ospf-protocol" not found (derived-from( 
/ietf-routing:routing/ietf-routing:control-plane-protocols/ietf-routing:control-plane-protocol[ietf-routing:name=current()]/ietf-routing:type,
 ietf-ospf:ospf-protocol) with context node 
"/ietf-ospf:if-state-change/routing-protocol-name".

Thanks
Acee 

On 1/10/18, 4:36 AM, "Martin Bjorklund" <m...@tail-f.com> wrote:

Hi,

I think we can agree that the model in this I-D should use
derived-from-or-self() instead of string comparison, and conclude this
discussion here.  I suggest that if we need to further discuss the
representation of identityrefs, then we start a new thred on the
NETMOD ML.


/martin



Ladislav Lhotka <lho...@nic.cz> wrote:
> On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote:
> > 
> > > > Hi,
> > 
> > > > 
> > 
> > > > Ladislav Lhotka <lho...@nic.cz> wrote:
> > 
    > > > > > Hi Acee,
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > please see inline.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > On Mon, 2018-01-08 at 19:28 +, Acee Lindem (acee) wrote:
> > 
> > > > 
> > 
> > > > > > Hi Lada,
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Apologies for the delay. We somewhat got hung up on 4 and 6. See
> > inline.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > > Reviewer: Ladislav Lhotka
> > 
> > > > 
> > 
> > > > > > > Review result: Ready with Issues
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > ...
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > > > 
> > 
> > > > 
> > 
> > > > > > > 3. Maybe the draft could mention that implementations should 
supply
> > a
> > 
> > > > 
> > 
> > > > > > >   default routing domain as a system-controlled resource.
> > 
> > > > 
> > 
> > > > > > 
> > 
> > > > 
> > 
> > > > > > Isn’t this more of an RFC8022BIS statement? I guess we could 
state
> > this as
> > 
> > > > 
> > 
> > > > > > an assumption.
> > 
> > > > 
> > 
> > > > > 
> > 
> > > > 
> > 
> > > > > Probably, but it is not

Re: [OSPF] Fwd: YANG modules publication: what to focus on next?

[Acee Lindem (acee)]

Hi Tom, 

On 1/17/18, 12:05 PM, "t.petch"  wrote:

>Acee
>
>Looking at draft-ietf-ospf-yang, I see that it Normatively references
>[RFC6020] (but not RFC7950), the soon-to-be-obsoleted  [RFC7223]
>and [RFC8022] 

We will fix this. 

> while revised-datastores is only a Informative reference.

While the model is NDMA compliant, it isn’t really dependent on the draft
(IMO). 
>
>Do you plan on changing any of this?.
>
>I note that the import statements do not specify a revision date.

Nope. We’ll add a comment that it should be the NDMA compliant version.

Thanks,
Acee 
>
>Tom Petch
>
>
>- Original Message -
>From: "Benoit Claise" 
>To: ; 
>Sent: Tuesday, January 16, 2018 11:30 AM
>
>> Dear all,
>>
>> So that you know that draft-ietf-ospf-yang and
>> draft-ietf-isis-yang-isis-cfg are bottlenecks to publish many YANG
>> modules. Please progress them asap.
>>
>> Regards, Benoit
>>
>>
>>  Forwarded Message 
>> Subject: YANG modules publication: what to focus on next?
>> Date: Tue, 16 Jan 2018 12:27:01 +0100
>> From: Benoit Claise 
>> To: NETMOD Working Group 
>>
>>
>>
>> Dear all,
>>
>> At the last IETF meeting, Alia, Deborah and I looked at the
>publication
>> status of most YANG modules.
>> Since that time, I've been keeping a summary of the situation. Let me
>> share it with everybody.
>>
>> Before publishing YANG modules, we have two series of bottlenecks:
>> - the YANG module import (shown by tooling below)
>> - the normative references (MISSREF in the RFC editor queue
>> )
>>   Note that draft-ietf-netmod-revised-datastores, a normative
>reference
>> for many YANG modules,
>>   was just approved. Good news!
>>
>> We now have many YANG modules in RFC editor queue:
>> ***draft-ietf-lime-yang-connectionless-oam-18
>>
>m>**
>> draft-ietf-lime-yang-connectionless-oam-methods-13
>>
>m-methods>**
>> draft-ietf-i2rs-yang-l3-topology-16
>> **
>> draft-ietf-i2rs-yang-network-topo-20
>> **
>> draft-wu-l3sm-rfc8049bis-11
>> 
>> **draft-ietf-netconf-rfc6536bis-09
>> 
>> *draft-ietf-netmod-rfc7223bis-03
>> 
>> draft-ietf-netmod-rfc7277bis-03
>> 
>> draft-ietf-rtgwg-yang-vrrp-09
>> 
>> draft-ietf-rtgwg-yang-rip-08
>> 
>> draft-ietf-netmod-revised-datastores-10
>>
>
>>
>> Here are the YANG module dependencies
>>
>etf-ip[]=ietf-connectionless-oam[]=ietf-lime-time-types&
>modules[]=ietf-connectionless-oam-methods[]=ietf-l3-unicast-topo
>logy[]=ietf-l3-unicast-topology-state[]=ietf-network-top
>ology[]=ietf-network-topology-state[]=ietf-network
>es[]=ietf-network-state[]=ietf-l3vpn-svc[]=ietf-netconf-
>acm[]=ietf-interfaces[]=ietf-vrrp[]=ietf-rip
>ules[]=ietf-datastores[]=ietf-origin=1=1_subm=
>1_dir=dependencies>
>> for these RFC editor modules, as requirement before publishing.
>>
>> Some more YANG modules are on the IESG table:
>>   draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)
>>   draft-ietf-netmod-rfc8022bis is on the Jan 25th IESG telechat
>>   draft-ietf-netmod-entity is on the Jan 25th IESG telechat
>>
>> Assuming those are in the RFC editor queue, this is the new set of
>YANG
>> module dependencies
>>
>etf-ip[]=ietf-connectionless-oam[]=ietf-lime-time-types&
>modules[]=ietf-connectionless-oam-methods[]=ietf-l3-unicast-topo
>logy[]=ietf-l3-unicast-topology-state[]=ietf-network-top
>ology[]=ietf-network-topology-state[]=ietf-network
>es[]=ietf-network-state[]=ietf-l3vpn-svc[]=ietf-netconf-
>acm[]=ietf-interfaces[]=ietf-vrrp[]=ietf-rip
>ules[]=ietf-pim-dm[]=ietf-pim-base[]=ietf-pim-sm
>[]=ietf-pim-bidir[]=ietf-pim-rp[]=ietf-routing[]
>=ietf-ipv6-router-advertisements[]=ietf-ipv4-unicast-routing
>ules[]=ietf-ipv6-unicast-routing[]=ietf-entity[]=ietf-da
>tastores[]=ietf-origin=1=1_subm=1_dir=dep
>endencies>.
>> It takes a little bit of re-arrangering the elements, but all the
>> information is there.
>>
>> The next bottlenecks for publishing those YANG modules are:
>>   draft-ietf-netmod-schema-mount
>>   draft-ietf-rtgwg-ni-model
>>   ietf-bfd-yang
>>   

Re: [OSPF] OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

[Acee Lindem (acee)]

Hi Shraddha,

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Friday, January 12, 2018 at 3:07 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

Acee,

Pls see inline..

From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Wednesday, January 10, 2018 7:51 AM
To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

Hi Shraddha,

We noticed that RFC 5817 sets the TE Metric to 0x for graceful TE 
shutdown and the OSPF Link Overload draft uses MAX-TE-METRIC (0xfffe). Two 
Questions:


1.   MAX-TE-METRIC is being defined in the OSPF Link Overload draft – 
correct? It is not a reference from some other RFC or draft?

Yes. This value is introduced in this draft.

Given all work on TE, I was inclined to search for this constant in other 
documents. I think it would be useful to precede the definition with “This 
document defines MAX-TE-METRIC as 0xffe.” to avoid any confusion.


The reason was that some implementation treat te-metric 0x as invalid 
value and do not setup paths through them. Using 0x-1 seemed like a 
safe option

I was not aware some TE implementations did this. We definitely want it to be 
used as the least preferred path in this state.

I know that pre-RFC 2383 (not going to look up where it was actually changed) 
defined 0xff as unreachable and this was later deprecated.


2.   Why not just use 0x like RFC 5817?

We can if we have the Working Group Consensus.

I don’t feel strongly but would err on the conservative side if there are 
implementations that treat 0x as unusable.

Thanks,
Acee




Thanks,
Acee

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

[OSPF] OSPF Link Overload (aka, Graceful Link Shutdown) MAX-TE-METRIC

[Acee Lindem (acee)]

Hi Shraddha,

We noticed that RFC 5817 sets the TE Metric to 0x for graceful TE 
shutdown and the OSPF Link Overload draft uses MAX-TE-METRIC (0xfffe). Two 
Questions:

   1. MAX-TE-METRIC is being defined in the OSPF Link Overload draft – correct? 
It is not a reference from some other RFC or draft?
   2. Why not just use 0x like RFC 5817?

Thanks,
Acee

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Acee Lindem (acee)]

Hi Pushpasis, Shraddha, et al,

From: Pushpasis Sarkar 
<pushpasis.i...@gmail.com<mailto:pushpasis.i...@gmail.com>>
Date: Monday, January 8, 2018 at 12:22 PM
To: Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, Acee 
Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg (ginsberg)" 
<ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "Ketan Talaulikar (ketant)" 
<ket...@cisco.com<mailto:ket...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, "i...@ietf.org<mailto:i...@ietf.org>" 
<i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>, 
Pushpasis Sarkar <pushpasis.i...@gmail.com<mailto:pushpasis.i...@gmail.com>>, 
Hannes Gredler <han...@gredler.at<mailto:han...@gredler.at>>, 
<mnand...@ebay.com<mailto:mnand...@ebay.com>>, Luay Jalil 
<luay.ja...@verizon.com<mailto:luay.ja...@verizon.com>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>, 
<a...@cisco.com<mailto:a...@cisco.com>>, Alvaro Retana 
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>, Deborah Brungard 
<db3...@att.com<mailto:db3...@att.com>>, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>
Resent-Date: Monday, January 8, 2018 at 12:22 PM

Hi Joel et al,

+1 for 'graceful-link-shutdown'.

I think we are converging on this. I must admit that it is much better than 
“link-overload”. Although Les raises a good point that this behavior could be 
used for other use cases, subsequent discussions have indicated that these 
could be handled differently.


Another possibility may be 'link-decommission'..

This implies too much permanence. If you decommission something, you are more 
or less retiring It which is not this use case. This is more of giving the link 
a rest. Maybe we could use the there term “Link on Leave” or LOL state ;^).

Thanks,
Acee


Thanks and regards
-Pushpasis

On Mon, Jan 8, 2018 at 7:09 PM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:


From: Shraddha Hegde

How about “graceful-link-shutdown” ?

Looks good to me.

Also, FYI, for BGP sessions, in the GROW WG we used the term “Graceful BGP 
session shutdown” and named the BGP community “GRACEFUL_SHUTDOWN” so this would 
align on the terminology.
https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-13

Best regards,
--Bruno


Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:

Re: [OSPF] Opsdir last call review of draft-ietf-ospf-ospfv3-lsa-extend-20

[Acee Lindem (acee)]

Thanks for the review Mehmet.
Acee 

On 1/8/18, 2:07 PM, "Mehmet Ersue"  wrote:

>Reviewer: Mehmet Ersue
>Review result: Ready
>
>I reviewed the document "OSPFv3 LSA Extendibility"
>(draft-ietf-ospf-ospfv3-lsa-extend-20.txt) as part of the Operational
>directorate's ongoing effort to review all IETF documents being processed
>by
>the IESG. These comments were written primarily for the benefit of the
>operational area directors.  Document editors and WG chairs should treat
>these
>comments just like any other last call comments.
>
>Intended status: Standards Track
>Current IESG state: In Last Call (ends 2018-01-11)
>IANA State: IANA - Review Needed
>Updates RFC 5340 (OSPF for IPv6) and RFC 5838 (Support of Address
>Families in
>OSPFv3)
>
>Summary:
>The document extends the Link State Advertisement (LSA) format by
>encoding the
>existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and
>allowing
>advertisement of additional information with additional TLVs.  The
>document
>provides backward compatibility mechanisms.
>
>There are no relevant nits in the document.
>
>I believe the document does not cause any issues related to operations and
>management. It has a clear language and looks ready for publication.
>
>Mehmet
>
>

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

Re: [OSPF] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Acee Lindem (acee)]

Hi Lada,

Apologies for the delay. We somewhat got hung up on 4 and 6. See inline.

On 12/6/17, 6:26 AM, "Ladislav Lhotka"  wrote:

>Reviewer: Ladislav Lhotka
>Review result: Ready with Issues
>
>The data model defined in this document is a massive piece of work: it
>consists of 11 YANG modules and defines around 1200 schema nodes. The
>"ietf-ospf@2017-10-30" module is compatible with the NMDA architecture.
>
> Comments
>
>1. Unless there is a really compelling reason not to do so, the
>   "ietf-ospf" should declare YANG version 1.1. For one,
>   "ietf-routing" that is being augmented by "ietf-ospf" already
>   declares this version. Some of my suggestions below also assume
>   version 1.1.

We will add this. 


>
>2. The "ietf-ospf" can work only with the new NMDA-compatible
>   revisions of some modules, such as "ietf-interfaces" and
>   "ietf-routing". I understand it is not desirable to import such
>   modules by revision, but at least it should be mentioned in a
>   description attached to every such import.

We will add comments to the description.
>
>3. Maybe the draft could mention that implementations should supply a
>   default routing domain as a system-controlled resource.

Isn’t this more of an RFC8022BIS statement? I guess we could state this as
an assumption. 
>
>4. In "when" expressions, the module uses literal strings for
>   identities. This is known to be problematic, the XPath functions
>   derived-from() or derived-from-or-self() should be used instead.

Why is this problematic? Is it because the types can be extended?

>
>5. Some enumerations, such as "packet-type" and "if-state-type"
>   define enum identifiers with uppercase letters and/or underscores,
>   for example "Database-Description" or "LONG_WAIT". RFC6087bis
>   recommends that only lowercase letters, numbers and dashes. I think
>   this convention should be observed despite the fact that the
>   current names are traditionally used in OSPF specs. The
>   "ietf-routing" module also defines "router-id" even though the
>   documents use "Router ID".

I agree - we will follow the RFC 6087BIS guidelines.


>
>6. The types of LSA headers are modelled as integers. While OSPF gurus
>   probably know these numbers by heart, it is not very
>   reader-frienly. So at least some references to documents defining
>   these numbers should be provided, but my suggestion is to consider
>   implementing them with identities. It seems it might also be useful
>   to define some "abstract" identities for these types. For example,
>   if "opaque-lsa" is defined, then the definition of container
>   "opaque" could simply use
>
> when "derived-from(../../header/type, 'ospf:opaque-lsa')";
>
>   instead of
>
>  when "../../header/type = 9 or "
>  + "../../header/type = 10 or "
>  + "../../header/type = 11";

I guess I don’t see the identities as always being better. We will
consider this one. 


>
>7. The title of sec. 2.9 should be "OSPF Notifications" rather than
>   "OSPF notification".

Sure. 

Thanks,
Acee 
>
>

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Acee Lindem (acee)]

Works for me.
Acee

From: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>
Date: Friday, January 5, 2018 at 11:15 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg 
(ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "Ketan Talaulikar 
(ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

How about “graceful-link-shutdown” ?

Rgds
Shraddha



From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Friday, January 5, 2018 6:50 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel 
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Acee Lindem (acee)]

It is not in “maintenance" mode yet as it is still being used. However, it is 
better than “overload”. “pending-maintenance” is a bit long which is why I 
suggested “pending-shutdown” since “shutdown” is term that vendors have used 
for eons to described an interface that is not in service.
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 11:56 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com<mailto:ket...@cisco.com>>, 
Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Ketan –

“maintenance” I could live with.

“GIR” seems to not be generic enough.

   Les


From: Ketan Talaulikar (ketant)
Sent: Thursday, January 04, 2018 8:09 PM
To: Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>>; Les Ginsberg 
(ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Joel Halpern 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11

Hello,

May I suggest something more generic like “Maintenance Mode” or “Graceful 
Insertion/Removal (GIR) Mode” which could be defined so as to cover the 
multiple scenarios in question (e.g. pending shutdown, down for repairs, last 
resort due to poor link quality, etc.).

Thanks,
Ketan

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 05 January 2018 08:14
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; 
Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; 
gen-...@ietf.org<mailto:gen-...@ietf.org>
Cc: ospf@ietf.org<mailto:ospf@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

Hi Les,

From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" 
<j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>"
 
<draft-ietf-ospf-link-overload@ietf.org<mailto:draft-ietf-ospf-link-overload@ietf.org>>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to 

Re: [OSPF] Genart last call review of draft-ietf-ospf-link-overload-11

[Acee Lindem (acee)]

Hi Les,

From: "Les Ginsberg (ginsberg)" >
Date: Thursday, January 4, 2018 at 9:26 PM
To: Acee Lindem >, "Joel M. Halpern" 
>, 
"gen-...@ietf.org" 
>
Cc: OSPF WG List >, 
"i...@ietf.org" >, 
"draft-ietf-ospf-link-overload@ietf.org"
 
>
Subject: RE: Genart last call review of draft-ietf-ospf-link-overload-11


> >Minor issues:

> >I understand the WG likes using the term "overload" for a link

> >being taken

> >out of service.  I think people will learn what we mean.  I do wish

> >we had

> >not chosen to misuse the words in this fashion.  This is much more a

> >graceful-link-close indication (or clsoe-pending indication) than

> >it is an

> >overload indication.

>

> I agree with this comment but I wasn’t sure we’d reach consensus on a

> better alternative. However, after some though and consideration of current

> OSPF router terminology, I’d propose we use the term “Pending-Shutdown”.

> Does anyone not agree that this is a more appropriate moniker for the TLV

> and state?

>

[Les:] I agree with Joel's comment. The use of the term "overload" is 
unfortunate.

But "pending-shutdown" isn’t appealing to me because - at least in most use 
cases - you aren't actually going to shutdown the link. What you are going to 
do is make a link the "link of last resort".

This seems a better choice.

That is not the use case - you are going to take the link down. It is not going 
to be the "link of last resort”, it is the currently the “link of last resort” 
and will imminently be taken down.




The suggestion from Shraddha that this term was borrowed from IS-IS isn't 
accurate. "overload" in IS-IS has a very different meaning - it indicates a 
node either has an incomplete LSDB or (a la RFC 
3277 )an incomplete forwarding plane.



The only use of "link overload" in IS-IS occurs in 
https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and 
this was added recently to support the (very useful) TE use case which was 
defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When 
this was done the term "link-overload" was cut and pasted from the OSPF draft. 
I think this should also be changed in the IS-IS draft.

Agreed.

Thanks,
Acee



   Les



> Thanks,

> Acee

> >

> >

> >

>

> ___

> 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] Genart last call review of draft-ietf-ospf-link-overload-11

[Acee Lindem (acee)]

Hi Joel, 

On 1/4/18, 6:32 PM, "Joel Halpern"  wrote:

>Reviewer: Joel Halpern
>Review result: Ready
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
>.
>
>Document: draft-ietf-ospf-link-overload-11
>Reviewer: Joel Halpern
>Review Date: 2018-01-04
>IETF LC End Date: 2018-01-16
>IESG Telechat date: 2018-01-25
>
>Summary: This document is ready for publication as a Proposed Standard
>
>Major issues:
>N/A; my concerns from earlier versions have been addressed.
>
>Minor issues:
>I understand the WG likes using the term "overload" for a link being
>taken
>out of service.  I think people will learn what we mean.  I do wish
>we had
>not chosen to misuse the words in this fashion.  This is much more a
>graceful-link-close indication (or clsoe-pending indication) than it
>is an
>overload indication.

I agree with this comment but I wasn’t sure we’d reach consensus on a
better alternative. However, after some though and consideration of
current OSPF router terminology, I’d propose we use the term
“Pending-Shutdown”. Does anyone not agree that this is a more appropriate
moniker for the TLV and state?

Thanks,
Acee 
>
>
>

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

Re: [OSPF] AD review of draft-ietf-ospf-ospfv3-lsa-extend

[Acee Lindem (acee)]

Hi Alia,

Thanks for your comments. I  believe that the –20 version addresses them. 
Please  see inline.

From: Alia Atlas >
Date: Tuesday, December 19, 2017 at 6:49 PM
To: 
"draft-ietf-ospf-ospfv3-lsa-ext...@ietf.org"
 
>,
 OSPF WG List >
Subject: AD review of draft-ietf-ospf-ospfv3-lsa-extend
Resent-From: >
Resent-To: Acee Lindem >, 
>, "Goethals, Dirk (Nokia - BE/Antwerp)" 
>, 
>, Fred Baker 
>
Resent-Date: Tuesday, December 19, 2017 at 6:49 PM

As is customary, I have done my AD review of 
draft-ietf-ospf-ospfv3-lsa-extend-19.  First, I would like to thank the authors 
- Acee, Abhay, Dirk, Veerendranatha, and Fred- and the implementors at Nokia 
and Huawei (who have enabled us to move forward on this critical document) and 
the WG.  This draft is very important for adding improved  flexiblity to OSPFv3 
for IPv6 compared to what we enjoy for OSPFv2.

I do have some minor concerns and nits - as listed below. I am going to put 
this document into a 3 week IETF Last Call (given the holiday season) and place 
it on the telechat for Jan 25, 2018.  Please do respond and update the draft in 
a timely fashion (given I'm on vacation until 2018).

1)  Given the extensive changes to OSPFv3 and the expectation that 
implementations of OSPFv3 will support this, the draft should update RFC 5340 
(and mention that in the abstract as well).

I have indicated that the draft updates both RFC 5340 and RFC 5838.

2) In Sec 3: it would be helpful to indicate how many levels of nesting of TLVs 
are supported.  There are clearly TLVs and sub-TLVs.  Can there be 
sub-sub-TLVs?  Can there be an arbitrarily deep level of sub-TLVs?  Please just 
clarify - b/c it can affect folks implementations and also assumptions for how 
to define the various sub-TLVs.

This is really not an issue as demonstrated by the nesting of Sub-TLVs in GMPLS 
technology specific OSPF TE LSAs. I think it is a mistake that a big deal is 
made of this in IS-IS. Nevertheless, I have added:

   While this document only describes the usage of TLVs and
   Sub-TLVs, Sub-TLVs may be nested to any level as long as the Sub-TLVs
   are fully specified in the specification for the subsuming Sub-TLV.

3) Sec 3.3: Is there a reason that sub-TLVs aren't listed in the figure?  I see 
them in the figures for sec 3.2 and 3.4 without explanation.  Consistency would 
be good. I could picture it being helpful to include, for instance, an SRLG or 
other information.

The reason that there are no Sub-TLVs described, is that none are allowed for 
the Attached-Routers TLV. The reasoning for is included in the text.


   There are two reasons for not having a separate TLV or sub-TLV for
   each adjacent neighbor.  The first is to discourage using the E-
   Network-LSA for more than its current role of solely advertising the
   routers attached to a multi-access network.  The router's metric as
   well as the attributes of individual attached routers should be
   advertised in their respective E-Router-LSAs.  The second reason is
   that there is only a single E-Network-LSA per multi-access link with
   the Link State ID set to the Designated Router's Interface ID and,
   consequently, compact encoding has been chosen to decrease the
   likelihood that the size of the E-Network-LSA will require IPv6
   fragmentation when advertised in an OSPFv3 Link State Update packet.


4) Sec 4.1: Please clarify whether an E-Router-LSA is malformed if it does not 
contain at least one Router-Link TLV.

I have added this.

   Depending on the implementation, it is perfectly valid for an E-
   Router-LSA to not contain any Router-Link TLVs.  However, this would
   imply that the OSPFv3 router doesn't have any active interfaces in
   the corresponding area and such E-Router-LSA would never be flooded
   to other OSPFv3 routers in the area.


5) Sec 4.7: I believe it is possible to have multiple IPv6 link-local 
addresses. I do see that RFC 5340 restricted OSPFv3 to advertising just one.  
Is there a strong reason that if additional are sent  "Instances following the 
first MUST be ignored." ?  Perhaps this could be a SHOULD - to allow for 
flexibility?

Ok – I have changed this although I’m not familiar with the use case for 
multiples.

6) Sec 5: "an LSA MUST be considered malformed if it does not include any 
required TLV or Sub-TLVs."  should be "...not include all of the required TLVs 
or sub-TLVs." or the equiv.

I have fixed this.

   Additionally, an LSA MUST be 

Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-20.txt

[Acee Lindem (acee)]

This version addresses Alia’s Routing AD comments.
Thanks,
Acee

On 12/26/17, 6:32 PM, "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 WG of the
>IETF.
>
>Title   : OSPFv3 LSA Extendibility
>Authors : Acee Lindem
>  Abhay Roy
>  Dirk Goethals
>  Veerendranatha Reddy Vallem
>  Fred Baker
>   Filename: draft-ietf-ospf-ospfv3-lsa-extend-20.txt
>   Pages   : 38
>   Date: 2017-12-26
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>   This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,
>   "Support of Address Families in OSPFv3".
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-20
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-20
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-20
>
>
>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

Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-19.txt

[Acee Lindem (acee)]

This version fixes the "IANA Considerations" OSPFv3 Extended LSA Sub-TLV
registry to match the body of the draft. Additionally, more guidance is
provided in the management and allocation of the added registries. Hence,
the changes are confirmed to the “IANA Considerations” section.

On 12/18/17, 7:55 PM, "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 WG of the
>IETF.
>
>Title   : OSPFv3 LSA Extendibility
>Authors : Acee Lindem
>  Abhay Roy
>  Dirk Goethals
>  Veerendranatha Reddy Vallem
>  Fred Baker
>   Filename: draft-ietf-ospf-ospfv3-lsa-extend-19.txt
>   Pages   : 38
>   Date: 2017-12-18
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-19
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-19
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-19
>
>
>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

Re: [OSPF] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

Hi Amanda, 

Right - assignments for the Remote IPv4 address Sub-TLV, Local/Remote
Interface ID Sub-TLV, and Link-Overload Sub-TLV should be taken from the
unassigned values (7-32767). The values in the draft were suggested since
they were unassigned when the draft was first authored. However, to the
best of my knowledge, there are no implementations using these values.

Thanks,
Acee 

On 12/15/17, 2:15 PM, "OSPF on behalf of Amanda Baber via RT"
<ospf-boun...@ietf.org on behalf of iana-prot-param-comm...@iana.org>
wrote:

>Hi Acee, Peter,
>
>Acee replied: 
>
>> >Is the first registry, "OSPF Extended Link TLVs Registry," meant to
>>refer
>> >to  "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV
>> >Sub-TLVs"? In the first of those, values 4, 5, and 11 are available. In
>> >the second, values 4 and 5 are not available. Please see
>> >
>> >https://www.iana.org/assignments/ospfv2-parameters
>> 
>> Sounds good to me.
>
>Are we making the assignments in OSPF Extended Link TLVs Registry, which
>does have the values available? It looks like Peter wrote below that
>these should instead be allocated from the second option, the OSPFv2
>Extended Link TLV Sub-TLVs registry, where values 4 and 5 have already
>been assigned.
>
>thanks,
>Amanda
>
>On Thu Dec 14 08:52:23 2017, ppse...@cisco.com wrote:
>> Hi Acee,
>> 
>> On 14/12/17 01:39 , Acee Lindem (acee) wrote:
>> > Please provide allocations for the code points in
>> > draft-ietf-ospf-link-overload-10.txt:
>> >
>> >   OSPF Extended Link TLVs Registry
>> 
>> more precisely, these should be allocated from "OSPFv2 Extended Link
>>TLV 
>> Sub-TLVs" registry. The text in the draft should be updated as well to
>> reflect the correct registry name. At this point it says "OSPF Extended
>> Link TLVs Registry", which would suggest it is from a different, top
>> level TLV registry.
>> 
>> Also I see that value 5 has been taken by RFC8169 already.
>> 
>> thanks,
>> Peter
>> 
>> >
>> > i) Link-Overload sub-TLV - Suggested value 5
>> >
>> > ii) Remote IPv4 address sub-TLV - Suggested value 4
>> >
>> > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11
>> >
>> > OSPFV3 Router Link TLV Registry
>> >
>> > i) Link-Overload sub-TLV - suggested value 4
>> >
>> > BGP-LS Link NLRI Registry [RFC7752]
>> >
>> > i)Link-Overload TLV - Suggested 1101
>> >
>> > Thanks,
>> >
>> > Acee
>> >
>> > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>> >
>> >> Acee Lindem has requested publication of
>>draft-ietf-ospf-link-overload-10
>> >> as Proposed Standard on behalf of the OSPF working group.
>> >>
>> >> Please verify the document's state at
>> >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>> >>
>> >
>> > ___
>> > 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] [IANA #992646] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

Hi Amanda, 

On 12/14/17, 7:55 PM, "Amanda Baber via RT"
<iana-prot-param-comm...@iana.org> wrote:

>Hi all,
>
>As Peter pointed out, there appear to be issues with these registrations.
>
>Is the first registry, "OSPF Extended Link TLVs Registry," meant to refer
>to  "OSPFv2 Extended Link Opaque LSA TLVs" or "OSPFv2 Extended Link TLV
>Sub-TLVs"? In the first of those, values 4, 5, and 11 are available. In
>the second, values 4 and 5 are not available. Please see
>
>https://www.iana.org/assignments/ospfv2-parameters

Sounds good to me.

>
>For the second registry in the document, if "OSPFV3 Router Link TLV
>Registry" refers to "OSPFv3 Router LSA Link Types," value 4 is not
>available. Please see
>
>https://www.iana.org/assignments/ospfv3-parameters

Let’s defer this for now. We don’t even have early allocation for the
registries yet and this would be requested for “OSPFv3 Extended LSAs”.
Sorry for not seeing this in my initial E-mail. We recently reinstated the
OSPFv3 specification since OSPFv3 Extended LSAs is being progressed.

>
>For the third registry in the document, if "BGP-LS Link NLRI Registry"
>refers to "BGP-LS NLRI-Types," value 1101 is available, but because this
>is a Specification Required registry, we'll have to ask the designated
>experts to confirm that this is OK. Can you confirm that this is the
>correct registry?
>
>https://www.iana.org/assignments/bgp-ls-parameters

Sounds good, I’ve copied Hannes and Adrian.

Thanks,
Acee


>You can see a list of registries here:
>
>https://www.iana.org/protocols
>
>thanks,
>
>Amanda Baber
>Lead IANA Services Specialist
>
>On Thu Dec 14 08:52:23 2017, ppse...@cisco.com wrote:
>> Hi Acee,
>> 
>> On 14/12/17 01:39 , Acee Lindem (acee) wrote:
>> > Please provide allocations for the code points in
>> > draft-ietf-ospf-link-overload-10.txt:
>> >
>> >   OSPF Extended Link TLVs Registry
>> 
>> more precisely, these should be allocated from "OSPFv2 Extended Link
>>TLV 
>> Sub-TLVs" registry. The text in the draft should be updated as well to
>> reflect the correct registry name. At this point it says "OSPF Extended
>> Link TLVs Registry", which would suggest it is from a different, top
>> level TLV registry.
>> 
>> Also I see that value 5 has been taken by RFC8169 already.
>> 
>> thanks,
>> Peter
>> 
>> >
>> > i) Link-Overload sub-TLV - Suggested value 5
>> >
>> > ii) Remote IPv4 address sub-TLV - Suggested value 4
>> >
>> > iii) Local/Remote Interface ID sub-TLV - Suggested Value 11
>> >
>> > OSPFV3 Router Link TLV Registry
>> >
>> > i) Link-Overload sub-TLV - suggested value 4
>> >
>> > BGP-LS Link NLRI Registry [RFC7752]
>> >
>> > i)Link-Overload TLV - Suggested 1101
>> >
>> > Thanks,
>> >
>> > Acee
>> >
>> > On 12/13/17, 2:57 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>> >
>> >> Acee Lindem has requested publication of
>>draft-ietf-ospf-link-overload-10
>> >> as Proposed Standard on behalf of the OSPF working group.
>> >>
>> >> Please verify the document's state at
>> >> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>> >>
>> >
>> > ___
>> > 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] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

On 12/14/17, 7:59 AM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote:

>On Wed, Dec 13, 2017, at 07:52 PM, Acee Lindem (acee) wrote:
>> Hi Alexey
>> 
>> These all seem to be valid comments except for the one on byte order.
>> Note
>> that section 3.1 of RFC 2360 already states that IETF document packet
>> encodings are in Network-Byte Order (NBO).
>> https://www.ietf.org/rfc/rfc2360.txt
>
>Well, lots of recent RFCs violate this, so repeating it doesn't hurt.

Can you provide an example? IETF standard packets should always be in
Network-Byte Order.

Thanks,
Acee 
>
>> Typically, we have not defined Reserved field usage. However, I guess we
>> could say that they SHOULD be set to 0 on transmission and MUST be
>> ignored
>> on reception.
>
>Yes, please. Just mention it once early in the document.
>
>> This will allow for future reuse in a backward compatible
>> manner. 
>> Thanks,
>> Acee 
>> 
>> 
>> 
>> 
>> 
>> On 12/13/17, 5:47 AM, "Alexey Melnikov" <aamelni...@fastmail.fm> wrote:
>> 
>> >Alexey Melnikov has entered the following ballot position for
>> >draft-ietf-ospf-segment-routing-extensions-23: Discuss
>> >
>> >When responding, please keep the subject line intact and reply to all
>> >email addresses included in the To and CC lines. (Feel free to cut this
>> >introductory paragraph, however.)
>> >
>> >
>> >Please refer to
>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>> >for more information about IESG DISCUSS and COMMENT positions.
>> >
>> >
>> >The document, along with other ballot positions, can be found here:
>> 
>>>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensi
>>>on
>> >s/
>> >
>> >
>> >
>> >--
>> >DISCUSS:
>> >--
>> >
>> >This is generally a clearly written document, but it needs a few minor
>> >changes
>> >before I can recommend its approval for publication.
>> >
>> >1) In Section 3.2:
>> >
>> >   o  When a router receives multiple overlapping ranges, it MUST
>> >  conform to the procedures defined in
>> >  [I-D.ietf-spring-conflict-resolution].
>> >
>> >RFC 2119 keyword usage makes the reference a Normative reference, yet
>>it
>> >is
>> >currently listed as informative.
>> >
>> >3.4.  SRMS Preference TLV
>> >
>> >   The Segment Routing Mapping Server Preference TLV (SRMS Preference
>> >   TLV) is used to advertise a preference associated with the node that
>> >   acts as an SR Mapping Server.  The role of an SRMS is described in
>> >   [I-D.ietf-spring-segment-routing-ldp-interop].
>> >
>> >As draff-ietf-spring-segment-routing-ldp-interop needs to be read in
>> >order to
>> >understand what SR Mapping Server is, this reference must also be
>> >Normative.
>> >
>> >  SRMS preference is defined in [I-D.ietf-spring-conflict-resolution].
>> >
>> >This just confirms that this reference must be Normative.
>> >
>> >2) In Section 3.1:
>> >
>> >   When multiple SR-Algorithm TLVs are received from a given router,
>>the
>> >   receiver SHOULD use the first occurrence of the TLV in the Router
>> >   Information LSA.  If the SR-Algorithm TLV appears in multiple Router
>> >   Information LSAs that have different flooding scopes, the SR-
>> >   Algorithm TLV in the Router Information LSA with the area-scoped
>> >   flooding scope SHOULD be used.  If the SR-Algorithm TLV appears in
>> >   multiple Router Information LSAs that have the same flooding scope,
>> >   the SR-Algorithm TLV in the Router Information (RI) LSA with the
>> >   numerically smallest Instance ID SHOULD be used and subsequent
>> >   instances of the SR-Algorithm TLV SHOULD be ignored.
>> >
>> >In the last 2 sentences: why are you using SHOULD (twice) instead of
>> >MUST? This
>> >seems to affect interoperability.
>> >
>> >(I think there is similar text in another section.)
>> >
>> >
>> >--
>> >COMMENT:
>> >--
>> >
>> >Several TLVs have "Reserved" fields, yet you never explain what
>>"Reserved"
>> >means. You do explain what reserved flags mean in some of them. I
>>suggest
>> >either explicitly explaining what Reserved means in each case or
>>specify
>> >this
>> >in the terminology section near the beginning of the document.
>> >
>> >The document never specifies byte order for length fields.
>> >
>> >The acronym NSSA is never explained and it has no reference.
>> >
>> >
>> 

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

Re: [OSPF] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

Thanks Peter - Agree the registry needs to be updated.
Acee 

On 12/14/17, 3:52 AM, "Peter Psenak (ppsenak)" <ppse...@cisco.com> wrote:

>Hi Acee,
>
>On 14/12/17 01:39 , Acee Lindem (acee) wrote:
>> Please provide allocations for the code points in
>> draft-ietf-ospf-link-overload-10.txt:
>>
>>   OSPF Extended Link TLVs Registry
>
>more precisely, these should be allocated from "OSPFv2 Extended Link TLV
>Sub-TLVs" registry. The text in the draft should be updated as well to
>reflect the correct registry name. At this point it says "OSPF Extended
>Link TLVs Registry", which would suggest it is from a different, top
>level TLV registry.
>
>Also I see that value 5 has been taken by RFC8169 already.
>
>thanks,
>Peter
>
>>
>> i) Link-Overload sub-TLV - Suggested value 5
>>
>> ii) Remote IPv4 address sub-TLV - Suggested value 4
>>
>> iii) Local/Remote Interface ID sub-TLV - Suggested Value 11
>>
>> OSPFV3 Router Link TLV Registry
>>
>> i) Link-Overload sub-TLV - suggested value 4
>>
>> BGP-LS Link NLRI Registry [RFC7752]
>>
>> i)Link-Overload TLV - Suggested 1101
>>
>> Thanks,
>>
>> Acee
>>
>> On 12/13/17, 2:57 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>>
>>> Acee Lindem has requested publication of
>>>draft-ietf-ospf-link-overload-10
>>> as Proposed Standard on behalf of the OSPF working group.
>>>
>>> Please verify the document's state at
>>> https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>>>
>>
>> ___
>> 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] FW: Publication has been requested for draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

Please provide allocations for the code points in
draft-ietf-ospf-link-overload-10.txt:

 OSPF Extended Link TLVs Registry

   i) Link-Overload sub-TLV - Suggested value 5

   ii) Remote IPv4 address sub-TLV - Suggested value 4

   iii) Local/Remote Interface ID sub-TLV - Suggested Value 11

   OSPFV3 Router Link TLV Registry

   i) Link-Overload sub-TLV - suggested value 4

   BGP-LS Link NLRI Registry [RFC7752]

i)Link-Overload TLV - Suggested 1101

Thanks,

Acee 

On 12/13/17, 2:57 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

>Acee Lindem has requested publication of draft-ietf-ospf-link-overload-10
>as Proposed Standard on behalf of the OSPF working group.
>
>Please verify the document's state at
>https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/
>

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

Re: [OSPF] OSPF Working Group Last Call for "OSPF Link Overload" - draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

The WG Last Call has completed. I’m requesting publication and IANA Early 
allocation of the code points.
Thanks,
Acee

From: OSPF > on behalf of 
Acee Lindem >
Date: Tuesday, November 28, 2017 at 9:12 AM
To: OSPF WG List >
Subject: [OSPF] OSPF Working Group Last Call for "OSPF Link Overload" - 
draft-ietf-ospf-link-overload-10

This begins the OSPF Working Group Last Call for the subject document. Please 
submit comments to this list before 12:00 AM PST on Wednesday, December 13th, 
2017. For your convenience, here is a URL for the draft:

https://www.ietf.org/id/draft-ietf-ospf-link-overload-10.txt

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

Re: [OSPF] Alexey Melnikov's Discuss on draft-ietf-ospf-segment-routing-extensions-23: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Alexey

These all seem to be valid comments except for the one on byte order. Note
that section 3.1 of RFC 2360 already states that IETF document packet
encodings are in Network-Byte Order (NBO).
https://www.ietf.org/rfc/rfc2360.txt

Typically, we have not defined Reserved field usage. However, I guess we
could say that they SHOULD be set to 0 on transmission and MUST be ignored
on reception. This will allow for future reuse in a backward compatible
manner. 

Thanks,
Acee 





On 12/13/17, 5:47 AM, "Alexey Melnikov"  wrote:

>Alexey Melnikov has entered the following ballot position for
>draft-ietf-ospf-segment-routing-extensions-23: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension
>s/
>
>
>
>--
>DISCUSS:
>--
>
>This is generally a clearly written document, but it needs a few minor
>changes
>before I can recommend its approval for publication.
>
>1) In Section 3.2:
>
>   o  When a router receives multiple overlapping ranges, it MUST
>  conform to the procedures defined in
>  [I-D.ietf-spring-conflict-resolution].
>
>RFC 2119 keyword usage makes the reference a Normative reference, yet it
>is
>currently listed as informative.
>
>3.4.  SRMS Preference TLV
>
>   The Segment Routing Mapping Server Preference TLV (SRMS Preference
>   TLV) is used to advertise a preference associated with the node that
>   acts as an SR Mapping Server.  The role of an SRMS is described in
>   [I-D.ietf-spring-segment-routing-ldp-interop].
>
>As draff-ietf-spring-segment-routing-ldp-interop needs to be read in
>order to
>understand what SR Mapping Server is, this reference must also be
>Normative.
>
>  SRMS preference is defined in [I-D.ietf-spring-conflict-resolution].
>
>This just confirms that this reference must be Normative.
>
>2) In Section 3.1:
>
>   When multiple SR-Algorithm TLVs are received from a given router, the
>   receiver SHOULD use the first occurrence of the TLV in the Router
>   Information LSA.  If the SR-Algorithm TLV appears in multiple Router
>   Information LSAs that have different flooding scopes, the SR-
>   Algorithm TLV in the Router Information LSA with the area-scoped
>   flooding scope SHOULD be used.  If the SR-Algorithm TLV appears in
>   multiple Router Information LSAs that have the same flooding scope,
>   the SR-Algorithm TLV in the Router Information (RI) LSA with the
>   numerically smallest Instance ID SHOULD be used and subsequent
>   instances of the SR-Algorithm TLV SHOULD be ignored.
>
>In the last 2 sentences: why are you using SHOULD (twice) instead of
>MUST? This
>seems to affect interoperability.
>
>(I think there is similar text in another section.)
>
>
>--
>COMMENT:
>--
>
>Several TLVs have "Reserved" fields, yet you never explain what "Reserved"
>means. You do explain what reserved flags mean in some of them. I suggest
>either explicitly explaining what Reserved means in each case or specify
>this
>in the terminology section near the beginning of the document.
>
>The document never specifies byte order for length fields.
>
>The acronym NSSA is never explained and it has no reference.
>
>

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

Re: [OSPF] IPR Poll "OSPF Link Overload"

[Acee Lindem (acee)]

Hi Pushpasis,
Please respond to the IPR poll. All other authors have responded.
Thanks,
Acee

From: OSPF > on behalf of 
Acee Lindem >
Date: Saturday, October 21, 2017 at 1:50 PM
To: 
"draft-ietf-ospf-link-overl...@ietf.org"
 
>
Cc: OSPF WG List >
Subject: [OSPF] IPR Poll "OSPF Link Overload"

Authors,

Please indicate whether you are aware of any relevant IPR and if so,
whether it has been disclosed.

The following IPR has been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-ospf-link-overload

Thanks,
Acee

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

[OSPF] OSPF Working Group Last Call for "OSPF Link Overload" - draft-ietf-ospf-link-overload-10

[Acee Lindem (acee)]

This begins the OSPF Working Group Last Call for the subject document. Please 
submit comments to this list before 12:00 AM PST on Wednesday, December 13th, 
2017. For your convenience, here is a URL for the draft:

https://www.ietf.org/id/draft-ietf-ospf-link-overload-10.txt

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

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-22.txt

[Acee Lindem (acee)]

Thanks Peter - I missed this one in my look at the new revision.
Acee 

On 11/27/17, 7:02 AM, "Peter Psenak (ppsenak)" <ppse...@cisco.com> wrote:

>Hi Acee,
>
>there is one more change.
>
>TLV type for the SRMS Preference TLV was changed from 13 to 15, as value
>13 was taken by "Tunnel Encapsulations".
>
>thanks,
>Peter
>
>
>On 27/11/17 12:57 , Acee Lindem (acee) wrote:
>> The only change in this version is to update the IANA IGP Algorithm Type
>> registry name based on our discussions.
>>
>> Thanks,
>> Acee
>>
>> On 11/27/17, 6:44 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 WG of the
>>> IETF.
>>>
>>> Title   : OSPF Extensions for Segment Routing
>>> Authors : Peter Psenak
>>>   Stefano Previdi
>>>   Clarence Filsfils
>>>   Hannes Gredler
>>>   Rob Shakir
>>>   Wim Henderickx
>>>   Jeff Tantsura
>>> Filename: draft-ietf-ospf-segment-routing-extensions-22.txt
>>> Pages   : 28
>>> Date: 2017-11-27
>>>
>>> Abstract:
>>>Segment Routing (SR) allows a flexible definition of end-to-end
>>>paths
>>>within IGP topologies by encoding paths as sequences of topological
>>>sub-paths, called "segments".  These segments are advertised by the
>>>link-state routing protocols (IS-IS and OSPF).
>>>
>>>This draft describes the OSPF extensions required for Segment
>>>Routing.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> 
>>>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensi
>>>on
>>> s/
>>>
>>> There are also htmlized versions available at:
>>> 
>>>https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-2
>>>2
>>> 
>>>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-ex
>>>te
>>> nsions-22
>>>
>>> A diff from the previous version is available at:
>>> 
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extens
>>>io
>>> ns-22
>>>
>>>
>>> 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

Re: [OSPF] Request for Early IANA allocation for draft-ietf-ospf-lls-interface-id

[Acee Lindem (acee)]

Hi Peter, 
I will initiate the early allocation.
Thanks,
Acee 

On 11/20/17, 4:53 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
 wrote:

>Hi OSPF WG Chairs,
>
>authors of draft-ietf-ospf-lls-interface-id would like to request early
>code-point allocation from IANA as follows:
>
>Registry:  Link Local Signalling TLV Identifiers
>Value: 18
>Description: Local Interface Identifier TLV
>
>thanks,
>Peter
>
>___
>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] IS-IS and OSPF Call for agenda slots @ IETF-100

[Acee Lindem (acee)]

On 11/1/17, 1:31 PM, "Christian Hopps" <cho...@chopps.org> wrote:

>
>Acee Lindem (acee) <a...@cisco.com> writes:
>
>> Hi Chris, et al,
>>
>> The authors of "OSPF Graceful Restart Enhancements”,
>> draft-basavaraj-ospf-graceful-restart-enhancements-00 would like a 10
>> minute slot at IETF 100.
>
>ACK.
>
>Who's presenting?

Put me for now. 

Thanks,
Acee 

>
>Thanks,
>Chris.
>
>>
>> Thanks,
>> Acee
>>
>>
>> On 10/19/17, 9:55 AM, "Christian Hopps" <cho...@chopps.org> wrote:
>>
>>>
>>>Hi OSPF and IS-IS,
>>>
>>>The preliminary agenda has been posted:
>>>
>>>   https://datatracker.ietf.org/meeting/100/agenda.html
>>>
>>>Our 2.5h joint session of IS-IS and OSPF is tentatively scheduled for
>>>Thursday from 9:30am to 12:00pm (+08).
>>>
>>>Please send your requests for a presentation slot, indicating
>>>draft name, speaker, and desired duration (covering presentation and
>>>discussion) to isis-cha...@ietf.org or ospf-cha...@ietf.org.
>>>
>>>Thanks,
>>>Abhay, Acee, Chris and Hannes.
>

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

Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-17.txt

[Acee Lindem (acee)]

Simply updated Veeru’s contact information to avoid bounces to draft alias
ASAP. 
Thanks,
Acee

On 10/30/17, 11:51 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 WG of the
>IETF.
>
>Title   : OSPFv3 LSA Extendibility
>Authors : Acee Lindem
>  Abhay Roy
>  Dirk Goethals
>  Veerendranatha Reddy Vallem
>  Fred Baker
>   Filename: draft-ietf-ospf-ospfv3-lsa-extend-17.txt
>   Pages   : 37
>   Date: 2017-10-30
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-17
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-17
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-17
>
>
>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

Re: [OSPF] Working Group Last Call for draft-ietf-ospf-ospfv3-lsa-extend

[Acee Lindem (acee)]

Note that the OSPF implementation Wiki has been updated for this draft.

https://trac.ietf.org/trac/ospf/wiki/draft-ietf-ospf-ospfv3-extend%20implementations

Thanks,
Acee

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
"Abhay Roy (akr)" <a...@cisco.com<mailto:a...@cisco.com>>
Date: Monday, October 23, 2017 at 2:06 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] Working Group Last Call for draft-ietf-ospf-ospfv3-lsa-extend

We are starting the Working Group Last Call of this revision of the subject 
draft. Draft has been stable for a while waiting for some implementations.

Also, there are multiple drafts waiting to allocate code points from the new 
IANA registries coming from this draft.

The OSPF WG last call will end at 9am PST on Nov 6 2017.

Abhay/Acee


On 10/9/17 5:32 AM, Acee Lindem (acee) wrote:

This is a simple refresh. We will WG last call this version.
Thanks,
Acee

On 10/9/17, 8:30 AM, "OSPF on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
<ospf-boun...@ietf.org on behalf of 
internet-dra...@ietf.org><mailto:ospf-bounces@ietf.orgonbehalfofinternet-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 WG of the
IETF.

   Title   : OSPFv3 LSA Extendibility
   Authors : Acee Lindem
 Abhay Roy
 Dirk Goethals
 Veerendranatha Reddy Vallem
 Fred Baker
Filename: draft-ietf-ospf-ospfv3-lsa-extend-15.txt
Pages   : 37
Date: 2017-10-09

Abstract:
  OSPFv3 requires functional extension beyond what can readily be done
  with the fixed-format Link State Advertisement (LSA) as described in
  RFC 5340.  Without LSA extension, attributes associated with OSPFv3
  links and advertised IPv6 prefixes must be advertised in separate
  LSAs and correlated to the fixed-format LSAs.  This document extends
  the LSA format by encoding the existing OSPFv3 LSA information in
  Type-Length-Value (TLV) tuples and allowing advertisement of
  additional information with additional TLVs.  Backward compatibility
  mechanisms are also described.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-15https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-15


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<mailto:OSPF@ietf.org>https://www.ietf.org/mailman/listinfo/ospf

___
OSPF mailing list
OSPF@ietf.org<mailto: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-ospfv3-lsa-extend-16.txt

[Acee Lindem (acee)]

Just fixed a typo in the Intra-Area-Prefix TLV text reported by Nagendra
Kumar.
Thanks,
Acee 

On 10/28/17, 7:17 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 WG of the
>IETF.
>
>Title   : OSPFv3 LSA Extendibility
>Authors : Acee Lindem
>  Abhay Roy
>  Dirk Goethals
>  Veerendranatha Reddy Vallem
>  Fred Baker
>   Filename: draft-ietf-ospf-ospfv3-lsa-extend-16.txt
>   Pages   : 37
>   Date: 2017-10-28
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-16
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-16
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-16
>
>
>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

Re: [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt

[Acee Lindem (acee)]

Hi Olivier, 

On 10/25/17, 5:37 AM, "olivier.dug...@orange.com"
<olivier.dug...@orange.com> wrote:

>Hi Acee,
>
>I agree, but I'm not referring to Unidirectional residual, available and
>utilized bandwidth as per RFC 7471.
>
>My comment concerns the MaximumBandwidth, MaximumReservableBandwidth and
>UnreservedBandwidth parameters defined in RFC 3630that are used by the
>CSPF to compute the path. These one are not aggregate if I correctly
>understand the proposed draft. I also don't understand why these standard
>TE parameters are duplicate in the ISIS draft and not mention in the OSPF
>draft. Do we go to a different behaviour between IS-IS and OSPF ?

If read beyond the draft title, you’ll see that these reservation
parameters are not included in draft-ietf-ospf-te-link-attr-reuse.

>
>Now, if the proposed drafts aims to used onlythese new Performance
>Metrics without duplicate them per application, my question becomes: Why
>a new drafts ? Why not simply implement RFC 7471 and RFC 7810 ? Up to
>now, I know only one partial implementation of these 2 RFCs (in
>FR-Routing Open Source project).

With respect to OSPF, this topic was already discussed at great length on
the OSPF list and during the IETF meetings in both Seoul and Chicago.
Please see the OSPF list archive.

Thanks,
Acee 
>
>Regards
>
>Olivier
>
>
>Le 25/10/2017 à 01:25, Acee Lindem (acee) a écrit :
>> Hi Olivier, 
>>
>> If you read the definitions of Unidirectional residual, available, and
>> utilized bandwidth in RFC 7471 you will note that these are all
>>aggregate
>> rather than application specific values. In other words, they will not
>> vary per application.
>>
>> Thanks,
>> Acee 
>>
>> On 10/16/17, 11:03 AM, "OSPF on behalf of olivier.dug...@orange.com"
>> <ospf-boun...@ietf.org on behalf of olivier.dug...@orange.com> wrote:
>>
>>> Dear authors,
>>>
>>> Please find below a comment on both
>>> draft-ietf-ospf-te-link-attr-reuse-01.txt and
>>> draft-ietf-isis-te-app-01.txt.
>>>
>>> I consider the use case of bandwidth reservation. I know this is not
>>>the
>>> most common use case, but the one I known well. The context is that of
>>>an
>>> operator who would setup some RSVP-TE tunnels and simultaneously SR-TE
>>> paths with bandwidth reservation. In this particular case, it is not
>>> possible to manage both reservation with the drafts as they are.
>>>
>>> Indeed, in OSPF draft, it is not proposed to advertised the usual
>>> bandwidth parameters as defined in RFC3630 and in ISIS, it is proposed
>>>to
>>> duplicate these parameters per application. The main problem arises
>>>from
>>> the fact that each application, in this case SR-TE and RSVP-TE,
>>> independently compute a path and therefore reserve bandwidth on their
>>> respective set of parameters. However, this will lead at a some point
>>>to
>>> bandwidth overbooking, which exactly what an operator wants to avoid by
>>> performing bandwidth reservation. Even if a PCE can be used to handle
>>> both the RSVP-TE tunnels and SR-TE paths, the same problem arises
>>>because
>>> each path computation is performed on a different set of bandwidth
>>> parameters i.e. one TED per application whereas these information
>>>relate
>>> to the same links. Of course a central entity like a PCE might try to
>>> reconcile the information into a single TED, but this will greatly
>>> increase the complexity of the PCE with a risk that the TE information
>>> will
>>> never be up to date, so at the end unnecessary.
>>>
>>> So, for me there are only 2 possibles solutions to avoid this
>>>overbooking
>>> problem:
>>>
>>> 1/ Split and partition network resources to avoid conflicts. But, this
>>> leads into a poor network usage. Indeed, if an application like RSVP-TE
>>> uses less bandwidth than its budget, why the SR-TE application could
>>>not
>>> reuse them if it has reached its threshold ? The under utilization of
>>> network resources will increase proportionally with the number of
>>> applications. Imagine if we want to use this principle for network
>>> Slicing. I understand the advantage for vendors, but I'm on the
>>>operator
>>> side ;-)
>>>
>>> 2/ Each time an application reserved some bandwidth, the routers
>>> concerned by this new path must update the bandwidth parameters of the
>>> concerned link not only to the given app

Re: [OSPF] Comments on draft-ietf-ospf-te-link-attr-reuse-01.txt and draft-ietf-isis-te-app-01.txt

[Acee Lindem (acee)]

Hi Olivier, 

If you read the definitions of Unidirectional residual, available, and
utilized bandwidth in RFC 7471 you will note that these are all aggregate
rather than application specific values. In other words, they will not
vary per application.

Thanks,
Acee 

On 10/16/17, 11:03 AM, "OSPF on behalf of olivier.dug...@orange.com"
 wrote:

>Dear authors,
>
>Please find below a comment on both
>draft-ietf-ospf-te-link-attr-reuse-01.txt and
>draft-ietf-isis-te-app-01.txt.
>
>I consider the use case of bandwidth reservation. I know this is not the
>most common use case, but the one I known well. The context is that of an
>operator who would setup some RSVP-TE tunnels and simultaneously SR-TE
>paths with bandwidth reservation. In this particular case, it is not
>possible to manage both reservation with the drafts as they are.
>
>Indeed, in OSPF draft, it is not proposed to advertised the usual
>bandwidth parameters as defined in RFC3630 and in ISIS, it is proposed to
>duplicate these parameters per application. The main problem arises from
>the fact that each application, in this case SR-TE and RSVP-TE,
>independently compute a path and therefore reserve bandwidth on their
>respective set of parameters. However, this will lead at a some point to
>bandwidth overbooking, which exactly what an operator wants to avoid by
>performing bandwidth reservation. Even if a PCE can be used to handle
>both the RSVP-TE tunnels and SR-TE paths, the same problem arises because
>each path computation is performed on a different set of bandwidth
>parameters i.e. one TED per application whereas these information relate
>to the same links. Of course a central entity like a PCE might try to
>reconcile the information into a single TED, but this will greatly
>increase the complexity of the PCE with a risk that the TE information
>will
>never be up to date, so at the end unnecessary.
>
>So, for me there are only 2 possibles solutions to avoid this overbooking
>problem:
>
>1/ Split and partition network resources to avoid conflicts. But, this
>leads into a poor network usage. Indeed, if an application like RSVP-TE
>uses less bandwidth than its budget, why the SR-TE application could not
>reuse them if it has reached its threshold ? The under utilization of
>network resources will increase proportionally with the number of
>applications. Imagine if we want to use this principle for network
>Slicing. I understand the advantage for vendors, but I'm on the operator
>side ;-)
>
>2/ Each time an application reserved some bandwidth, the routers
>concerned by this new path must update the bandwidth parameters of the
>concerned link not only to the given application, but also to all others.
>For example, when RSVP-TE setup a tunnel, Unreserved Bandwidth parameters
>must be updated in the standard RFC3630 set, but also in SR-TE parameters
>set. But, in this case, why duplicate TE parameters if at the end all set
>carry the same values, apart wasting CPU and bandwidth ?
>
>In summary, duplicate TE information is only relevant for the added
>metrics i.e. delay, loss, jitter ... but unusable for concave metrics
>i.e. bandwidth.
>
>Can you explain me how you intend to solve this issue as both possible
>solutions are not suitable for an operator.
>
>Best Regards
>
>Olivier
>
>__
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>___
>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] IS-IS and OSPF Call for agenda slots @ IETF-100

[Acee Lindem (acee)]

Hi Peter, 

We’ll add these to the agenda.

Thanks,
Acee 

On 10/23/17, 4:26 AM, "Peter Psenak (ppsenak)"  wrote:

>Hi Folks,
>
>authors of the following drafts would like to request a slot:
>
>- draft-ietf-ospf-lls-interface-id-00 - 10 mims
>
>- draft-hegdeppsenak-isis-sr-flex-algo-00 - 20 mins
>
>thanks,
>Peter
>
>
>On 19/10/17 15:55 , Christian Hopps wrote:
>>
>> Hi OSPF and IS-IS,
>>
>> The preliminary agenda has been posted:
>>
>> https://datatracker.ietf.org/meeting/100/agenda.html
>>
>> Our 2.5h joint session of IS-IS and OSPF is tentatively scheduled for
>> Thursday from 9:30am to 12:00pm (+08).
>>
>> Please send your requests for a presentation slot, indicating
>> draft name, speaker, and desired duration (covering presentation and
>> discussion) to isis-cha...@ietf.org or ospf-cha...@ietf.org.
>>
>> Thanks,
>> Abhay, Acee, Chris and Hannes.
>>
>>
>>
>> ___
>> 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] Request for WG last call and Early IANA allocation for draft-ietf-ospf-link-overload-09

[Acee Lindem (acee)]

Hi Shraddha,
Can you go ahead and add the OSPFv3 Extended Router-LSA encoding? We’re going 
to WG last call OSPFv3 Extended LSAs as well so it makes sense to include it 
(even if this document makes to the RFC queue first).

Thanks,
Acee

From: OSPF > on behalf of 
Acee Lindem >
Date: Friday, October 20, 2017 at 5:25 PM
To: Shraddha Hegde >, "Abhay 
Roy (akr)" >
Cc: OSPF WG List >
Subject: Re: [OSPF] Request for WG last call and Early IANA allocation for 
draft-ietf-ospf-link-overload-09

Hi Shraddha,

This sounds reasonable. I will start the WG Last Call after reading the –09 
version this weekend.

Thanks,
Acee


From: Shraddha Hegde >
Date: Friday, October 20, 2017 at 12:57 PM
To: Acee Lindem >, "Abhay Roy (akr)" 
>
Cc: OSPF WG List >
Subject: Request for WG last call and Early IANA allocation for 
draft-ietf-ospf-link-overload-09

Acee/Abhay,

All the review comments received so far from working group have been addressed 
in the latest revision draft-ietf-ospf-link-overload-09.
Authors of draft-ietf-ospf-link-overload would like to request for WG last call 
and also early code-point allocation from IANA.

Rgds
Shraddha

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

[OSPF] IPR Poll "OSPF Link Overload"

[Acee Lindem (acee)]

Authors,

Please indicate whether you are aware of any relevant IPR and if so,
whether it has been disclosed.

The following IPR has been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-ospf-link-overload

Thanks,
Acee

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

Re: [OSPF] [Bier] I-D Action: draft-ietf-bier-ospf-bier-extensions-08.txt

[Acee Lindem (acee)]

Hi Xiejing, (+OSPF List),

On 10/20/17, 5:20 AM, "BIER on behalf of Xiejingrong"
 wrote:

>HI, all:
>
>About draft-ietf-bier-ospf-bier-extensions-08.txt,
>In chap 2.1, BIER Sub-TLV is defined as a sub-tlv of the Extended Prefix
>TLV (defined in RFC7684).
>In chap 2.2, The BIER MPLS Encapsulation Sub-TLV is a Sub-TLV of the BIER
>Sub-TLV.
>In chap 2.3, The BIER Tree Type Sub-TLV is a Sub-TLV of the BIER Sub-TLV.
>In chap 2.4, The BIER sub-domain BSL conversion Sub-TLV is a Sub-TLV of
>the BIER Sub-TLV. 
>In chap 4, The document requests three new allocations from the OSPF
>Extended Prefix sub-TLV registry as defined in [RFC7684].
>
>Should the allocation for 3 Sub-TLVs of the BIER Sub-TLV be from some
>registry, other than the OSPF Extended Prefix sub-TLV registry?

No. With 64K Sub-TLV types, it is not likely that we will run out any time
soon and some of the Sub-TLVs apply to multiple TLVs.

Thanks,
Acee 
>___
>BIER mailing list
>b...@ietf.org
>https://www.ietf.org/mailman/listinfo/bier

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

[Acee Lindem (acee)]

Hi Dan,
Great – we’ll address that with your other comments.
Thanks,
Acee

From: Dan Romascanu <droma...@gmail.com<mailto:droma...@gmail.com>>
Date: Monday, October 9, 2017 at 1:58 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>, 
"draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>"
 
<draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] Genart last call review of 
draft-ietf-ospf-segment-routing-extensions-19

Hi Acee,

Indeed, that was the intention of my comment.

Thanks and Regards,

Dan


On Sun, Oct 8, 2017 at 8:15 PM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Dan,

Can you elaborate on how the OSPFv2 segment routing extensions in the draft 
make the protocol more susceptible to a DDoS attack? Is this with respect to 
logging the occurrence of malformed TLVs or Sub-TLVs? If so, that can be added.

Thanks,
Acee

From: Dan Romascanu <droma...@gmail.com<mailto:droma...@gmail.com>>
Date: Saturday, October 7, 2017 at 1:57 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>, 
"draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>"
 
<draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] Genart last call review of 
draft-ietf-ospf-segment-routing-extensions-19

Hi Acee,

Thank you for your response and for addressing my comments. I do not disagree 
that a generic IGP protocol security considerations document may be useful, but 
I do not believe that this document should be dependent upon it. My observation 
was related to the last paragraph of the Security Considerations document. It 
seems to me that non-mandatory counting or logging of malformed TLVs or 
Sub-TLVs may not be sufficient to protect against a large scale DoS attack.

Regards,

Dan


On Sat, Oct 7, 2017 at 1:54 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:


On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"
<ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org> on behalf of 
droma...@gmail.com<mailto:droma...@gmail.com>> wrote:

>Reviewer: Dan Romascanu
>Review result: Ready with Issues
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
><https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
>Document: draft-ietf-ospf-segment-routing-extensions-19
>Reviewer: Dan Romascanu
>Review Date: 2017-10-05
>IETF LC End Date: 2017-10-13
>IESG Telechat date: Not scheduled for a telechat
>
>Summary:
>
>A useful and well-written document. It requires previous reading and
>understanding of OSPF, SPRING and other routing work. It is Ready for
>publication. I found some unclear minor issues. I recommend to address
>them
>before approval and publication.
>
>Major issues:
>
>Minor issues:
>
>1. I am wondering why, at this stage of progress of the document, the type
>values are still 'TBD, suggested value x'. Is there any other document
>defining
>this?
>
>2. Section 3.1 - are there other algorithms planned to be added in the
>future?
>If yes, do we need a registry? If no, what is this field an octet?
>
>3. It would be useful to mention that the Length fields are expressed in
>Octets. Also please clarify if padding is applied or not.
>
>4. Section 3.3:
>
>'The originating router MUST NOT advertise overlapping ranges.'
>
>How are conflicts resolved at receiver?
>
>5. I like Section 9 - Implementation Status - which I found rather
>useful. Is
>there any chance to keep a trimmed down version of it, with synthetic
>information on the lines of 'at the time the document was discussed a
>survey
>was run, it showed that there were x implementation, y were imple

Re: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-lsa-extend-15.txt

[Acee Lindem (acee)]

This is a simple refresh. We will WG last call this version.
Thanks,
Acee 

On 10/9/17, 8:30 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 WG of the
>IETF.
>
>Title   : OSPFv3 LSA Extendibility
>Authors : Acee Lindem
>  Abhay Roy
>  Dirk Goethals
>  Veerendranatha Reddy Vallem
>  Fred Baker
>   Filename: draft-ietf-ospf-ospfv3-lsa-extend-15.txt
>   Pages   : 37
>   Date: 2017-10-09
>
>Abstract:
>   OSPFv3 requires functional extension beyond what can readily be done
>   with the fixed-format Link State Advertisement (LSA) as described in
>   RFC 5340.  Without LSA extension, attributes associated with OSPFv3
>   links and advertised IPv6 prefixes must be advertised in separate
>   LSAs and correlated to the fixed-format LSAs.  This document extends
>   the LSA format by encoding the existing OSPFv3 LSA information in
>   Type-Length-Value (TLV) tuples and allowing advertisement of
>   additional information with additional TLVs.  Backward compatibility
>   mechanisms are also described.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend-15
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-lsa-extend-15
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-lsa-extend-15
>
>
>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

Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

[Acee Lindem (acee)]

Hi Dan,

Can you elaborate on how the OSPFv2 segment routing extensions in the draft 
make the protocol more susceptible to a DDoS attack? Is this with respect to 
logging the occurrence of malformed TLVs or Sub-TLVs? If so, that can be added.

Thanks,
Acee

From: Dan Romascanu <droma...@gmail.com<mailto:droma...@gmail.com>>
Date: Saturday, October 7, 2017 at 1:57 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>, 
"draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>"
 
<draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, 
OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] Genart last call review of 
draft-ietf-ospf-segment-routing-extensions-19

Hi Acee,

Thank you for your response and for addressing my comments. I do not disagree 
that a generic IGP protocol security considerations document may be useful, but 
I do not believe that this document should be dependent upon it. My observation 
was related to the last paragraph of the Security Considerations document. It 
seems to me that non-mandatory counting or logging of malformed TLVs or 
Sub-TLVs may not be sufficient to protect against a large scale DoS attack.

Regards,

Dan


On Sat, Oct 7, 2017 at 1:54 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:


On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"
<ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org> on behalf of 
droma...@gmail.com<mailto:droma...@gmail.com>> wrote:

>Reviewer: Dan Romascanu
>Review result: Ready with Issues
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
><https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
>Document: draft-ietf-ospf-segment-routing-extensions-19
>Reviewer: Dan Romascanu
>Review Date: 2017-10-05
>IETF LC End Date: 2017-10-13
>IESG Telechat date: Not scheduled for a telechat
>
>Summary:
>
>A useful and well-written document. It requires previous reading and
>understanding of OSPF, SPRING and other routing work. It is Ready for
>publication. I found some unclear minor issues. I recommend to address
>them
>before approval and publication.
>
>Major issues:
>
>Minor issues:
>
>1. I am wondering why, at this stage of progress of the document, the type
>values are still 'TBD, suggested value x'. Is there any other document
>defining
>this?
>
>2. Section 3.1 - are there other algorithms planned to be added in the
>future?
>If yes, do we need a registry? If no, what is this field an octet?
>
>3. It would be useful to mention that the Length fields are expressed in
>Octets. Also please clarify if padding is applied or not.
>
>4. Section 3.3:
>
>'The originating router MUST NOT advertise overlapping ranges.'
>
>How are conflicts resolved at receiver?
>
>5. I like Section 9 - Implementation Status - which I found rather
>useful. Is
>there any chance to keep a trimmed down version of it, with synthetic
>information on the lines of 'at the time the document was discussed a
>survey
>was run, it showed that there were x implementation, y were implementing
>the
>full specification, z were included in released production software '
>
>6. Section 10 - beyond recommending the counting and logging of the
>mal-formed
>TLVs and sub-TLVs, should not supplementary security recommendations be
>made?
>for example - throttling mechanisms to preempt DoS attacks.

The generic OSPFv2 security considerations are referenced as well. Can you
be specific as to why you think there additional considerations specific
to these extensions? Perhaps, we should start work on a generic IGP
protocol security considerations document that is more comprehensive than
what we have done before.

Thanks,
Acee


>
>Nits/editorial comments:
>
>
>___
>OSPF mailing list
>OSPF@ietf.org<mailto: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] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

[Acee Lindem (acee)]

On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"
 wrote:

>Reviewer: Dan Romascanu
>Review result: Ready with Issues
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
>.
>
>Document: draft-ietf-ospf-segment-routing-extensions-19
>Reviewer: Dan Romascanu
>Review Date: 2017-10-05
>IETF LC End Date: 2017-10-13
>IESG Telechat date: Not scheduled for a telechat
>
>Summary:
>
>A useful and well-written document. It requires previous reading and
>understanding of OSPF, SPRING and other routing work. It is Ready for
>publication. I found some unclear minor issues. I recommend to address
>them
>before approval and publication.
>
>Major issues:
>
>Minor issues:
>
>1. I am wondering why, at this stage of progress of the document, the type
>values are still 'TBD, suggested value x'. Is there any other document
>defining
>this?
>
>2. Section 3.1 - are there other algorithms planned to be added in the
>future?
>If yes, do we need a registry? If no, what is this field an octet?
>
>3. It would be useful to mention that the Length fields are expressed in
>Octets. Also please clarify if padding is applied or not.
>
>4. Section 3.3:
>
>'The originating router MUST NOT advertise overlapping ranges.'
>
>How are conflicts resolved at receiver?
>
>5. I like Section 9 - Implementation Status - which I found rather
>useful. Is
>there any chance to keep a trimmed down version of it, with synthetic
>information on the lines of 'at the time the document was discussed a
>survey
>was run, it showed that there were x implementation, y were implementing
>the
>full specification, z were included in released production software '
>
>6. Section 10 - beyond recommending the counting and logging of the
>mal-formed
>TLVs and sub-TLVs, should not supplementary security recommendations be
>made?
>for example - throttling mechanisms to preempt DoS attacks.

The generic OSPFv2 security considerations are referenced as well. Can you
be specific as to why you think there additional considerations specific
to these extensions? Perhaps, we should start work on a generic IGP
protocol security considerations document that is more comprehensive than
what we have done before.

Thanks,
Acee


>
>Nits/editorial comments:
>
>
>___
>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] early AD review of draft-ietf-bier-ospf-bier-extensions-07

[Acee Lindem (acee)]

Hi Alia,

I spoke to Peter and I think the OSPFv3 Bier Extensions should go into a 
separate OSPFv3 draft. Heretofore, all the work has been done in the BIER 
working group and it seems it would make sense to do it here rather than mix 
much into the overflow draft. As for the OSPF WG, the priority needs to be to 
publish the OSPFv3 Extended LSA draft. I’ll ask Abhay to start the WG last call 
and concurrently post the implementation information.

Thanks,
Acee

From: Alia Atlas >
Date: Monday, October 2, 2017 at 2:32 PM
To: "Peter Psenak (ppsenak)" >, 
Acee Lindem >
Cc: "b...@ietf.org" 
>, OSPF WG List 
>, 
"draft-ietf-bier-ospf-bier-extensi...@ietf.org"
 
>
Subject: Re: early AD review of draft-ietf-bier-ospf-bier-extensions-07



On Mon, Oct 2, 2017 at 2:26 PM, Peter Psenak 
> wrote:
Hi Alia,

please see inline:

On 02/10/17 17:33 , Alia Atlas wrote:
On Mon, Oct 2, 2017 at 11:07 AM, Peter Psenak 

>> wrote:

Hi Alia,

please see inline:

On 02/10/17 16:41 , Alia Atlas wrote:

Hi Peter,

On Mon, Oct 2, 2017 at 10:05 AM, Peter Psenak 

>
 

Re: [OSPF] draft-ietf-ospf-ospfv3-segment-routing-extensions

[Acee Lindem (acee)]

Hi Les, 

I was talking in terms of general IETF terminology as opposed to specific
terminology in this draft. For example, we have various groups of links,
e.g., SRLGs and LAGs. It is more consistent to use “group” for adjacencies
as well. 
Thanks,
Acee


On 10/2/17, 4:16 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote:

>Acee -
>
>OSPF draft currently says:
>
>"The G-Flag: Group Flag.  When set, the G-Flag indicates that
> the Adj-SID refers to a group of adjacencies (and therefore MAY
> be assigned to other adjacencies as well)."
>
>IS-IS draft currently says:
>
>"S-Flag.  Set flag.  When set, the S-Flag indicates that the
> Adj-SID refers to a set of adjacencies (and therefore MAY be
> assigned to other adjacencies as well)."
>
>I do not see the terms "link-group" or "link-set" in either draft and I
>don’t see how they would apply to "adjacencies".
>So exactly what is the issue and what is the proposed change?
>
>If the concern is about the name "G-flag" vs "S-flag"  - I find this much
>ado about very little. (Sorry...)
>
>Les
>
>
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>> (acee)
>> Sent: Monday, October 02, 2017 11:46 AM
>> To: Goethals, Dirk (Nokia - BE/Antwerp) <dirk.goeth...@nokia.com>
>> Cc: OSPF WG List <ospf@ietf.org>
>> Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-segment-routing-extensions
>> 
>> Hi Dirk,
>> 
>> I agree we should use the same term but we have finished WG last call
>>and
>> AD review for the OSPFv2 Segment Routing extensions. Additionally,
>> everyone is familiar with the term link-group. A link-set would be new
>> terminology. Let’s fix the IS-IS draft.
>> 
>> Thanks,
>> Acee
>> >
>> >
>> >
>> > Original Message 
>> >Subject:draft-ietf-ospf-ospfv3-segment-routing-extensions
>> >Resent-Date:Wed, 13 Sep 2017 06:26:45 -0700
>> >Resent-From:<alias-boun...@ietf.org>
>> >Resent-To:  <ppse...@cisco.com>, <stef...@previdi.net>,
>> ><cfils...@cisco.com>, <han...@rtbrick.com>, <ro...@google.com>,
>> ><wim.henderi...@nokia.com>, <jefftant.i...@gmail.com>
>> >Date:   Wed, 13 Sep 2017 15:26:47 +0200
>> >From:   Dirk Goethals <dirk.goeth...@nokia.com>
>> >To: <draft-ietf-ospf-ospfv3-segment-routing-extensi...@ietf.org>,
>> ><draft-ietf-isis-segment-routing-extensi...@ietf.org>,
>> >"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
>> ><draft-ietf-ospf-segment-routing-extensi...@ietf.org>
>> >
>> >
>> >
>> >Hi authors,
>> >
>> >OSPF's G-flag and ISIS's S-flag are both representing adjacency sets,
>> >see snip below, can we align these definitions and simply call it
>> >S-Flag in both IGPs.
>> >
>> >Thx,
>> >Dirk
>> >
>> >OSPFv2 and OSPFv3:
>> >
>> >   The G-Flag.  Group Flag.  When set, the G-Flag indicates
>>that
>> >   the Adj-SID refers to a set of adjacencies (and therefore
>>MAY
>> >   be assigned to other adjacencies as well).
>> >
>> >
>> >
>> >ISIS:
>> >
>> >   S-Flag.  Set flag.  When set, the S-Flag indicates that the
>> >   Adj-SID refers to a set of adjacencies (and therefore MAY be
>> >   assigned to other adjacencies as well).
>> >
>> >.
>> >
>> >
>> 
>> ___
>> 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] draft-ietf-ospf-ospfv3-segment-routing-extensions

[Acee Lindem (acee)]

Hi Dirk, 

I agree we should use the same term but we have finished WG last call and
AD review for the OSPFv2 Segment Routing extensions. Additionally,
everyone is familiar with the term link-group. A link-set would be new
terminology. Let’s fix the IS-IS draft.

Thanks,
Acee  
>
>
>
> Original Message 
>Subject:   draft-ietf-ospf-ospfv3-segment-routing-extensions
>Resent-Date:   Wed, 13 Sep 2017 06:26:45 -0700
>Resent-From:   
>Resent-To: , ,
>, , ,
>, 
>Date:  Wed, 13 Sep 2017 15:26:47 +0200
>From:  Dirk Goethals 
>To:,
>,
>"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
>
>
>
>
>Hi authors,
>
>OSPF's G-flag and ISIS's S-flag are both representing adjacency sets,
>see snip below,
>can we align these definitions and simply call it S-Flag in both IGPs.
>
>Thx,
>Dirk
>
>OSPFv2 and OSPFv3:
>
>   The G-Flag.  Group Flag.  When set, the G-Flag indicates that
>   the Adj-SID refers to a set of adjacencies (and therefore MAY
>   be assigned to other adjacencies as well).
>
>
>
>ISIS:
>
>   S-Flag.  Set flag.  When set, the S-Flag indicates that the
>   Adj-SID refers to a set of adjacencies (and therefore MAY be
>   assigned to other adjacencies as well).
>
>.
>
>

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

Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

Hi Alia,

From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Friday, September 15, 2017 at 8:41 AM
To: Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, 
"draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>"
 
<draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

Hi Bruno,

On Fri, Sep 15, 2017 at 7:59 AM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:
Hi Alia, Acee, WG

From: Acee Lindem (acee) [mailto:a...@cisco.com<mailto:a...@cisco.com>]
Sent: Saturday, August 12, 2017 7:25 PM
To: Alia Atlas; 
draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>;
 OSPF List
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

Hi Alia,

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Friday, August 11, 2017 at 10:42 PM
To: 
"draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>"
 
<draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>>,
 OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

As is customary, I have done another AD review of 
draft-ietf-ospf-encapsulation-cap-06.  First, I'd like to thank the authors for 
their work and the improvement.

I have one minor issue on the IANA section.

For the current FCFS space, I think it would be better to have "Specification 
Required" so that there's a place to look to understand what sub-TLVs are 
included.
If the WG is happy with FCFS, that is fine too.

I don’t have a strong opinion here. The goal is to be stingy for the code 
points that overlap the corresponding IS-IS registry (with a single octet type) 
and more liberal here. However, we’ve never gone all the way to FCFS before and 
“Specification Required” would seem more in line with other IGP registries.

[Bruno] Alia, I see your point that we need a stable specification to interop. 
On the other hand, in the IDR WG, there is a direction toward having code 
points easier to get, in order to allow quicker implementations and avoid 
squatting. I though the situation would be similar in OSPF, but may be not. 
“Specification Required” seem to me roughly as hard to get a code point from, 
than “Standard Action” with early allocation. Plus there is a need to find a 
designated expert.

What about changing the size of the ranges? e.g.
- the first half for STD action (1 – 31999)
- second half for FCFS (32000-65499)

With 32k entries in each range, there seem to be “plenty” for everyone, even if 
the IETF gets creative with many tunnel encapsulations and many parameters for 
each.

The bar for Specification Required is much lower than Standard Action.  It just 
looks for something to be written down.  A web-page, an internet-draft, etc. 
all qualify.

I prefer to be able to have folks know how to implement using the code-point, 
but there are tons available and having a FCFS range is useful.

Acee has tracked better what the case is for OSPF - and I'm happy to have him 
make the call here.

I don’t have a strong opinion so we  could go with the larger STANDARDS ACTION 
range as suggested by Alia. In either ranges, if we even approach expiration in 
either range the capability is most likely being misused.

Thanks,
Acee


Regards,
Alia


Thanks,
Regards,
--Bruno



I'm asking for an IETF Last Call and will put this on the telechat on Aug 31.

Thanks – hope to clear some more of these “almost ready" documents prior to 
next IETF.
Acee


Regards,
Alia

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emai

Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Suresh,

From: Suresh Krishnan 
<suresh.krish...@gmail.com<mailto:suresh.krish...@gmail.com>>
Date: Thursday, August 31, 2017 at 10:06 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, 
"draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>"
 
<draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>>,
 "ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>" 
<ospf-cha...@ietf.org<mailto:ospf-cha...@ietf.org>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: 
(with DISCUSS and COMMENT)

Hi Acee,
  Thanks for the quick reply. Please find comments inline.

On Aug 31, 2017, at 5:50 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Suresh,

On 8/30/17, 10:49 PM, "Suresh Krishnan" 
<suresh.krish...@gmail.com<mailto:suresh.krish...@gmail.com>> wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-06: Discuss

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


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


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



--
DISCUSS:
--

* There seems to be an difference between this document's definition of
sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet
types and lengths). So I am surprised to see the document point to the RFC5512
based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can you
please explain how these sub-TLVs are encoded on the wire to be compatible with
this draft?

I can answer this one since I specifically told the authors to use this format. 
If you look at RFC 7770, you’ll see that all OSPF Router Information (RI) LSA 
TLVs and Sub-TLVs have 2 octet types and lengths.

2.3. OSPF Router Information LSA TLV Format

The format of the TLVs within the body of an RI LSA is the same as
the format used by the Traffic Engineering Extensions to OSPF [TE].
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets. The format of each TLV is:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3. TLV Format


Additionally, if you look at 
https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt (which obsoletes 
RFC 5512), you’ll see that the 1 octet length with insufficient.


   Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
   2-octet length field (depending on the type), and zero or more octets
   of value.  A sub-TLV is structured as shown in Figure 2:

   +---+
   |  Sub-TLV Type (1 Octet)   |
   +---+
   | Sub-TLV Length (1 or 2 Octets)|
   +---+
   | Sub-TLV Value (Variable)  |
   |   |
   +---+

   Figure 2: Tunnel Encapsulation Sub-TLV Format

   o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
  property about the tunnel TLV that contains this sub-TLV.





Rosen, et al.   Expires January 18, 2018[Page 7]
?
Internet-Draft   Tunnel Encapsulation AttributeJuly 2017


   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
  sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
  the Sub-TLV Type field contains a value in the range from 1-127.
  The Sub-TLV Length field contains two octets if the Sub-TLV Type
  field contains a value in the range from 128-254.

   o  Sub-TLV Value (variable): encodings of the value field depend on
  the sub-TLV type as enumerated above.  The following sub-sections
  define the encoding in detail.

I did read the draft-ietf-idr-tunnel-encaps-07 draft (following it from the 
references) and I do understand why the document made the switch to 2 octets 
for the length. The part that threw me off is 

Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)

[Acee Lindem (acee)]

Hi Suresh,

On 8/30/17, 10:49 PM, "Suresh Krishnan" 
> wrote:

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-06: Discuss

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


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


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



--
DISCUSS:
--

* There seems to be an difference between this document's definition of
sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet
types and lengths). So I am surprised to see the document point to the RFC5512
based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can you
please explain how these sub-TLVs are encoded on the wire to be compatible with
this draft?

I can answer this one since I specifically told the authors to use this format. 
If you look at RFC 7770, you’ll see that all OSPF Router Information (RI) LSA 
TLVs and Sub-TLVs have 2 octet types and lengths.

2.3. OSPF Router Information LSA TLV Format

The format of the TLVs within the body of an RI LSA is the same as
the format used by the Traffic Engineering Extensions to OSPF [TE].
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets. The format of each TLV is:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3. TLV Format


Additionally, if you look at 
https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt (which obsoletes 
RFC 5512), you’ll see that the 1 octet length with insufficient.


   Each sub-TLV consists of three fields: a 1-octet type, a 1-octet or
   2-octet length field (depending on the type), and zero or more octets
   of value.  A sub-TLV is structured as shown in Figure 2:

   +---+
   |  Sub-TLV Type (1 Octet)   |
   +---+
   | Sub-TLV Length (1 or 2 Octets)|
   +---+
   | Sub-TLV Value (Variable)  |
   |   |
   +---+

   Figure 2: Tunnel Encapsulation Sub-TLV Format

   o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
  property about the tunnel TLV that contains this sub-TLV.





Rosen, et al.   Expires January 18, 2018[Page 7]

Internet-Draft   Tunnel Encapsulation AttributeJuly 2017


   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
  sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
  the Sub-TLV Type field contains a value in the range from 1-127.
  The Sub-TLV Length field contains two octets if the Sub-TLV Type
  field contains a value in the range from 128-254.

   o  Sub-TLV Value (variable): encodings of the value field depend on
  the sub-TLV type as enumerated above.  The following sub-sections
  define the encoding in detail.

Thanks,
Acee


--
COMMENT:
--

* IANA considerations

Looks like the value 65535 is included both as experimental and reserved. 
Suggest changing

OLD:
65500-65535Experimental  This document

NEW:
65500-65534Experimental  This document



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

Re: [OSPF] 答复: Genart last call review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

From: Pete Resnick <presn...@qti.qualcomm.com<mailto:presn...@qti.qualcomm.com>>
Date: Thursday, August 24, 2017 at 3:59 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: Xiaohu Xu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>, 
"gen-...@ietf.org<mailto:gen-...@ietf.org>" 
<gen-...@ietf.org<mailto:gen-...@ietf.org>>, OSPF WG List 
<ospf@ietf.org<mailto:ospf@ietf.org>>, 
"draft-ietf-ospf-encapsulation-cap@ietf.org<mailto:draft-ietf-ospf-encapsulation-cap@ietf.org>"
 
<draft-ietf-ospf-encapsulation-cap@ietf.org<mailto:draft-ietf-ospf-encapsulation-cap@ietf.org>>,
 "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>
Subject: Re: 答复: Genart last call review of draft-ietf-ospf-encapsulation-cap-06
Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
Resent-To: Xiaohu Xu <xuxia...@huawei.com<mailto:xuxia...@huawei.com>>, Bruno 
Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>, Robert 
Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>, Luis Contreras 
<luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com>>,
 Luay Jalil <luay.ja...@verizon.com<mailto:luay.ja...@verizon.com>>, Acee 
Lindem <a...@cisco.com<mailto:a...@cisco.com>>, 
<a...@cisco.com<mailto:a...@cisco.com>>, 
<aret...@cisco.com<mailto:aret...@cisco.com>>, Deborah Brungard 
<db3...@att.com<mailto:db3...@att.com>>, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>
Resent-Date: Thursday, August 24, 2017 at 3:59 PM


On 24 Aug 2017, at 11:24, Acee Lindem (acee) wrote:

For 1, 2, 6, and 7, that's easy; the drafts defining the values can do
the registrations. For 5, the reference would be to an existing RFC
that doesn't do the registration. I'm not sure what to do about that;
perhaps register it here and make the reference both 5640 and this

document.

Actually, this document does assign these code points in the registry so
“This document” is appropriate. The value portion of these TLVs just
happened to be described via a reference rather than text.

There is nothing preventing the IANA registry from having useful information. 
:-) Yes, this document registers it, but really what the implementer is going 
to need is this document and 5640, so I see no particular harm in putting both 
references in the registry, and it's probably useful.

Ok – I think I found an example of where something like this was done (although 
only for IS-IS TLVs ;^).

https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv

Authors – can you cross-reference the document defining the value in the table? 
We’re not going to move any IANA allocations.

Thanks,
Acee




pr
--
Pete Resnick 
http://www.qualcomm.com/~presnick/<http://www.qualcomm.com/%7Epresnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] tsv-dir review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

Xiaohu and other Co-authors,

Please respond to Joe’s comments. You don’t necessarily have to address
them all as he as suggested but please respond.

Joe, 

For your comment on the introduction, can you provide text?

Thanks, 
Acee 

On 8/24/17, 12:39 AM, "OSPF on behalf of Joe Touch"  wrote:

>Hi, all,
>
>I am the assigned TSV-ART reviewer for draft-ietf-ospf-encapsulation-cap
>
>For background on TSV-ART, please see the FAQ at
>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive.
>
>Joe
>
>--
>
>I've reviewed this document as part of the transport area directorate's
>ongoing effort to review key IETF documents. These comments were written
>primarily for the transport area directors, but are copied to the
>document's authors for their information and to allow them to address
>any issues raised. When done at the time of IETF Last Call, the authors
>should consider this review together with any other last-call comments
>they receive. Please always CC tsv-...@ietf.org if you reply to or
>forward this review.
>
>"This draft has serious issues, described in the review, and needs to be
>rethought."
>
>Although I found no transport issues, there are many fundamental
>problems that need to be corrected before this document should proceed.
>These are summarized below.
>
>Sec1: The introduction jumps too quickly into a list of situations in
>which tunnels are used, two of which are emerging (currently only
>drafts). There are many better and more established examples (going back
>to the M-Bone, the 6-Bone, etc., to VPNs, network virtualization, etc.).
>Terms are used before defined (what is an ingress? are you referring to
>the router or host at which a tunnel is attached, or the input to the
>tunnel itself?). The last two sentences should begin the intro, which
>should expand and explain what is meant (e.g., by "egress tunneling" and
>the reason for wanting to encode tunnels as LSAs.
>
>Sec2: The terminology section is incomplete. The terms tunnel, ingress,
>egress, egress tunneling, etc. are not defined in RFC7770. Only the LSA
>terminology is relevant from that RFC. Other terms need to be defined in
>this doc or used from others.
>
>Sec3: This section is written as if the "Encapsulation Capability TLV"
>is already defined (in RFC7770), rather than being defined herein. The
>section title doesn't match this name, which is confusing. The term TLV
>is itself confusing, as this is really a single TLV of the RI Opaque LSA
>set of types, which itself is represented as a (sub)TLV list. I
>appreciate that this terminology was made confusing in previous,
>established documents, but a bit of explanation would go a long way - as
>would showing the top-level OSPF RI Opaque LSA and where the new TBD1
>value would appear - before diving into the structure inside this new
>"TLV".
>
>Sec 4: the discussion should clarify what happens if the length field is
>longer than the fields indicated by the sub-TLVs (is this an error or
>padding to be ignored; does the latter present a covert channel).
>additionally, this section refers to RFC5512 - which is being obsoleted
>by ietf-idr-tunnel-encaps - and this pending ID is used as the primary
>reference in Secs 5.1 and 5.2. References to RFC5512 should be replaced
>with that ID (which I'll assume will be published concurrently).
>
>Sec 5: this section refers to the concept of an "invalid" sub-TLV; given
>the previous sentence explains that unknown sub-TLVs are silently
>ignored, then what exactly is an invalid sub-TLV? It further isn't clear
>why 2 octets of type and 2 octets of length are needed (granted it
>provides alignment, but is that really important for this sort of
>application-layer protocol?)
>
>Sec 5.1 and 5.2: it is unclear why the two fundamental sub-TLVs of this
>TLV are defined elsewhere; in specific, the example of the sub-TLV
>should appear here (actually for each of the sub-TLVs).
>
>Sec 5.3 infers IP address version from length, when the version could
>(should) easily encoded either as different types (you have 65K of
>them!) or using an additional few bits (e.g., carved out of the excesses
>noted in Sec 5).
>
>Sec 5.4 - I had to thread through several different sections of the IDR
>ID to figure out what Color meant and how it is used. Granted that is a
>different problem in a different doc, IMO this doc should include enough
>of a summary that this sort of 'traceback' should not be needed to
>understand what is being described. Further, the other doc doesn't even
>explain Color sufficiently, IMO.
>
>Secs 5.6 and 5.7 - There are many rules for how the outer encapsulation
>header is composed, and many fields it may affect beyond QoS and UDP
>destination port. This section is incomplete in describing values for
>the outer header(s) or relationships to the inner header(s).
>
>Sec 6 - I would encourage moving this 

Re: [OSPF] 答复: Genart last call review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

Hi Pete, 

One more inline since Xiaohu must have missed your other comment.

On 8/23/17, 9:21 PM, "Xuxiaohu" <xuxia...@huawei.com> wrote:

>
>
>> -邮件原件-----
>> 发件人: Acee Lindem (acee) [mailto:a...@cisco.com]
>> 发送时间: 2017年8月22日 2:45
>> 收件人: Pete Resnick
>> 抄送: gen-...@ietf.org; ospf@ietf.org;
>> draft-ietf-ospf-encapsulation-cap@ietf.org; i...@ietf.org
>> 主题: Re: Genart last call review of draft-ietf-ospf-encapsulation-cap-06
>> 
>> 
>> 
>> On 8/21/17, 12:12 PM, "Pete Resnick" <presn...@qti.qualcomm.com> wrote:
>> 
>> >On 21 Aug 2017, at 10:58, Acee Lindem (acee) wrote:
>> >
>> >> Hi Pete,
>> >>
>> >> On 8/21/17, 11:40 AM, "Pete Resnick" <presn...@qti.qualcomm.com>
>> >> wrote:
>> >>
>> >>> Reviewer: Pete Resnick
>> >>> Review result: Almost Ready
>> >>>
>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> >>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> >>> the IESG for the IETF Chair.  Please treat these comments just like
>> >>> any other last call comments.
>> >>>
>> >>> For more information, please see the FAQ at
>> >>>
>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>> >>>
>> >>> Document: draft-ietf-ospf-encapsulation-cap-06
>> >>> Reviewer: Pete Resnick
>> >>> Review Date: 2017-08-21
>> >>> IETF LC End Date: 2017-08-28
>> >>> IESG Telechat date: 2017-08-31
>> >>>
>> >>> Summary: Almost Ready
>> >>>
>> >>> The content of this document is fine. However, I think the IANA
>> >>> registry stuff is not ready.
>> >>>
>> >>> Major issues:
>> >>>
>> >>> I think the registrations other than for Endpoint and Color are
>> >>> incorrect and should not be in this document. Certainly the
>> >>> "Reference" field for 1, 2, 5, 6, and 7 should not be "This
>> >>> document", given that the syntax and semantics for these values are
>> >>> defined in other documents.
>> >>
>> >> The authors can fix these.
>> >
>> >For 1, 2, 6, and 7, that's easy; the drafts defining the values can do
>> >the registrations. For 5, the reference would be to an existing RFC
>> >that doesn't do the registration. I'm not sure what to do about that;
>> >perhaps register it here and make the reference both 5640 and this
>>document.
>> >However, when someone goes to update 5640 some day, they're going to
>> >have to put into the IANA considerations to update both the OSPF and
>> >BGP registries. I'm not sure how to keep track of that. Perhaps saying
>> >that this document "Updates: 5640"? That doesn't seem great either.

Actually, this document does assign these code points in the registry so
“This document” is appropriate. The value portion of these TLVs just
happened to be described via a reference rather than text.

Thanks,
Acee 




>> >
>> >>> I also think that having things in
>> >>> this registry which are also used by the BGP registry is asking for
>> >>> trouble:
>> >>> You wouldn't want the references for the two registries to get out
>> >>> of sync.
>> >>> This seems like a mess to me. Would it be possible for IANA to
>> >>> simply rename the "BGP Tunnel Encapsulation Attribute Sub-TLVs"
>> >>> registry to "BGP and OSPF Tunnel Encapsulation Attribute Sub-TLVs",
>> >>> and share the registry between the two protocols? Then have this
>> >>> (and other) document(s) add values to that registry. That way, the
>> >>> documents that actually define the codepoints can be put into the
>> >>> registry.
>> >>
>> >> We’ve already had a protracted discussion on the IANA registries. It
>> >> is not possible as BGP advertises some of the attributes in BGP
>> >> communities rather than tunnel attributes (e.g., color).
>> >
>> >Yuck. I'll try not to prolong the discussion much further, but did you
>> >consider the possibility of having some of the attributes appear twice,
>> >with one saying "For BGP communities only" and the other saying, "For
>> >OSPF tunnels only"? What a lovely mess. :-(
>> 
>> The cleanest solution is for BGP and OSPF to have their own registries.
>> Trying to retrofit the existing BGP registry to satisfy OSPF
>>advertisement
>> requirements is not feasible.
>
>Fully agree.
>
>Best regards,
>Xiaohu
>
>> Thanks,
>> Acee
>> 
>> 
>> 
>> >
>> >> Thanks,
>> >> Acee
>> >
>> >Cheers,
>> >
>> >pr
>> >
>> >>> Minor issues:
>> >>>
>> >>> None.
>> >>>
>> >>> Nits/editorial comments:
>> >>>
>> >>> In section 7.1, please add:
>> >>>
>> >>>   [RFC Editor: Please replace "TBD1" in section 3 with the registry
>> >>> value
>> >>>   allocated by IANA, and remove this note].
>> >>>
>> >>> That will save them from hunting.
>> >>>
>> >
>> >
>> >--
>> >Pete Resnick <http://www.qualcomm.com/~presnick/>
>> >Qualcomm Technologies, Inc. - +1 (858)651-4478
>

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

On 8/21/17, 12:12 PM, "Pete Resnick" <presn...@qti.qualcomm.com> wrote:

>On 21 Aug 2017, at 10:58, Acee Lindem (acee) wrote:
>
>> Hi Pete,
>>
>> On 8/21/17, 11:40 AM, "Pete Resnick" <presn...@qti.qualcomm.com>
>> wrote:
>>
>>> Reviewer: Pete Resnick
>>> Review result: Almost Ready
>>>
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>>
>>> For more information, please see the FAQ at
>>>
>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-ospf-encapsulation-cap-06
>>> Reviewer: Pete Resnick
>>> Review Date: 2017-08-21
>>> IETF LC End Date: 2017-08-28
>>> IESG Telechat date: 2017-08-31
>>>
>>> Summary: Almost Ready
>>>
>>> The content of this document is fine. However, I think the IANA
>>> registry
>>> stuff
>>> is not ready.
>>>
>>> Major issues:
>>>
>>> I think the registrations other than for Endpoint and Color are
>>> incorrect
>>> and
>>> should not be in this document. Certainly the "Reference" field for
>>> 1, 2,
>>> 5, 6,
>>> and 7 should not be "This document", given that the syntax and
>>> semantics
>>> for
>>> these values are defined in other documents.
>>
>> The authors can fix these.
>
>For 1, 2, 6, and 7, that's easy; the drafts defining the values can do
>the registrations. For 5, the reference would be to an existing RFC that
>doesn't do the registration. I'm not sure what to do about that; perhaps
>register it here and make the reference both 5640 and this document.
>However, when someone goes to update 5640 some day, they're going to
>have to put into the IANA considerations to update both the OSPF and BGP
>registries. I'm not sure how to keep track of that. Perhaps saying that
>this document "Updates: 5640"? That doesn't seem great either.
>
>>> I also think that having things in
>>> this registry which are also used by the BGP registry is asking for
>>> trouble:
>>> You wouldn't want the references for the two registries to get out of
>>> sync.
>>> This seems like a mess to me. Would it be possible for IANA to simply
>>> rename
>>> the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to "BGP
>>> and
>>> OSPF
>>> Tunnel Encapsulation Attribute Sub-TLVs", and share the registry
>>> between
>>> the
>>> two protocols? Then have this (and other) document(s) add values to
>>> that
>>> registry. That way, the documents that actually define the codepoints
>>> can
>>> be
>>> put into the registry.
>>
>> We’ve already had a protracted discussion on the IANA registries. It
>> is
>> not possible as BGP advertises some of the attributes in BGP
>> communities
>> rather than tunnel attributes (e.g., color).
>
>Yuck. I'll try not to prolong the discussion much further, but did you
>consider the possibility of having some of the attributes appear twice,
>with one saying "For BGP communities only" and the other saying, "For
>OSPF tunnels only"? What a lovely mess. :-(

The cleanest solution is for BGP and OSPF to have their own registries.
Trying to retrofit the existing BGP registry to satisfy OSPF advertisement
requirements is not feasible.

Thanks,
Acee 



>
>> Thanks,
>> Acee
>
>Cheers,
>
>pr
>
>>> Minor issues:
>>>
>>> None.
>>>
>>> Nits/editorial comments:
>>>
>>> In section 7.1, please add:
>>>
>>>   [RFC Editor: Please replace "TBD1" in section 3 with the registry
>>> value
>>>   allocated by IANA, and remove this note].
>>>
>>> That will save them from hunting.
>>>
>
>
>-- 
>Pete Resnick <http://www.qualcomm.com/~presnick/>
>Qualcomm Technologies, Inc. - +1 (858)651-4478

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

Re: [OSPF] Genart last call review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

Hi Pete,

On 8/21/17, 11:40 AM, "Pete Resnick"  wrote:

>Reviewer: Pete Resnick
>Review result: Almost Ready
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair.  Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
>.
>
>Document: draft-ietf-ospf-encapsulation-cap-06
>Reviewer: Pete Resnick
>Review Date: 2017-08-21
>IETF LC End Date: 2017-08-28
>IESG Telechat date: 2017-08-31
>
>Summary: Almost Ready
>
>The content of this document is fine. However, I think the IANA registry
>stuff
>is not ready.
>
>Major issues:
>
>I think the registrations other than for Endpoint and Color are incorrect
>and
>should not be in this document. Certainly the "Reference" field for 1, 2,
>5, 6,
>and 7 should not be "This document", given that the syntax and semantics
>for
>these values are defined in other documents.

The authors can fix these.

> I also think that having things in
>this registry which are also used by the BGP registry is asking for
>trouble:
>You wouldn't want the references for the two registries to get out of
>sync.
>This seems like a mess to me. Would it be possible for IANA to simply
>rename
>the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to "BGP and
>OSPF
>Tunnel Encapsulation Attribute Sub-TLVs", and share the registry between
>the
>two protocols? Then have this (and other) document(s) add values to that
>registry. That way, the documents that actually define the codepoints can
>be
>put into the registry.

We’ve already had a protracted discussion on the IANA registries. It is
not possible as BGP advertises some of the attributes in BGP communities
rather than tunnel attributes (e.g., color).

Thanks,
Acee 

>
>Minor issues:
>
>None.
>
>Nits/editorial comments:
>
>In section 7.1, please add:
>
>   [RFC Editor: Please replace "TBD1" in section 3 with the registry value
>   allocated by IANA, and remove this note].
>
>That will save them from hunting.
>

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

Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

[Acee Lindem (acee)]

Thanks Alia – I’ve read through the comments and I think the authors should be 
able to address these in this draft or the LDP interoperation draft.
Acee

From: OSPF > on behalf of 
Alia Atlas >
Date: Friday, August 11, 2017 at 10:09 PM
To: OSPF WG List >, 
"draft-ietf-ospf-segment-routing-extensi...@ietf.org"
 
>
Subject: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18

As is customary, I have done another AD review of 
draft-ietf-ospf-segment-routing-extensions-18. I do appreciate the improvements 
in the draft.

I do still see a few minor issues.  I would like to see a revised draft before 
IETF Last Call. I expect to progress this at an IESG telechat with the primary 
spring documents, when Alvaro feels they are ready.


1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
   Information LSAs that have different flooding scopes, the SR-
   Algorithm TLV in the Router Information LSA with the narrowest
   flooding scope SHOULD be used.  "
   Given that the area-scope is REQUIRED - shouldn't this also prefer
   the area-scope?  Is there future-proofing being done?

2) In Sec 3.4: "For the purpose of the SRMS Preference TLV advertisement, 
AS-scoped flooding is REQUIRED.  This
   is because SRMS servers can be located in a different area then
   consumers of the SRMS advertisements.  If the SRMS advertisements
   from the SRMS server are only used inside the SRMS server's area,
   area-scoped flooding may be used."

REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be used 
area-scoped flooding MAY be used."

3) In Sec 4. "The Segment Routing Mapping Server, which is described in
   [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
   need a single advertisement to advertise SIDs for multiple prefixes
   from a contiguous address range."

I've read through the vastly improved section (thank you) in 
draft-ietf-spring-segment-routing-ldp-interop-08 and I don't see any 
explanation for why a contiguous address range is needed.

I can speculate that a primary purpose is to advertise SIDs for the loopback 
addresses of routers that don't support SR - and those loopback addresses are 
likely to be allocated from a contiguous range (though why some wouldn't be 
supporting SR and cause gaps isn't clear).

4) Sec 5: In the end of Sec 4.2 in 
draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR mappings 
advertisements cannot set Penultimate Hop Popping.
   In the previous example, P6 requires the presence of the segment 103
   such as to map it to the LDP label 1037.  For that reason, the P flag
   available in the Prefix-SID is not available in the Remote-Binding
   SID."
However, in this draft Sec 5 gives the following rules:

"As the Mapping Server does not specify the originator of a prefix 
advertisement, it is not possible to determine PHP behavior solely based on the 
Mapping Server advertisement. However, PHP behavior SHOULD be done in following 
cases: The Prefix is intra-area type and the downstream neighbor is the 
originator of the prefix. The Prefix is inter-area type and downstream neighbor 
is an ABR, which is advertising prefix reachability and is also generating the 
Extended Prefix TLV with the A-flag set for this prefix as described in section 
2.1 of [RFC7684]. The Prefix is external type and downstream neighbor is an 
ASBR, which is advertising prefix reachability and is also generating the 
Extended Prefix TLV with the A-flag set for this prefix as described in section 
2.1 of [RFC7684].

These seem to be contradictory.

5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
   Prefix-SIDs for the same prefix, in which case the same Prefix-SID
   MUST be advertised by all of them."

What is forcing this constraint?  Does it work if the Prefix-SID is an index 
into an
SRGB or SRLB that is not the same value globally? I don't see it specified in 
Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-08?

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

Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

[Acee Lindem (acee)]

Hi Alia,

From: OSPF > on behalf of 
Alia Atlas >
Date: Friday, August 11, 2017 at 10:42 PM
To: 
"draft-ietf-ospf-encapsulation-...@ietf.org"
 
>,
 OSPF WG List >
Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06

As is customary, I have done another AD review of 
draft-ietf-ospf-encapsulation-cap-06.  First, I'd like to thank the authors for 
their work and the improvement.

I have one minor issue on the IANA section.

For the current FCFS space, I think it would be better to have "Specification 
Required" so that there's a place to look to understand what sub-TLVs are 
included.
If the WG is happy with FCFS, that is fine too.

I don’t have a strong opinion here. The goal is to be stingy for the code 
points that overlap the corresponding IS-IS registry (with a single octet type) 
and more liberal here. However, we’ve never gone all the way to FCFS before and 
“Specification Required” would seem more in line with other IGP registries.

I'm asking for an IETF Last Call and will put this on the telechat on Aug 31.

Thanks – hope to clear some more of these “almost ready" documents prior to 
next IETF.
Acee


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

Re: [OSPF] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 8099

[Acee Lindem (acee)]

Thanks - the IPR was disclosed back before the draft was made a WG
document. As expected, the claims are purely defensive. However, in the
future, it would be better to have the formal statement earlier in the
process. As a WG chair, I should have pushed for the formal statement even
though I fully expected it to be in line with the other Huawei IPR
statements. We’ll do better in the future ;^)

Thanks,
Acee 

On 8/4/17, 6:00 PM, "OSPF on behalf of IETF Secretariat"
 wrote:

>Dear Huaimo Chen, Renwei Li, Alvaro Retana, Yi Yang, Vic Liu:
>
>
>An IPR disclosure that pertains to your RFC entitled "OSPF
>Topology-Transparent Zone" (RFC8099) was submitted to the IETF
>Secretariat on  and has been posted on the "IETF Page of Intellectual
>Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3046/). The
>title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement
>about IPR related to RFC 8099"
>
>
>Thank you
>
>IETF Secretariat
>
>___
>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] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt

[Acee Lindem (acee)]

Hi Ketan, 

With all the WG documents we have, I wouldn’t put this as a high priority.
Rather, I’d like to focus on getting OSPFv3 Extended LSAs published and
encouraging wider implementation.

Thanks,
Acee 

On 7/27/17, 10:20 PM, "Ketan Talaulikar (ketant)" <ket...@cisco.com> wrote:

>Hi Acee/WG,
>
>I would like to bring up that this draft does not cover the application
>to Traffic Engineering applications (RSVP-TE/SR-TE). It only talks about
>and covers the traditional OSPF SPF computation. For truly achieving the
>objective, I believe this draft should also cover TE and all other types
>of computations which would result in transit traffic going through the
>node.
>
>I realized that TE applicability was never specified explicitly even for
>RFC6987/RFC3137 and very likely that implementations might have adopted
>different mechanisms in applying the max-metric to TE as well that can
>cause interop issues. Perhaps that warrants a bis?
>
>Thanks,
>Ketan
>
>-Original Message-----
>From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
>Sent: 15 June 2017 01:19
>To: OSPF WG List <ospf@ietf.org>
>Subject: [OSPF] FW: I-D Action: draft-ietf-ospf-ospfv2-hbit-03.txt
>
>The question of OSPFv2 complete blocking of transit routing support
>(similar to OSPFv3) seems to come up every year or so. I’d like to WG last
>call this document. Does anyone see any issues?
>Thanks,
>Acee 
>
>On 6/14/17, 12:44 PM, "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   : H-bit Support for OSPFv2
>>Authors : Keyur Patel
>>  Padma Pillay-Esnault
>>  Manish Bhardwaj
>>  Serpil Bayraktar
>>  Filename: draft-ietf-ospf-ospfv2-hbit-03.txt
>>  Pages   : 8
>>  Date: 2017-06-14
>>
>>Abstract:
>>   OSPFv3 defines an option field for router-LSAs known as a R-bit in
>>   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
>>   OSPF topology distribution without acting as a forwarder to forward
>>   the transit traffic.  In such cases, an OSPF router would only accept
>>   traffic intended for local delivery.  This draft defines R-bit
>>   functionality for OSPFv2 defined in RFC2328.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/
>>
>>There are also htmlized versions available at:
>>https://tools.ietf.org/html/draft-ietf-ospf-ospfv2-hbit-03
>>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv2-hbit-03
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv2-hbit-03
>>
>>
>>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

Re: [OSPF] Implementation Survey for OSPFv3 Extended LSAs

[Acee Lindem (acee)]

If anyone else has an implementation, please respond to the survey as well. I 
know there have been implementation specific queries.

Thanks,
Acee

From: OSPF > on behalf of 
Acee Lindem >
Date: Friday, July 28, 2017 at 3:20 PM
To: "Goethals, Dirk (Nokia - BE/Antwerp)" 
>, Veerendranatha Reddy 
Vallem >
Cc: OSPF WG List >
Subject: [OSPF] Implementation Survey for OSPFv3 Extended LSAs

Hi Dirk, Veeru,

Please respond to the implementation survey questions below.

  1. Does your implementation support for all 9 OSPFv3 Extended LSAs?

  2. Does your implementation support for N-Bit Prefix Option?

  3. Does your implementation support OSPFv3 Extended LSAs across the entire 
routing domain?

  4. Does your implementation support per-area deployment of OSPF Extended LSAs 
(AS-External LSAs are legacy)?

  5. Does your implementation support full deployment of OSPFv3 Extended LSAs?

  6. Does your implementation support sparse mode deployment of OSPFv3 Extended 
LSAs?

  7. Does your implementation support any applications that make use of OSPFv3 
Extended LSAs (e.g., Segment Routing)?

  8. Have you done any interoperability testing with other implementations?


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

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

[Acee Lindem (acee)]

On 7/27/17, 5:49 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Hi Shraddha, Co-authors,
>
>I just read the draft and I there shouldn’t be any more contention.
>However, I have a couple questions on the use cases.
>
>  1. In the pseudowire use case (7.1), I don’t understand where OSPF
>link-overload is being advertised. I guess the assumption is that the
>pseudowires are running OSPF? Also, the use case references a private VLAN
>with 3 CEs. However, I see pseudowires as P2P.

I guess VPLS is also characterized as a pseudowire service.

Thanks,
Acee 

>
>  2. In the OSPF L3VPN use case, mention that the CEs are dual-homed. This
>include in my editorial comments.
>
>  3. In the Hub-and-Spoke use case (7.4), why wouldn’t one just use RFC
>6987 rather than advertising link-overload for all the links?
>
>I’ll send my editorial comments offline.
>
>Thanks,
>Acee 
>
>   
>
>On 7/27/17, 6:03 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>Acee/OSPF WG,
>>
>>I just realized my post on updated draft for -08 version posted on 17-07
>>was stuck at confirmation stage.
>>
>>I think it's useful to have normative language to ensure
>>interoperability. I have updated the "elements of procedure"
>>Section accordingly. Please review the -08 version.
>>
>>Thanks
>>Shraddha
>>
>>-Original Message-
>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>Sent: Tuesday, July 25, 2017 3:59 AM
>>To: Shraddha Hegde <shrad...@juniper.net>; Peter Psenak (ppsenak)
>><ppse...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>
>>Cc: ospf@ietf.org
>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>>Hi Shraddha, 
>>
>>Great - I think we are all in sync.
>>
>>What are your thoughts on using “MUST” for the setting the link metrics
>>in sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and
>>they don't use normative language since setting the link-metrics to
>>0x is the very definition of OSPF stub router behavior.
>>
>>Also, one more reference to RFC 4203.
>>
>>*** 438,445 
>> field in the Extended Link TLV carries the Local interface-id
>>instead
>> of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
>> originated when there are multiple parallel unnumbered interfaces
>>!between two nodes.  Procedures to obtain interface-id of the remote
>>!side are defined in [RFC4203].
>>  
>>  
>>  
>>--- 438,445 
>> field in the Extended Link TLV carries the Local interface-id
>>instead
>> of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
>> originated when there are multiple parallel unnumbered interfaces
>>!between two nodes.  One of the mechanisms to obtain remote
>>!interface-id is described in [RFC4203].
>>  
>>
>>
>>Thanks,
>>Acee 
>>
>>
>>On 7/10/17, 12:52 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>>
>>>All,
>>>
>>>Link-local flooding was added as an optimization for use-cases that do
>>>not need area level flooding on request from Acee.
>>>I agree flooding area level in all cases is a reasonable way forward as
>>>the overhead isn't much.
>>>
>>>If anyone has objections to removing Link-local scope advertisement, do
>>>let me know.
>>>
>>>Rgds
>>>Shraddha
>>>
>>>
>>>-Original Message-
>>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>>Sent: Thursday, July 6, 2017 2:55 PM
>>>To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar
>>>(ketant) <ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>
>>>Cc: ospf@ietf.org
>>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>>
>>>Hi Peter, Shradha,
>>>
>>>On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
>>><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>>>
>>>>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>>>>> Hi Shraddha,
>>>>>
>>>>> Thanks for taking care of some of the comments shared previously.
>>>>>Please find below some more that were probably missed or not taken
>>>>>care of.
>>>>>
>>>>> 1) I see that the use of link-local scope RI LSA has 

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

[Acee Lindem (acee)]

Hi Shraddha, Co-authors,

I just read the draft and I there shouldn’t be any more contention.
However, I have a couple questions on the use cases.

  1. In the pseudowire use case (7.1), I don’t understand where OSPF
link-overload is being advertised. I guess the assumption is that the
pseudowires are running OSPF? Also, the use case references a private VLAN
with 3 CEs. However, I see pseudowires as P2P.

  2. In the OSPF L3VPN use case, mention that the CEs are dual-homed. This
include in my editorial comments.

  3. In the Hub-and-Spoke use case (7.4), why wouldn’t one just use RFC
6987 rather than advertising link-overload for all the links?

I’ll send my editorial comments offline.

Thanks,
Acee 

   

On 7/27/17, 6:03 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>Acee/OSPF WG,
>
>I just realized my post on updated draft for -08 version posted on 17-07
>was stuck at confirmation stage.
>
>I think it's useful to have normative language to ensure
>interoperability. I have updated the "elements of procedure"
>Section accordingly. Please review the -08 version.
>
>Thanks
>Shraddha
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Tuesday, July 25, 2017 3:59 AM
>To: Shraddha Hegde <shrad...@juniper.net>; Peter Psenak (ppsenak)
><ppse...@cisco.com>; Ketan Talaulikar (ketant) <ket...@cisco.com>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>
>Hi Shraddha, 
>
>Great - I think we are all in sync.
>
>What are your thoughts on using “MUST” for the setting the link metrics
>in sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and
>they don't use normative language since setting the link-metrics to
>0x is the very definition of OSPF stub router behavior.
>
>Also, one more reference to RFC 4203.
>
>*** 438,445 
> field in the Extended Link TLV carries the Local interface-id instead
> of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
> originated when there are multiple parallel unnumbered interfaces
>!between two nodes.  Procedures to obtain interface-id of the remote
>!side are defined in [RFC4203].
>  
>  
>  
>--- 438,445 
> field in the Extended Link TLV carries the Local interface-id instead
> of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
> originated when there are multiple parallel unnumbered interfaces
>!between two nodes.  One of the mechanisms to obtain remote
>!interface-id is described in [RFC4203].
>  
>
>
>Thanks,
>Acee 
>
>
>On 7/10/17, 12:52 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:
>
>>All,
>>
>>Link-local flooding was added as an optimization for use-cases that do
>>not need area level flooding on request from Acee.
>>I agree flooding area level in all cases is a reasonable way forward as
>>the overhead isn't much.
>>
>>If anyone has objections to removing Link-local scope advertisement, do
>>let me know.
>>
>>Rgds
>>Shraddha
>>
>>
>>-Original Message-
>>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>>Sent: Thursday, July 6, 2017 2:55 PM
>>To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar
>>(ketant) <ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>
>>Cc: ospf@ietf.org
>>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>>Hi Peter, Shradha,
>>
>>On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
>><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>>
>>>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>>>> Hi Shraddha,
>>>>
>>>> Thanks for taking care of some of the comments shared previously.
>>>>Please find below some more that were probably missed or not taken
>>>>care of.
>>>>
>>>> 1) I see that the use of link-local scope RI LSA has still been
>>>>retained in this version and not sure why. RI LSA is for node
>>>>attributes and it's use for signalling of link is not right IMO. Why
>>>>not use the link-local scope Extended Link LSA instead?
>>>
>>>an alternative would be to always flood area scope Extended Link LSA.
>>>It should not harm anything and could be used by other routers in area
>>>as a "heads-up" that remote link is becoming overloaded.
>>
>>I think this would be a good way forward as the OSPF Extended Attribute
>>LSA will most likely be advertised for SR in OSPF Service Provider
>>domains anyway.

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

[Acee Lindem (acee)]

Hi Shraddha, 

Great - I think we are all in sync.

What are your thoughts on using “MUST” for the setting the link metrics in
sections 5.1, 5.2, 5.3 and 5.5? I checked RFC 6987 (and RFC 3137) and they
don't use normative language since setting the link-metrics to 0x is
the very definition of OSPF stub router behavior.

Also, one more reference to RFC 4203.

*** 438,445 
 field in the Extended Link TLV carries the Local interface-id instead
 of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
 originated when there are multiple parallel unnumbered interfaces
!between two nodes.  Procedures to obtain interface-id of the remote
!side are defined in [RFC4203].
  
  
  
--- 438,445 
 field in the Extended Link TLV carries the Local interface-id instead
 of the IP address.  The Local/Remote Interface ID sub-TLV MUST be
 originated when there are multiple parallel unnumbered interfaces
!between two nodes.  One of the mechanisms to obtain remote
!interface-id is described in [RFC4203].
  


Thanks,
Acee 


On 7/10/17, 12:52 AM, "Shraddha Hegde" <shrad...@juniper.net> wrote:

>All,
>
>Link-local flooding was added as an optimization for use-cases that do
>not need area level flooding on request from Acee.
>I agree flooding area level in all cases is a reasonable way forward as
>the overhead isn't much.
>
>If anyone has objections to removing Link-local scope advertisement, do
>let me know.
>
>Rgds
>Shraddha
>
>
>-Original Message-
>From: Acee Lindem (acee) [mailto:a...@cisco.com]
>Sent: Thursday, July 6, 2017 2:55 PM
>To: Peter Psenak (ppsenak) <ppse...@cisco.com>; Ketan Talaulikar (ketant)
><ket...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>
>Hi Peter, Shradha,
>
>On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>
>>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>>> Hi Shraddha,
>>>
>>> Thanks for taking care of some of the comments shared previously.
>>>Please find below some more that were probably missed or not taken
>>>care of.
>>>
>>> 1) I see that the use of link-local scope RI LSA has still been
>>>retained in this version and not sure why. RI LSA is for node
>>>attributes and it's use for signalling of link is not right IMO. Why
>>>not use the link-local scope Extended Link LSA instead?
>>
>>an alternative would be to always flood area scope Extended Link LSA.
>>It should not harm anything and could be used by other routers in area
>>as a "heads-up" that remote link is becoming overloaded.
>
>I think this would be a good way forward as the OSPF Extended Attribute
>LSA will most likely be advertised for SR in OSPF Service Provider
>domains anyway. So, just advertising the area-scope for all use cases
>would seem to be the simplify this approach and get us past this
>discussion. In fact, the -00 version of the draft had area-scope alone
>and I, regretfully, had suggested the OSPF RI as possible way to get
>support either scope.
>
>Thanks,
>Acee 
>
>>
>>
>>>
>>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be
>>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure
>>>backward compatibility? What if the router on which overload is
>>>signalled does not do MAX-METRIC but the implementation on the remote
>>>side end up doing MAX-METRIC. Would it not result in asymmetric metric
>>>in a un-intended manner? Please consider changing all SHOULD here to
>>>MUST to ensure backward compatibility.
>>>
>>> 3) Sec 5.4, can you please make similar change in language related to
>>>the RFC4203 reference as you've done in other parts in this version?
>>>
>>> Also I don't agree with the rationale you've given for not using LLS
>>>for the link-local signalling. Even if the hello processing were
>>>delegated to the LC, there are already a lot of protocol events which
>>>can happen via hello packets (which includes LLS) that require
>>>signalling update to the control plane OSPF main process. An
>>>implementation aspect such as this should hardly be a good reason to
>>>not use LLS for link-local signalling such as overload.
>>
>>+1 on the above.
>>
>>thanks,
>>Peter
>>
>>>
>>> Thanks,
>>> Ketan
>>>
>>> -Original Message-
>>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of S

Re: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-18.txt

[Acee Lindem (acee)]

This version includes updates addressed AD comments including removing the
ERO and Binding-SID extensions. After discussions between Peter Psenak and
various parties, it was decided not to add the Binding-SID back and this
will potentially be addressed by Peter and Shraddha in a subsequent draft.

I’ve also updated the Shepherd’s report:

  
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions
/shepherdwriteup/

Thanks,
Acee 

On 7/18/17, 7:03 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 Extensions for Segment Routing
>Authors : Peter Psenak
>  Stefano Previdi
>  Clarence Filsfils
>  Hannes Gredler
>  Rob Shakir
>  Wim Henderickx
>  Jeff Tantsura
>   Filename: draft-ietf-ospf-segment-routing-extensions-18.txt
>   Pages   : 28
>   Date: 2017-07-18
>
>Abstract:
>   Segment Routing (SR) allows a flexible definition of end-to-end paths
>   within IGP topologies by encoding paths as sequences of topological
>   sub-paths, called "segments".  These segments are advertised by the
>   link-state routing protocols (IS-IS and OSPF).
>
>   This draft describes the OSPF extensions required for Segment
>   Routing.
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension
>s/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-18
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-exte
>nsions-18
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensio
>ns-18
>
>
>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] IETF 99 OSPF WG Meeting Minutes

[Acee Lindem (acee)]

The minutes from the IETF 99 WG Meeting have been posted. Thanks to Les 
Ginsberg for taking them.

https://www.ietf.org/proceedings/99/minutes/minutes-99-ospf-00.txt

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

[OSPF] FW: I-D Action: draft-ietf-bfd-yang-06.txt

[Acee Lindem (acee)]

FYI - We will have a separate OSPF BFD YANG module that augments the OSPF
interfaces and uses the BFD provided grouping. This will be done as part
of the current draft.

Thanks,
Acee

On 7/20/17, 10:18 AM, "Reshad Rahman (rrahman)"  wrote:

>We (BFD and OSPF YANG authors) had a discussion yesterday.
>
>The agreement is that since IGP peers are auto-discovered, we want to add
>back the basic BFD config (multiplier + intervals) in IGP via a grouping.
>BFD will provide that grouping in a specific YANG module. IGP BFD YANG
>will be in a separate module (separate from the main IGP module).
>
>
>Regards,
>Reshad.
>
>On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas"
> wrote:
>
>>Thanks authors for the edits on the BFD yang module.  This gets us a
>>significant step closer to alignment with the rest of IETF for network
>>instancing.
>>
>>I'd like to encourage the working group to provide feedback on this issue
>>and also the changes in the module.
>>
>>As noted in another thread, we still have to figure out how to deal with
>>accommodating interaction of the BFD yang module with client protocols.
>>For
>>example, the IGPs.  In particular, how do you configure the properties of
>>the BFD sessions that may be dynamically instantiated based on control
>>protocol activity?
>>
>>-- Jeff
>>
>>On Fri, Jun 30, 2017 at 12:55:59PM -0700, 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 Bidirectional Forwarding Detection of
>>>the IETF.
>>> 
>>> Title   : YANG Data Model for Bidirectional Forwarding
>>>Detection (BFD)
>>> Authors : Reshad Rahman
>>>   Lianshu Zheng
>>>   Mahesh Jethanandani
>>>   Santosh Pallagatti
>>>   Greg Mirsky
>>> Filename: draft-ietf-bfd-yang-06.txt
>>> Pages   : 59
>>> Date: 2017-06-30
>>> 
>>> Abstract:
>>>This document defines a YANG data model that can be used to
>>>configure
>>>and manage Bidirectional Forwarding Detection (BFD).
>>> 
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06
>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-06
>>> 
>>> 
>>> 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

Re: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-05.txt

[Acee Lindem (acee)]

Speaking as document shepherd:

This version resolves Alia’s AD comments. The is now using 2-octet Sub-TLV
type/length consistent with RFC 7770. For tunnel types, the existing RFC
5512 registry is referenced. For the Tunnel Encapsulation Attributes, we
elected to take the most straightforward approach and have a separate OSPF
registry. This will avoid the fact that BGP advertises at least one of
these attributes in communities (e.g., color) and the fact that IS-IS has
a different one-octet type/length vs OSPF’s 2-octet type/length.

Speaking as WG Co-Chair:

This also begins a 2-week last call on these changes (ends Tues, August
1st) at 12:00 AM UTC. This shouldn’t cause much delay (assuming consensus)
as Alia is backed up right now with this week’s IETF and a queue of other
documents. 

Thanks,
Acee

On 7/17/17, 3:50 AM, "bruno.decra...@orange.com"
<bruno.decra...@orange.com> wrote:

>Hi Alia, Acee, all
>
>draft-ietf-ospf-encapsulation-cap-06 has just been uploaded to address
>the comments received.
>Draft: https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-06
>Diff: 
>https://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-06.t
>xt
>
>Please see inline [Authors] more details about issues resolution
>
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Acee Lindem
>>(acee)
> > Sent: Wednesday, July 05, 2017 7:59 PM
> > To: Alia Atlas
> > Cc: ospf@ietf.org
> > Subject: Re: [OSPF] I-D Action:
>draft-ietf-ospf-encapsulation-cap-05.txt
> > 
> > Hi Alia,
> > 
> > So the issues we are still discussing are:
> > 
> >   1. Common IGP Tunnel Type/Tunnel Attribute IANA Registry or
>simply
> > reference the BGP registries created by RFC 5512.
>
>[Authors] There are 2 registries:
>a) Tunnel Encapsulation Type: registry shared with BGP  (since draft-05)
>Tunnel types are shared with the BGP  extension [RFC5512] and hence are
>defined in the existing IANA registry  "BGP Tunnel Encapsulation
>Attribute Tunnel Types".
>https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-05#section-4
>
>b) Tunnel Encapsulation Attribute Sub-TLVs: registry dedicated to OSPF
>(changed in draft-06)
>- Difficult to share with IS-IS as IS-IS has TLV size restrictions which
>do not match BGP and OSPF. Due to this restriction future sub-TLV may be
>encoded in a more compact way, possibly with less information.
>- Difficult to share with BGP as BGP attach the attribute to various type
>of BGP routes hence needs to handle labelled/unlabeled routes,
>underlay/overlay routes... The color sub-TLV already has a different
>syntax. (yet the same sub-TLV code point could have been used.)
>
> >   2. 1-octet or 2-octet type/length in Tunnel Encapsulation
>Attribute
> > Sub-TLVs. I’d vote for 2-octet for RFC 7770 consistency even though the
> > BGP registry code point is limited to 255 types.
>
>[Authors] draft-06 use 2 octets to encode the type, and 2 octets to
>encode the length, as typical for OSPF.
>
> >   3. Addition of the RFC 5640 ECMP block suggested by Carlos
>
>[Authors] Done.
>
>Thanks
>--Authors
>
> > Pignataro.
> > 
> > Thanks,
> > Acee
> > 
> > 
> > On 7/3/17, 10:52 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   : Advertising Tunneling Capability in OSPF
> > >Authors : Xiaohu Xu
> > >  Bruno Decraene
> > >  Robert Raszuk
> > >  Luis M. Contreras
> > >  Luay Jalil
> > >   Filename: draft-ietf-ospf-encapsulation-cap-05.txt
> > >   Pages   : 10
> > >   Date: 2017-07-03
> > >
> > >Abstract:
> > >   Networks use tunnels for a variety of reasons.  A large variety of
> > >   tunnel types are defined and the ingress needs to select a type of
> > >   tunnel which is supported by the egress and itself.  This document
> > >   defines how to advertise egress tunnel capabilities in OSPF Router
> > >   Information Link State Advertisement (LSAs).
> > >
> > >
> > >
> > >The IETF datatracker status page for this draft is:
> > >https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
> > >
> > >There ar

Re: [OSPF] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

[Acee Lindem (acee)]

OSPF Evolution and the role of
draft-ppsenak-ospf-te-link-attr-reuse

The document draft-ppsenak-ospf-te-link-attr-reuse-05.txt not-only
provides flexible and compact mechanisms and encodings for advertising
link attributes for single or multiple applications. It is also part of
the wider goal of transforming OSPF to a TLV-based protocol that is every
bit as extendable as the other IGPs while affording the distinct advantage
of optimally partitioning the advertised information into multiple LSAs of
different types. 

This draft represents the last piece of our vision to achieve this
outcome. For OSPFv2, we have the base LSAs that cannot be extended in a
backward compatible fashion. Additionally, we have RFC 7770 (OSPF Router
Information Advertisement) and RFC 7684 (OSPF Prefix/Link Attributes). The
former has been extended to support distribution of non-OSPF information
in addition to OSPF Router-level protocol information. The extended OSPF
Prefix/Link LSAs are being used to support segment routing and other
technologies. They are now part of the OSPF base and will be advertised in
many OSPF domains. The major implementations have the capability to
correlate the base LSAs and the OSPF Prefix/Link LSAs for segment routing.
This correlation requires handling lots of chicken and egg complexities
that have all been overcome.

It has been suggested that since the OSPF TE LSAs (RFC 3630) contain some
generally useful link attributes, this be the only means by which this
information is advertised in OSPF routing domains. This will be both
unwieldy and inefficient due to the advertisement, processing, and storage
of the TE LSAs in networks not utilizing RSVP-based TE.  There is also the
added complexity with this approach as you have not only the chicken and
the egg, but the chicken, egg, and the rooster to correlate.

For OSPFv3 and OSPFv3 Extended LSAs
(draft-ietf-ospf-ospfv3-lsa-extend-14.txt), we have made the difficult
choice to extend the base RFC 5340 LSAs (OSPF for IPv6) in a
non-compatible fashion. After an initial delay, we have implementations of
the OSPFv3 Extended LSAs draft and will soon be advancing it. With the
OSPFv3 extended LSAs, we are finally at the point where all the
information (other than RSVP TE information) for a given prefix or link is
advertised in a single LSA rather than multiple LSAs. Would those who
argue for making OSPFv2 TE LSAs generally applicable also want to require
the advertisement of RFC 5329 (OSPFv3 Traffic Engineering) LSAs?  If so,
we would miss a tremendous opportunity.


Thanks,
Acee

On 7/6/17, 6:10 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Support as co-author. More to come…
>Acee 
>
>On 7/3/17, 2:37 PM, "OSPF on behalf of Abhay Roy (akr)"
><ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:
>
>>We would like to kick-off a poll for WG adoption of the following
>>document (per Authors request):
>>
>>https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse
>>
>>Please let us know if you support or have concerns with OSPF WG adopting
>>this work.
>>
>>Regards,
>>-Abhay
>>
>>___
>>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] WG adoption poll for draft-ppsenak-ospf-te-link-attr-reuse

[Acee Lindem (acee)]

Support as co-author. More to come…
Acee 

On 7/3/17, 2:37 PM, "OSPF on behalf of Abhay Roy (akr)"
 wrote:

>We would like to kick-off a poll for WG adoption of the following
>document (per Authors request):
>
>https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse
>
>Please let us know if you support or have concerns with OSPF WG adopting
>this work.
>
>Regards,
>-Abhay
>
>___
>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-07.txt

[Acee Lindem (acee)]

Hi Peter, Shradha, 

On 7/6/17, 3:30 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
 wrote:

>On 06/07/17 05:50 , Ketan Talaulikar (ketant) wrote:
>> Hi Shraddha,
>>
>> Thanks for taking care of some of the comments shared previously.
>>Please find below some more that were probably missed or not taken care
>>of.
>>
>> 1) I see that the use of link-local scope RI LSA has still been
>>retained in this version and not sure why. RI LSA is for node attributes
>>and it's use for signalling of link is not right IMO. Why not use the
>>link-local scope Extended Link LSA instead?
>
>an alternative would be to always flood area scope Extended Link LSA. It
>should not harm anything and could be used by other routers in area as a
>"heads-up" that remote link is becoming overloaded.

I think this would be a good way forward as the OSPF Extended Attribute
LSA will most likely be advertised for SR in OSPF Service Provider domains
anyway. So, just advertising the area-scope for all use cases would seem
to be the simplify this approach and get us past this discussion. In fact,
the -00 version of the draft had area-scope alone and I, regretfully, had
suggested the OSPF RI as possible way to get support either scope.

Thanks,
Acee 

>
>
>>
>> 2) Sec 5.1, why is advertising of MAX-METRIC for the link to be
>>overloaded a SHOULD and not a MUST? Isn't this mandatory to ensure
>>backward compatibility? What if the router on which overload is
>>signalled does not do MAX-METRIC but the implementation on the remote
>>side end up doing MAX-METRIC. Would it not result in asymmetric metric
>>in a un-intended manner? Please consider changing all SHOULD here to
>>MUST to ensure backward compatibility.
>>
>> 3) Sec 5.4, can you please make similar change in language related to
>>the RFC4203 reference as you've done in other parts in this version?
>>
>> Also I don't agree with the rationale you've given for not using LLS
>>for the link-local signalling. Even if the hello processing were
>>delegated to the LC, there are already a lot of protocol events which
>>can happen via hello packets (which includes LLS) that require
>>signalling update to the control plane OSPF main process. An
>>implementation aspect such as this should hardly be a good reason to not
>>use LLS for link-local signalling such as overload.
>
>+1 on the above.
>
>thanks,
>Peter
>
>>
>> Thanks,
>> Ketan
>>
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Shraddha Hegde
>> Sent: 03 July 2017 11:11
>> To: internet-dra...@ietf.org; i-d-annou...@ietf.org
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>> OSPF WG,
>>
>> New version of the ospf-link-overload draft is posted.
>> Editorial comments received so far have been addressed in this version.
>>
>> There was one comments to move the link-overload sub-TLV to LLS in
>>hello messages.
>> Many implementations delegate the Hello processing to
>>linecards/different deamons
>> Once adjacency is established. Hello messages are not sent to control
>>plane
>> post adjacency establishment. The link-overload information typically
>>needs to be processed
>> after adjacency establishment, it introduces unnecessary complexity in
>>hello processing.
>> We had a discussion among authors on this and feel advertising
>>link-overload sub-TLV
>> in the LSAs is the most appropriate mechanism.
>>
>>
>>
>> Rgds
>> Shraddha
>>
>> -Original Message-
>> From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of
>>internet-dra...@ietf.org
>> Sent: Monday, July 3, 2017 11:01 AM
>> To: i-d-annou...@ietf.org
>> Cc: ospf@ietf.org
>> Subject: [OSPF] I-D Action: draft-ietf-ospf-link-overload-07.txt
>>
>>
>> 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-07.txt
>>  Pages   : 14
>>  Date: 2017-07-02
>>
>> 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 

Re: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-05.txt

[Acee Lindem (acee)]

Hi Alia, 

So the issues we are still discussing are:

  1. Common IGP Tunnel Type/Tunnel Attribute IANA Registry or simply
reference the BGP registries created by RFC 5512.
  2. 1-octet or 2-octet type/length in Tunnel Encapsulation Attribute
Sub-TLVs. I’d vote for 2-octet for RFC 7770 consistency even though the
BGP registry code point is limited to 255 types.
  3. Addition of the RFC 5640 ECMP block suggested by Carlos
Pignataro. 

Thanks,
Acee 
  

On 7/3/17, 10:52 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   : Advertising Tunneling Capability in OSPF
>Authors : Xiaohu Xu
>  Bruno Decraene
>  Robert Raszuk
>  Luis M. Contreras
>  Luay Jalil
>   Filename: draft-ietf-ospf-encapsulation-cap-05.txt
>   Pages   : 10
>   Date: 2017-07-03
>
>Abstract:
>   Networks use tunnels for a variety of reasons.  A large variety of
>   tunnel types are defined and the ingress needs to select a type of
>   tunnel which is supported by the egress and itself.  This document
>   defines how to advertise egress tunnel capabilities in OSPF Router
>   Information Link State Advertisement (LSAs).
>
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-05
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-05
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-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

Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

[Acee Lindem (acee)]

Hi Chao,

I think rules (e) 1 and (e) 2 should remain to handle the case of an NSSA that 
receives both the intra-NSSA LSA and a translated AS External LSA (via a 
backbone path). I only think that rule (e) 3 needs to be relaxed. If we were 
doing another NSSA BIS, I’d remove it completely but since we are just talking 
about an Errata, I think we should just make the Router ID tie-breaker optional.

Thanks,
Acee

From: Chao Fu <chao...@ericsson.com<mailto:chao...@ericsson.com>>
Date: Wednesday, July 5, 2017 at 3:02 AM
To: "Balaji Ganesh (balagane)" <balag...@cisco.com<mailto:balag...@cisco.com>>, 
OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: RE: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

In my opinion rule (e) should be removed. ( 
https://mailarchive.ietf.org/arch/search/?email_list=ospf=%5BTechnical+Errata+Reported%5D+RFC3101
 ).
If not, it should be clarified more including removing “2. A Type-5 LSA.”

Regards,
Chao Fu

From: OSPF [mailto:ospf-boun...@ietf.org] On Behalf Of Balaji Ganesh (balagane)
Sent: Wednesday, July 05, 2017 14:01
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>; Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

Any views/comments on the below?

Regards,
Balaji

From: Acee Lindem (acee)
Sent: 19 June 2017 00:08
To: Balaji Ganesh (balagane) <balag...@cisco.com<mailto:balag...@cisco.com>>; 
OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi –  I encouraged Balaji to post to the list is that I think many 
implementations have ignored #3. I know that I changed the IBM implementation 
to compute ECMP routes to multiple ASBRs and had the Redback implementation do 
this from the start. Consequently, we’d like to solicit input as to what other 
implementations do. If we can reach consensus on this, we could issue an Errata 
to make this optional.

Thanks,
Acee

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
"Balaji Ganesh (balagane)" <balag...@cisco.com<mailto:balag...@cisco.com>>
Date: Tuesday, June 13, 2017 at 4:13 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

When the metrics are same, RFC 3101 specifies the preference for NSSA/External 
routes as follows.
In the section 2.5<https://tools.ietf.org/html/rfc3101#section-2.5> Calculating 
Type-7 AS External Routes - 2.5.6.(e), it says..

  (e) If the current LSA is functionally the same as an
  installed LSA (i.e., same destination, cost and non-zero
  forwarding address) then apply the following priorities in
  deciding which LSA is preferred:

 1. A Type-7 LSA with the P-bit set.

 2. A Type-5 LSA.

 3. The LSA with the higher router ID.


Points 1 and 2 are clear..

However Point 3 specifies preference of an LSA with a higher router ID. Why is 
it so?


  *   Should we not install ECMP paths in this case?
  *   Is point 3 actually intended for NSSA translators to prefer a Type 7 LSA 
which needs to be used for translation to Type 5?

Considering the above 2 points, I guess point 3 needs to be modified in the RFC 
to probably say..

3. Preference is same, install ECMP paths.
   Additionally if the router is an NSSA translator, prefer 
the LSA with higher router ID for Type 7-Type 5 translation.

Please let know any views/comments on the same.

Regards,
Balaji

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

Re: [OSPF] Working Group Last Call for OSPFv2 Segment Routing - draft-ietf-ospf-segment-routing-extensions-17

[Acee Lindem (acee)]

The WG last call on the -17 updates to the document has concluded without
substantive comment.

Thanks,
Acee 

On 6/23/17, 2:07 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Since an unimplemented section was removed and there were also a number of
>clarifications, I’d like to request a WG last call on the modified draft.
>It will end on July 1st, 2017 at 12:00 AM GMT. For your convenience, here
>are the relevant links.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extension
>s
>/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-17
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-exte
>n
>sions-17
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensio
>n
>s-17
>
>Thanks,
>Acee 
>
>
>
>
>On 6/23/17, 6:14 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
><ospf-boun...@ietf.org on behalf of ppse...@cisco.com> wrote:
>
>>Hi Alia,
>>
>>thanks for comments, please see inline:
>>
>>
>>On 31/05/17 04:05 , Alia Atlas wrote:
>>> As is customary, I have done my AD review
>>> of draft-ietf-ospf-segment-routing-extensions-16 once publication has
>>> been requested.  First, I would like to thank the editors & many
>>> authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the
>>>work
>>> that they have put in so far and the remaining work that is greatly
>>>needed.
>>>
>>> While there are a great many issues to be handled, they fall primarily
>>> into three categories.  The first is simply not going through and
>>> tightening up the details; for example, stating that the length of a
>>>TLV
>>> is variable provides no meaning.  The second is that the technical
>>> documents from SPRING that this draft depends on do not adequately
>>> describe the use of the advertised information (SID/Label Binding TLV)
>>> or some of the concepts (e.g. SR Mapping Server).  The third is a more
>>> common set of handling error cases and adding clarity to the intended
>>> behavior.  I do not see issues with the encodings but I do see
>>>fragility
>>> with the unstated assumptions and behaviors.  The draft describes
>>> encodings, but very little of the handling, behaviors, or meaning - and
>>> the references do not provide adequate detail.
>>>
>>> I have spent all day (and evening) doing this review and I am quite
>>> disappointed and concerned about the document.  I would strongly
>>> recommend having sharing the next WGLC with the SPRING working group;
>>> perhaps more eyes will help with the discrepancies.
>>>
>>> I have not yet decided what to do about the "early" IANA allocation -
>>> which has now existed for this draft for 3 years.  I do know that there
>>> are implementations,
>>> but I am currently seeing the failure of this work to successfully
>>> complete as an example of an issue with providing early allocations.
>>>
>>> MAJOR ISSUES:
>>>
>>> 1) This draft has 7 authors.  The limit for authors & editors is 5, as
>>> is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well
>>> over a decade, unless there are extraordinary circumstances.  Is there
>>>a
>>> reason to not simply list the active editor and move the others to
>>> contributors?  One of the authors is already listed there.  I regret
>>> that failure to deal earlier with this long-standing IETF policy will
>>>be
>>> delaying progressing the draft.
>>
>>I don't know how to resolve this. I can not tell any of the coauthors
>>that I'm going to drop him from the list after his contribution to this
>>for several years. Two of us are marked as editors already.
>>
>>
>>>
>>> 2) This expired individual
>>> draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as
>>> Informative - but IS ACTUALLY NORMATIVE since it DEFINES the
>>> "M-bit - When the bit is set, the binding represents a mirroring
>>>context
>>> as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]."
>>>   Unfortunately, when I look there for the definition of a mirroring
>>> context, it doesn't exists.
>>
>>Section 6 was removed.
>>
>>
>>>

[OSPF] FW: IPR Call for "H-Support for OSPFv2"

[Acee Lindem (acee)]

From: "Serpil Bayraktar (serpil)" <ser...@cisco.com<mailto:ser...@cisco.com>>
Date: Saturday, July 1, 2017 at 11:50 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Padmadevi Pillay 
Esnault <pa...@huawei.com<mailto:pa...@huawei.com>>, Keyur Patel 
<ke...@arrcus.com<mailto:ke...@arrcus.com>>
Subject: Re: [OSPF] IPR Call for "H-Support for OSPFv2"

I am not aware of any IPR.

Apologies for the late response, I am out on PTO.

Serpil


Authors,

If you are listed as a document author or contributor, please respond to
this email stating whether or not you are aware of any relevant IPR. The
response needs to be sent to the OSPF mailing list. The document will
not advance to the next stage until a response has been received from
each author and each individual that has contributed to the document.

Thanks,
Acee



On 6/14/17, 3:48 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org> on behalf of 
a...@cisco.com<mailto:a...@cisco.com>> wrote:

The question of OSPFv2 complete blocking of transit routing support
(similar to OSPFv3) seems to come up every year or so. I’d like to WG
last
call this document. Does anyone see any issues?
Thanks,
Acee

On 6/14/17, 12:44 PM, "OSPF on behalf of 
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>"
<ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org> on behalf of 
internet-dra...@ietf.org<mailto: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   : H-bit Support for OSPFv2
Authors : Keyur Patel
  Padma Pillay-Esnault
  Manish Bhardwaj
  Serpil Bayraktar
Filename: draft-ietf-ospf-ospfv2-hbit-03.txt
Pages   : 8
Date: 2017-06-14

Abstract:
   OSPFv3 defines an option field for router-LSAs known as a R-bit in
   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
   OSPF topology distribution without acting as a forwarder to forward
   the transit traffic.  In such cases, an OSPF router would only accept
   traffic intended for local delivery.  This draft defines R-bit
   functionality for OSPFv2 defined in RFC2328.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv2-hbit-03
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv2-hbit-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv2-hbit-03


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<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf

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

___
OSPF mailing list
OSPF@ietf.org<mailto: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] AD review of draft-ietf-ospf-encapsulation-cap-03

[Acee Lindem (acee)]

Hi Bruno,

From: Bruno Decraene 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Date: Friday, June 30, 2017 at 12:07 PM
To: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>, Acee Lindem 
<a...@cisco.com<mailto:a...@cisco.com>>, 
"draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>"
 
<draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: RE: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Acee, Alia,

From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Friday, June 30, 2017 5:59 PM
To: Acee Lindem (acee)
Cc: DECRAENE Bruno IMT/OLN; OSPF List; 
draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Acee,

On Fri, Jun 30, 2017 at 11:52 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Alia, Bruno,

From: OSPF <ospf-boun...@ietf.org<mailto:ospf-boun...@ietf.org>> on behalf of 
Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Friday, June 30, 2017 at 11:30 AM
To: Bruno Decraene <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, 
"draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>"
 
<draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Bruno,

On Fri, Jun 30, 2017 at 8:31 AM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:
Hi Alia,

More inline [Bruno2]

From: Alia Atlas [mailto:akat...@gmail.com<mailto:akat...@gmail.com>]
Sent: Thursday, June 29, 2017 11:09 PM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF List; 
draft-ietf-ospf-encapsulation-...@ietf.org<mailto:draft-ietf-ospf-encapsulation-...@ietf.org>;
 Xuxiaohu
Subject: Re: AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Bruno,

Thanks for the updated draft - more in-line.

On Mon, Jun 26, 2017 at 5:59 AM, 
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> wrote:
Hi Alia,

Many thanks for the useful review.
-04 has just been published. I believe it address your first pass of comments.
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-04



Main changes:
- aligning with  I-D.ietf-idr-tunnel-encaps rather than RFC 5512.
- adding 2 sub-TLV coming from I-D.ietf-idr-tunnel-encaps: IP QoS Field, UDP 
Destination Port. Note that the first one is currently called "IPv4 DS Field" 
in the IDR draft. I've commented on IDR that this is IPv4 specific with no IPv6 
counterpart.

[Alia] The text for the UDP Destination Port (Sec 6.6) is wrong - it's just 
copied from Sec 6.5.
[Bruno2] thanks, fixed
I agree with you on the need for the IP QoS field to represent both IPv6 as 
well as IPv4; it also just talks about the DS field - but that's 6 bits.  Are 
the ECN bits included?  That's a conversation for IDR.
[Bruno2] agreed (that’s for IDR)

Waiting for the resolution. We need the BGP and IGP draft to be aligned.
- removed registry "IGP Tunnel Encapsulation Type" and pointing to existing 
registry "BGP Tunnel Encapsulation Type"
- (editorial) Sub-TLV of the Tunnel Encapsulation Attribute are grouped in a 
dedicated section (§6)
- clarification that for all but one, those sub-TLV are defined in 
I-D.ietf-idr-tunnel-encaps, from a syntax, semantic and usage standpoint.
- color Sub-TLV better defined (as not aligned with the IDR draft)
- added a section about the usage of the Tunnel Encapsulation attribute (§7)
- a significant rule added: " A tunnel MUST NOT be used if there is no route 
toward the IP address
   specified in the Endpoint Sub-TLV or if the route is not advertised
   by the router advertising the Tunnel Encapsulation attribute
   advertising this tunnel. "


Some follow up on some of your points that I had missed in previous answer:

> From: Alia Atlas [mailto:akat...@gmail.com<mailto:akat...@gmail.com>]
> Sent: Thursday, June 15, 2017 12:56 AM
[...]
> (does variable length fields based upon the allocated type cause issues for 
> OSPF sub-TLV parsing???)

I guess that you are referring to
"   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
  sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
  the Sub-TLV Type field contains a value in the range from 1-127.
  The Sub-TLV Length field contains two octets if the Sub-TLV Type
  field contains 

Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

[Acee Lindem (acee)]

Hi Alia, Bruno,

From: OSPF > on behalf of 
Alia Atlas >
Date: Friday, June 30, 2017 at 11:30 AM
To: Bruno Decraene >
Cc: OSPF WG List >, 
"draft-ietf-ospf-encapsulation-...@ietf.org"
 
>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Bruno,

On Fri, Jun 30, 2017 at 8:31 AM, 
> wrote:
Hi Alia,

More inline [Bruno2]

From: Alia Atlas [mailto:akat...@gmail.com]
Sent: Thursday, June 29, 2017 11:09 PM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF List; 
draft-ietf-ospf-encapsulation-...@ietf.org;
 Xuxiaohu
Subject: Re: AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Bruno,

Thanks for the updated draft - more in-line.

On Mon, Jun 26, 2017 at 5:59 AM, 
> wrote:
Hi Alia,

Many thanks for the useful review.
-04 has just been published. I believe it address your first pass of comments.
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-04



Main changes:
- aligning with  I-D.ietf-idr-tunnel-encaps rather than RFC 5512.
- adding 2 sub-TLV coming from I-D.ietf-idr-tunnel-encaps: IP QoS Field, UDP 
Destination Port. Note that the first one is currently called "IPv4 DS Field" 
in the IDR draft. I've commented on IDR that this is IPv4 specific with no IPv6 
counterpart.

[Alia] The text for the UDP Destination Port (Sec 6.6) is wrong - it's just 
copied from Sec 6.5.
[Bruno2] thanks, fixed
I agree with you on the need for the IP QoS field to represent both IPv6 as 
well as IPv4; it also just talks about the DS field - but that's 6 bits.  Are 
the ECN bits included?  That's a conversation for IDR.
[Bruno2] agreed (that’s for IDR)

Waiting for the resolution. We need the BGP and IGP draft to be aligned.
- removed registry "IGP Tunnel Encapsulation Type" and pointing to existing 
registry "BGP Tunnel Encapsulation Type"
- (editorial) Sub-TLV of the Tunnel Encapsulation Attribute are grouped in a 
dedicated section (§6)
- clarification that for all but one, those sub-TLV are defined in 
I-D.ietf-idr-tunnel-encaps, from a syntax, semantic and usage standpoint.
- color Sub-TLV better defined (as not aligned with the IDR draft)
- added a section about the usage of the Tunnel Encapsulation attribute (§7)
- a significant rule added: " A tunnel MUST NOT be used if there is no route 
toward the IP address
   specified in the Endpoint Sub-TLV or if the route is not advertised
   by the router advertising the Tunnel Encapsulation attribute
   advertising this tunnel. "


Some follow up on some of your points that I had missed in previous answer:

> From: Alia Atlas [mailto:akat...@gmail.com]
> Sent: Thursday, June 15, 2017 12:56 AM
[...]
> (does variable length fields based upon the allocated type cause issues for 
> OSPF sub-TLV parsing???)

I guess that you are referring to
"   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
  sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
  the Sub-TLV Type field contains a value in the range from 1-127.
  The Sub-TLV Length field contains two octets if the Sub-TLV Type
  field contains a value in the range from 128-254."
https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-06#section-2

The IGP draft does not use this. It uses a fixed 1-octet length field:
" Sub-TLV Length (1 octet): Unsigned 8-bit integer indicating the
  total number of octets of the Sub-TLV value field."
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04#section-5

[Alia] I think that there is still clarification on what to do if (in the 
future) a sub-TLV that
used the 2-octet length couldn't fit into a 1-octet length. I know this is 
currently hypothetical,
so all I'm looking for is a statement about the difference and that such 
sub-TLVs are not supported
without further extensions.

 [Bruno2] There are 2 “Tunnel Encapsulation Attribute Types” registries:
- one for BGP, which allow length of 1 or 2 octets (as per the 
draft-ietf-idr-tunnel-encaps-06 because RFC 5512 only allowed for 1 octet)
- one for IGP, which allow length of 1 octet
Even though it is unlikely to be required, can we just go with 2 octet type and 
length for the tunnel attribute Sub-TLVs consistent with the TLV format in RFC 
7770? Seems like this would simplify things – I guess we are worried about 
IS-IS consistency?

Thanks,
Acee





For the IGP, 

Re: [OSPF] [Bier] I-D Action: draft-ietf-bier-ospf-bier-extensions-06.txt

[Acee Lindem (acee)]

BIER and OSPF WGs, 

This version includes my very minor editorial comments. I fully support
publication. I’d encourage others to review, comment, and hopefully
support. 

Thanks,
Acee 

On 6/20/17, 12:20 PM, "BIER 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 Bit Indexed Explicit Replication of the
>IETF.
>
>Title   : OSPF Extensions for BIER
>Authors : Peter Psenak
>  Nagendra Kumar
>  IJsbrand Wijnands
>  Andrew Dolganow
>  Tony Przygienda
>  Jeffrey Zhang
>  Sam Aldrin
>   Filename: draft-ietf-bier-ospf-bier-extensions-06.txt
>   Pages   : 9
>   Date: 2017-06-20
>
>Abstract:
>   Bit Index Explicit Replication (BIER) is an architecture that
>   provides multicast forwarding through a "BIER domain" without
>   requiring intermediate routers to maintain multicast related per-flow
>   state.  Neither does BIER require an explicit tree-building protocol
>   for its operation.  A multicast data packet enters a BIER domain at a
>   "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
>   one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router
>   adds a BIER header to the packet.  Such header contains a bit-string
>   in which each bit represents exactly one BFER to forward the packet
>   to.  The set of BFERs to which the multicast packet needs to be
>   forwarded is expressed by the according set of bits set in BIER
>   packet header.
>
>   This document describes the OSPF protocol extension required for BIER
>   with MPLS encapsulation.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-bier-ospf-bier-extensions-06
>https://datatracker.ietf.org/doc/html/draft-ietf-bier-ospf-bier-extensions
>-06
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-ospf-bier-extensions-06
>
>
>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/
>
>___
>BIER mailing list
>b...@ietf.org
>https://www.ietf.org/mailman/listinfo/bier

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

Re: [OSPF] IPR Call for "H-Support for OSPFv2"

[Acee Lindem (acee)]

Corrected draft alias - reply to this one.

On 6/26/17, 6:45 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>Authors,
>
>If you are listed as a document author or contributor, please respond to
>this email stating whether or not you are aware of any relevant IPR. The
>response needs to be sent to the OSPF mailing list. The document will
>not advance to the next stage until a response has been received from
>each author and each individual that has contributed to the document.
> 
>
>Thanks,
>Acee
>
>
>
>On 6/14/17, 3:48 PM, "OSPF on behalf of Acee Lindem (acee)"
><ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:
>
>>The question of OSPFv2 complete blocking of transit routing support
>>(similar to OSPFv3) seems to come up every year or so. I’d like to WG
>>last
>>call this document. Does anyone see any issues?
>>Thanks,
>>Acee 
>>
>>On 6/14/17, 12:44 PM, "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   : H-bit Support for OSPFv2
>>>Authors : Keyur Patel
>>>  Padma Pillay-Esnault
>>>  Manish Bhardwaj
>>>  Serpil Bayraktar
>>> Filename: draft-ietf-ospf-ospfv2-hbit-03.txt
>>> Pages   : 8
>>> Date: 2017-06-14
>>>
>>>Abstract:
>>>   OSPFv3 defines an option field for router-LSAs known as a R-bit in
>>>   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
>>>   OSPF topology distribution without acting as a forwarder to forward
>>>   the transit traffic.  In such cases, an OSPF router would only accept
>>>   traffic intended for local delivery.  This draft defines R-bit
>>>   functionality for OSPFv2 defined in RFC2328.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/
>>>
>>>There are also htmlized versions available at:
>>>https://tools.ietf.org/html/draft-ietf-ospf-ospfv2-hbit-03
>>>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv2-hbit-03
>>>
>>>A diff from the previous version is available at:
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv2-hbit-03
>>>
>>>
>>>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] IPR Call for "H-Support for OSPFv2"

[Acee Lindem (acee)]

Authors,

If you are listed as a document author or contributor, please respond to
this email stating whether or not you are aware of any relevant IPR. The
response needs to be sent to the OSPF mailing list. The document will
not advance to the next stage until a response has been received from
each author and each individual that has contributed to the document.
 

Thanks,
Acee



On 6/14/17, 3:48 PM, "OSPF on behalf of Acee Lindem (acee)"
<ospf-boun...@ietf.org on behalf of a...@cisco.com> wrote:

>The question of OSPFv2 complete blocking of transit routing support
>(similar to OSPFv3) seems to come up every year or so. I’d like to WG last
>call this document. Does anyone see any issues?
>Thanks,
>Acee 
>
>On 6/14/17, 12:44 PM, "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   : H-bit Support for OSPFv2
>>Authors : Keyur Patel
>>  Padma Pillay-Esnault
>>  Manish Bhardwaj
>>  Serpil Bayraktar
>>  Filename: draft-ietf-ospf-ospfv2-hbit-03.txt
>>  Pages   : 8
>>  Date: 2017-06-14
>>
>>Abstract:
>>   OSPFv3 defines an option field for router-LSAs known as a R-bit in
>>   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
>>   OSPF topology distribution without acting as a forwarder to forward
>>   the transit traffic.  In such cases, an OSPF router would only accept
>>   traffic intended for local delivery.  This draft defines R-bit
>>   functionality for OSPFv2 defined in RFC2328.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/
>>
>>There are also htmlized versions available at:
>>https://tools.ietf.org/html/draft-ietf-ospf-ospfv2-hbit-03
>>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv2-hbit-03
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv2-hbit-03
>>
>>
>>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

Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

[Acee Lindem (acee)]

Thanks Bruno - I think this update provides simplification and brings us
closer to publication. It will be, however, now be gated on the IDR tunnel
encaps draft which has staled due to implementation discussions.

Thanks,
Acee 

On 6/26/17, 5:59 AM, "OSPF on behalf of bruno.decra...@orange.com"
 wrote:

>Hi Alia, 
>
>Many thanks for the useful review.
>-04 has just been published. I believe it address your first pass of
>comments.
>Htmlized:   
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
>Diff:   
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-04
>
>
>
>Main changes:
>- aligning with  I-D.ietf-idr-tunnel-encaps rather than RFC 5512.
>- adding 2 sub-TLV coming from I-D.ietf-idr-tunnel-encaps: IP QoS Field,
>UDP Destination Port. Note that the first one is currently called "IPv4
>DS Field" in the IDR draft. I've commented on IDR that this is IPv4
>specific with no IPv6 counterpart. Waiting for the resolution. We need
>the BGP and IGP draft to be aligned.
>- removed registry "IGP Tunnel Encapsulation Type" and pointing to
>existing registry "BGP Tunnel Encapsulation Type"
>- (editorial) Sub-TLV of the Tunnel Encapsulation Attribute are grouped
>in a dedicated section (§6)
>- clarification that for all but one, those sub-TLV are defined in
>I-D.ietf-idr-tunnel-encaps, from a syntax, semantic and usage standpoint.
>- color Sub-TLV better defined (as not aligned with the IDR draft)
>- added a section about the usage of the Tunnel Encapsulation attribute
>(§7)
>- a significant rule added: " A tunnel MUST NOT be used if there is no
>route toward the IP address
>   specified in the Endpoint Sub-TLV or if the route is not advertised
>   by the router advertising the Tunnel Encapsulation attribute
>   advertising this tunnel. "
>
>
>Some follow up on some of your points that I had missed in previous
>answer:
>
>> From: Alia Atlas [mailto:akat...@gmail.com]
>> Sent: Thursday, June 15, 2017 12:56 AM
>[...]
>> (does variable length fields based upon the allocated type cause issues
>>for OSPF sub-TLV parsing???)
>
>I guess that you are referring to
>"   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
>  sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
>  the Sub-TLV Type field contains a value in the range from 1-127.
>  The Sub-TLV Length field contains two octets if the Sub-TLV Type
>  field contains a value in the range from 128-254."
>https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-06#sect
>ion-2
>
>The IGP draft does not use this. It uses a fixed 1-octet length field:
>" Sub-TLV Length (1 octet): Unsigned 8-bit integer indicating the
>  total number of octets of the Sub-TLV value field."
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
>#section-5
>
>
>> Semantics and behavior need to be specified - not just the encodings
>
>Agreed.
>Note however that the behavior is more complex in the BGP draft, because
>the Tunnel Attribute is attached to BGP routes, which can be of various
>SAFI with their own semantic and usage (e.g. GRT vs VPN/overlay case,
>labeled/unlabeled...) and their interaction with the different kind of
>tunnels (GRT vs VPN, labeled vs unlabeled). This is not the case in the
>IGP draft which only signals the tunnel itself (discovery, parameters).
>
>
>Thanks again for the careful review and the useful comments.
>
>Regards,
>--Bruno 
>
>> From: Alia Atlas [mailto:akat...@gmail.com]  > Sent: Tuesday, June 20,
>>2017 5:27 PM
>> 
> > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu  wrote:
> > 
> > > Hi Alia,
> > >
> > >
> > >
> > > Thanks a lot for your AD review. Please see our response inline.
> > >
> > >
> > >
> > > *发件人**:* Alia Atlas [mailto:akat...@gmail.com ]
> > > *发送时间**:* 2017年6月15日 6:56
> > > *收件人**:* OSPF List; draft-ietf-ospf-encapsulation-...@ietf.org
> > > *主题**:* AD review of draft-ietf-ospf-encapsulation-cap-03
> > >
> > >
> > >
> > > As is customary, I have done my AD review of draft-ietf-ospf-
> > > encapsulation-cap-03.
> > >
> > > First, I would like to thank the authors - Xiaohu, Bruno, Robert,
>Luis,
> > > and Luay - for their work on this useful document.
> > >
> > >
> > >
> > > I do have a few concerns that need addressing before the draft can
> > > progress.
> > >
> > >
> > >
> > > [Bruno/Xiaohu] Many thanks for your useful comments.
> > >
> > > Following your comments, we believe it would be simpler and better
>to not
> > > create a new IANA registry for ”IGP  Tunnel Encapsulation Attribute
>Types”
> > > but rather reuse the existing BGP one:
> > >
> > > https://www.iana.org/assignments/bgp-parameters/
> > > bgp-parameters.xhtml#tunnel-types
> > >
> > 
> > Given that the sub-TLVs available depend on the tunnel type, I think
>this
> > makes sense.
> > 
> > 
> > 
> > > [Bruno/Xiaohu] BTW when this OSPF extension 

[OSPF] Working Group Last Call for OSPFv2 Segment Routing - draft-ietf-ospf-segment-routing-extensions-17

[Acee Lindem (acee)]

Since an unimplemented section was removed and there were also a number of
clarifications, I’d like to request a WG last call on the modified draft.
It will end on July 1st, 2017 at 12:00 AM GMT. For your convenience, here
are the relevant links.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions
/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-17
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-segment-routing-exten
sions-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extension
s-17

Thanks,
Acee 




On 6/23/17, 6:14 AM, "OSPF on behalf of Peter Psenak (ppsenak)"
 wrote:

>Hi Alia,
>
>thanks for comments, please see inline:
>
>
>On 31/05/17 04:05 , Alia Atlas wrote:
>> As is customary, I have done my AD review
>> of draft-ietf-ospf-segment-routing-extensions-16 once publication has
>> been requested.  First, I would like to thank the editors & many
>> authors, Peter, Stefano, Clarence, Hannes, Rob, Wim & Jeff, for the work
>> that they have put in so far and the remaining work that is greatly
>>needed.
>>
>> While there are a great many issues to be handled, they fall primarily
>> into three categories.  The first is simply not going through and
>> tightening up the details; for example, stating that the length of a TLV
>> is variable provides no meaning.  The second is that the technical
>> documents from SPRING that this draft depends on do not adequately
>> describe the use of the advertised information (SID/Label Binding TLV)
>> or some of the concepts (e.g. SR Mapping Server).  The third is a more
>> common set of handling error cases and adding clarity to the intended
>> behavior.  I do not see issues with the encodings but I do see fragility
>> with the unstated assumptions and behaviors.  The draft describes
>> encodings, but very little of the handling, behaviors, or meaning - and
>> the references do not provide adequate detail.
>>
>> I have spent all day (and evening) doing this review and I am quite
>> disappointed and concerned about the document.  I would strongly
>> recommend having sharing the next WGLC with the SPRING working group;
>> perhaps more eyes will help with the discrepancies.
>>
>> I have not yet decided what to do about the "early" IANA allocation -
>> which has now existed for this draft for 3 years.  I do know that there
>> are implementations,
>> but I am currently seeing the failure of this work to successfully
>> complete as an example of an issue with providing early allocations.
>>
>> MAJOR ISSUES:
>>
>> 1) This draft has 7 authors.  The limit for authors & editors is 5, as
>> is clearly stated in RFC 7322 Sec 4.1.1 and has been the case for well
>> over a decade, unless there are extraordinary circumstances.  Is there a
>> reason to not simply list the active editor and move the others to
>> contributors?  One of the authors is already listed there.  I regret
>> that failure to deal earlier with this long-standing IETF policy will be
>> delaying progressing the draft.
>
>I don't know how to resolve this. I can not tell any of the coauthors
>that I'm going to drop him from the list after his contribution to this
>for several years. Two of us are marked as editors already.
>
>
>>
>> 2) This expired individual
>> draft(draft-minto-rsvp-lsp-egress-fast-protection-03) is listed as
>> Informative - but IS ACTUALLY NORMATIVE since it DEFINES the
>> "M-bit - When the bit is set, the binding represents a mirroring context
>> as defined in [I-D.minto-rsvp-lsp-egress-fast-protection]."
>>   Unfortunately, when I look there for the definition of a mirroring
>> context, it doesn't exists.
>
>Section 6 was removed.
>
>
>>
>> 3) The following Informative references expired several years ago and -
>> being individual drafts - do not appear to convey the SPRING or TEAS WG
>> consensus.
>> a)  draft-filsfils-spring-segment-routing-ldp-interop-03 was
>> replaced with draft-ietf-spring-segment-routing-ldp-interop-07 and there
>> are considerable differences.
>
>fixed
>
>> b) It is unclear what happened
>> to draft-filsfils-spring-segment-routing-use-cases-01, but I do not see
>> any successor - or reason for this individual draft to explain the
>> OSPFv2 extensions more than work from the SPRING WG.
>
>I replaced it with RFC7855.
>
>>
>> 4) Sec 3.3: Is it ok to advertise an SRLB TLV without advertising the
>> SR-Algorithm TLV?  What is the expected behavior and assumptions by the
>> receiver?
>
>These are independent TLVs. Both are optional and there is no dependency
>between them.
>
>>
>> 5) Sec 3.4:  What happens if an SRMS Preference TLV is advertised
>> without an SR-Algorithm TLV in the same scope?
>
>SRMS Preference TLV is independent of the SR-Algorithm TLV.
>
>The fact that SRMS provides 

[OSPF] IETF 99 - OSPF WG Call for Agenda Items

[Acee Lindem (acee)]

We are fast approaching IETF 99 in Prague and are now formulating the OSPF WG 
agenda. The IETF agenda (still preliminary) is available at:
https://datatracker.ietf.org/meeting/99/agenda.html

The OSPF WG session (2h) is scheduled on
Tuesday, July 18, 2017 / Afternoon session I / 13:30-15:30 (local time)

Please send us your request for a presentation slot, indicating
draft name, speaker, and desired duration (covering presentation and
discussion).

Thanks,
Acee & Abhay

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

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

On 6/20/17, 1:50 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com> wrote:

>
>> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) <a...@cisco.com> wrote:
>> 
>> Hi Jeff, 
>> 
>> On 6/20/17, 10:58 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote:
>> 
>>> Les,
>>> 
>>> On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg)
>>>wrote:
>>>>> Different protocols have different survivability requirements.  An
>>>> IGP may
>>>>> very well want sub-second timers, potentially for repair behaviors.
>>>> BGP may
>>>>> want fast failover, but may be fine with second level granularity.
>>>> This is
>>>>> particularly true since the cost of too aggressively flapping BGP is
>>>> of
>>>>> significantly greater impact to the network and the router.
>>>>> 
>>>> [Les:] The real issues here are false failures and proper use of
>>>> dampening. No protocol - not even an IGP - wants to flap
>>>>unnecessarily.
>>>> If timers are set so aggressively that false failures are reported
>>>>this
>>>> is BAD.
>>>> Even worse is failure to dampen so that we get multiple false failures
>>>> in a short period of time.
>>>> 
>>>> Arguing that the right way to solve this problem is to increase the
>>>> number of sessions using different timer granularity seems likely to
>>>> make any problems worse as you have now increased the number of BFD
>>>> sessions with the associated costs.
>>> 
>>> I'm mildly amused you seem to think I'm not considering the cost of
>>> additional sessions in the scaling matrix. :-)
>>> 
>>> I do think you're conflating the survivability requirements vs. timer
>>> granularity.  However, I agree that the most commonly deployed form is
>>>to
>>> go
>>> for single session with the most stable aggressive timer.
>>> 
>>> Again, the reason I raise this is there has been discussion regarding
>>> behavior for different client timing requirements.  There are a few
>>> options
>>> for how this is likely to play out in terms of BFD protocol
>>> implementation.
>>> However, configuration and operational models tend to evolve much more
>>> slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>>> prodding
>>> at this space a bit to attempt to do some future proofing.
>>> 
>>> As we noted earlier in thread, this likely at least encourages
>>> configuration
>>> to be multi-instanced, even if the session instantiation is not
>>>currently.
>>> Key changes aren't something we can readily do, so getting that part
>>>right
>>> early is necessary.
>>> 
>>> The likely impact on current IGP module BFD configuration may be a
>>>later
>>> augmentation.  Thus, as long as the likely implications are understood,
>>> there may be no further action needed at this time.  Determining that
>>>is
>>> partially what this thread is attempting to shake out.
>> 
>> In the IGPs, we have a separate BFD container in the interface
>> configuration. Currently, it only contains the a boolean. This could
>> easily be augmented to reference the appropriate construct in the BFD
>> model. 
>
>Let me work with Reshad to suggest what IGP could suggest to BFD in their
>construct, and have BFP pick what it believes would be the right set of
>parameters to be able to support most of the IGPs over the given BFD
>session. Whether we add it in the current model or add it later as an
>augmentation could then be decided separately.

Given that the IGP models are more mature and will soon be ready for
publication, I think it is a given that this will be done in an
augmentation. 

Thanks,
Acee 


>
>> 
>> Thanks,
>> Acee 
>> 
>> 
>>> 
>>> -- Jeff
>> 
>
>Mahesh Jethanandani
>mjethanand...@gmail.com
>

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

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Acee Lindem (acee)]

Hi Jeff, 

On 6/20/17, 10:58 AM, "Jeffrey Haas"  wrote:

>Les,
>
>On Tue, Jun 20, 2017 at 02:25:12PM +, Les Ginsberg (ginsberg) wrote:
>> > Different protocols have different survivability requirements.  An
>>IGP may
>> > very well want sub-second timers, potentially for repair behaviors.
>>BGP may
>> > want fast failover, but may be fine with second level granularity.
>>This is
>> > particularly true since the cost of too aggressively flapping BGP is
>>of
>> > significantly greater impact to the network and the router.
>> > 
>> [Les:] The real issues here are false failures and proper use of
>>dampening. No protocol - not even an IGP - wants to flap unnecessarily.
>>If timers are set so aggressively that false failures are reported this
>>is BAD.
>> Even worse is failure to dampen so that we get multiple false failures
>>in a short period of time.
>> 
>> Arguing that the right way to solve this problem is to increase the
>>number of sessions using different timer granularity seems likely to
>>make any problems worse as you have now increased the number of BFD
>>sessions with the associated costs.
>
>I'm mildly amused you seem to think I'm not considering the cost of
>additional sessions in the scaling matrix. :-)
>
>I do think you're conflating the survivability requirements vs. timer
>granularity.  However, I agree that the most commonly deployed form is to
>go
>for single session with the most stable aggressive timer.
>
>Again, the reason I raise this is there has been discussion regarding
>behavior for different client timing requirements.  There are a few
>options
>for how this is likely to play out in terms of BFD protocol
>implementation.
>However, configuration and operational models tend to evolve much more
>slowly.  (And I certainly don't need to tell you that.)  Thus, I'm
>prodding
>at this space a bit to attempt to do some future proofing.
>
>As we noted earlier in thread, this likely at least encourages
>configuration
>to be multi-instanced, even if the session instantiation is not currently.
>Key changes aren't something we can readily do, so getting that part right
>early is necessary.
>
>The likely impact on current IGP module BFD configuration may be a later
>augmentation.  Thus, as long as the likely implications are understood,
>there may be no further action needed at this time.  Determining that is
>partially what this thread is attempting to shake out.

In the IGPs, we have a separate BFD container in the interface
configuration. Currently, it only contains the a boolean. This could
easily be augmented to reference the appropriate construct in the BFD
model. 

Thanks,
Acee 


>
>-- Jeff

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