Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

2020-12-02 Thread Acee Lindem (acee)
Speaking as WG member:

I have read this draft and support adoption.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, December 1, 2020 at 4:13 PM
To: lsr 
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

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


[Lsr] IPR Poll for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

2020-12-01 Thread Acee Lindem (acee)
Authors,

Are you aware of any IPR that applies to draft-bonica-lsr-ip-flexalgo-01?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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


[Lsr] IRP Poll for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01 (Resent with Corrected Subject)

2020-12-01 Thread Acee Lindem (acee)
Chris,

Are you aware of any IPR that applies to 
draft-ietf-lsr-yang-isis-reverse-metric-01?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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


Re: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

2020-12-01 Thread Acee Lindem (acee)
Speaking as a WG member, I support publication of the draft.
Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Monday, November 30, 2020 at 1:15 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse 
Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee

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


[Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

2020-12-01 Thread Acee Lindem (acee)
This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee

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


Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / MLAG hash

2020-11-30 Thread Acee Lindem (acee)
There is nothing in OSPF or IS-IS protocols related to the ECMP load-balancing 
with respect to the flow label. RFC 6437 is an IPv6 WG (predecessor of 6MAN) 
document. Are you just trying to torment me 

Acee

From: Gyan Mishra 
Date: Monday, November 30, 2020 at 4:23 PM
To: Acee Lindem 
Cc: lsr 
Subject: Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / 
MLAG hash

Hi Acee

6MAN deals with the IPv6 protocol specifications and not routing protocols in 
the ECMP load balancing framework.

6MAN would not have any idea if ISIS or OSPF AFI IPv6 5-tuple ECMP load 
balancing is supported and industry direction to support this critical feature 
from a IGP perspective.

This question posed is in the context of LSR IGP load balancing framework, OSPF 
& ISIS  AFI IPv6 use of RFC 6437 for 5-tuple hash ECMP load balancing for even 
50/50 load balancing hash as opposed to router default flow or session based 
load balancing.

Any feedback related in this context is  much appreciated.

Kind Regards

Gyan

On Mon, Nov 30, 2020 at 3:39 PM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Speaking as LSR Co-Chair:

Hi Gyan,
This is more a discussion for the 6MAN WG. Here is the charter for the LSR WG: 
https://datatracker.ietf.org/wg/lsr/about/
No need to cross-post to the LSR list…
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gyan 
Mishra mailto:hayabusa...@gmail.com>>
Date: Monday, November 30, 2020 at 3:22 PM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / 
MLAG hash


Dear LSR WG experts,


Does anyone know if vendors have started or plan to start supporting IPv6 flow 
label 5-tuple dscp marking for ECMP hashing.

IPv6 flow label support for ECMP

https://tools.ietf.org/html/rfc6437

IPv4 has traditionally always utilized recommended BCP of flow based load 
balancing due to issues related to out of order and reordering of packets.  
Although per packet load balancing is supported by most vendors it is not 
recommended due to forwarding plane impact.

This IPv6 flow label feature of 5-tuple hash provides significant advantages 
for operators much needed ECMP load balancing entropy as compare to traditional 
“flow or session” based load balancing which is the case as well with MPLS 
entropy label RFC 6790 load balancing contrasted below.

IPv6 flow label has significant  benefits for operators deploying  SRv6 which 
utilizes the IPv6 data plane to now have “native” built in ECMP entropy as part 
of the protocol as compare to its predecessor IPv4.

This gives SRv6 another significant edge over MPLS predecessor.

Excerpt from RFC 6437:


  Forwarding nodes such as routers and load distributors MUST NOT

  depend only on Flow Label values being uniformly distributed.  In

  any usage such as a hash key for load distribution, the Flow Label

  bits MUST be combined at least with bits from other sources within

  the packet, so as to produce a constant hash value for each flow

  and a suitable distribution of hash values across flows.

  Typically, the other fields used will be some or all components of

  the usual 5-tuple.  In this way, load distribution will still

  occur even if the Flow Label values are poorly distributed.



   Although uniformly distributed flow label values are recommended

   below, and will always be helpful for load distribution, it is unsafe

   to assume their presence in the general case, and the use case needs

   to work even if the flow label value is zero.



   As a general practice, packet flows should not be reordered, and the

   use of the Flow Label field does not affect this.  In particular, a

   Flow label value of zero does not imply that reordering is

   acceptable.





Below comparison of IPv6 flow label benefits over MPLS entropy label:





! MPLS Entropy label

https://tools.ietf.org/html/rfc6790







As a comparison to MPLS entropy label, the mpls entropy label reduces the 
control plane label binding and LFIB forwarding plane data structure by not 
having a per ECMP path label allocation per FEC by adding an additional entropy 
label to the label stack.





However MPLS entropy label is still uses the traditional flow or session based 
load balancing algorithm which results in

uneven load balancing.





Kind Regards



Gyan



--

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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


Re: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / MLAG hash

2020-11-30 Thread Acee Lindem (acee)
Speaking as LSR Co-Chair:

Hi Gyan,
This is more a discussion for the 6MAN WG. Here is the charter for the LSR WG: 
https://datatracker.ietf.org/wg/lsr/about/
No need to cross-post to the LSR list…
Thanks,
Acee

From: Lsr  on behalf of Gyan Mishra 

Date: Monday, November 30, 2020 at 3:22 PM
To: lsr 
Subject: [Lsr] IPv6 Flow Label QOS marking support for 5-tuple ECMP / LAG / 
MLAG hash


Dear LSR WG experts,


Does anyone know if vendors have started or plan to start supporting IPv6 flow 
label 5-tuple dscp marking for ECMP hashing.

IPv6 flow label support for ECMP

https://tools.ietf.org/html/rfc6437

IPv4 has traditionally always utilized recommended BCP of flow based load 
balancing due to issues related to out of order and reordering of packets.  
Although per packet load balancing is supported by most vendors it is not 
recommended due to forwarding plane impact.

This IPv6 flow label feature of 5-tuple hash provides significant advantages 
for operators much needed ECMP load balancing entropy as compare to traditional 
“flow or session” based load balancing which is the case as well with MPLS 
entropy label RFC 6790 load balancing contrasted below.

IPv6 flow label has significant  benefits for operators deploying  SRv6 which 
utilizes the IPv6 data plane to now have “native” built in ECMP entropy as part 
of the protocol as compare to its predecessor IPv4.

This gives SRv6 another significant edge over MPLS predecessor.

Excerpt from RFC 6437:


  Forwarding nodes such as routers and load distributors MUST NOT

  depend only on Flow Label values being uniformly distributed.  In

  any usage such as a hash key for load distribution, the Flow Label

  bits MUST be combined at least with bits from other sources within

  the packet, so as to produce a constant hash value for each flow

  and a suitable distribution of hash values across flows.

  Typically, the other fields used will be some or all components of

  the usual 5-tuple.  In this way, load distribution will still

  occur even if the Flow Label values are poorly distributed.



   Although uniformly distributed flow label values are recommended

   below, and will always be helpful for load distribution, it is unsafe

   to assume their presence in the general case, and the use case needs

   to work even if the flow label value is zero.



   As a general practice, packet flows should not be reordered, and the

   use of the Flow Label field does not affect this.  In particular, a

   Flow label value of zero does not imply that reordering is

   acceptable.





Below comparison of IPv6 flow label benefits over MPLS entropy label:





! MPLS Entropy label

https://tools.ietf.org/html/rfc6790







As a comparison to MPLS entropy label, the mpls entropy label reduces the 
control plane label binding and LFIB forwarding plane data structure by not 
having a per ECMP path label allocation per FEC by adding an additional entropy 
label to the label stack.





However MPLS entropy label is still uses the traditional flow or session based 
load balancing algorithm which results in

uneven load balancing.





Kind Regards



Gyan



--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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


[Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

2020-11-30 Thread Acee Lindem (acee)
Authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-yang-isis-reverse-metric-01?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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


[Lsr] Working Group Last Call for "YANG Module for IS-IS Reverse Metric" - draft-ietf-lsr-yang-isis-reverse-metric-01

2020-11-30 Thread Acee Lindem (acee)
As stated as the IETF 109 LSR WG meeting, we feel the IS-IS reverse metric 
augmentation is ready for publication. This begins a two week last call for the 
subject draft. Please indicate your support or objection on this list prior to 
12:00 AM UTC on December 15th, 2020. Also, review comments are certainly 
welcome.
Thanks,
Acee

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


Re: [Lsr] Link Data value for Multi-area links

2020-11-30 Thread Acee Lindem (acee)
Speaking on WG member:

Hi Alex,
I knew this was coming. In 2008, 99.9% of the requirements were handled by 
supporting an interface in a primary area and one other area. Using the remote 
IP address for the other area does handle this case. As I stated previously, if 
you support OSPF adjacencies on secondary IP addresses, the MIB and other 
complexities are all taken care of and that would be the solution that I would 
recommend. However, if you guys want to spend time trying to improve RFC5185, 
you are perfectly welcome to submit a draft.

Thanks,
Acee

From: Alexander Okonnikov 
Date: Monday, November 30, 2020 at 12:47 PM
To: Gunter Van de Velde 
Cc: Acee Lindem , "Peter Psenak (ppsenak)" , 
"lsr@ietf.org" 
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Acee,

RFC 5185 says that interface data structure is created for each multi-area 
adjacency. I guess that we are not allowed to allocate several ifIndex values 
for the same IP interface, because it is property of router's interface, not 
OSPF interface. Hence, we have several OSPF interfaces with the same ifIndex in 
unnumbered case and, thus, ambiguity in Interface table. The same for numbered 
- we have IP interface address (one), which is the same for multiple OSPF 
interfaces, and we again obtain ambiguity. Per my understanding advertising 
neighbor's IP address (or ifIndex) in Link Data doesn't help here.


30 нояб. 2020 г., в 20:20, Van De Velde, Gunter (Nokia - BE/Antwerp) 
mailto:gunter.van_de_ve...@nokia.com>> 
написал(а):

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.   we must first look if the there is a stub type 3 link

2.   If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.   If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.   If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.   = over-complex. (If we used  for RFC5185 ‘Link Data = local ip 
address’ then (2) would given answer directly)

In addition, for a router it is much simpler to learn and advertise 
local-ip-address in Router LSAs then using a remote-ip-address.
I also believe that if we want to search something in TEDB after receiving a TE 
Link TLV. How can we identify from the TE Link TLV if multi-area or not 
multi-area? If we can not, then how can we create the correct key?

Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
Data seems not the best design that we can do, and is adding OSPF complexity 
without benefits.

Should this not be corrected in RFC5185 and simply use local-ip-address instead 
of the remote-ip-address for Multi-area Link Data and avoid the additional 
unnecessary complexity the current RFC for numbered links?

Brgds,
G/


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>; Peter 
Psenak (ppsenak) mailto:ppse...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX   OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF interface entry describes one interface
  from the viewpoint of OSPF.

  Information in this table is persistent and when this object
  is written the entity SHOULD save the change to non-volatile
  storage."
   INDEX { ospfIfIpAddress

Re: [Lsr] Link Data value for Multi-area links

2020-11-30 Thread Acee Lindem (acee)
You are welcome to propose an alternate solution which could possibly be 
accepted as a BIS document. However, this is not something that can be simply 
changed in an Errata to reduce the complexity.
Thanks,
Acee

From: Lsr  on behalf of Gunter Van de Velde 

Date: Monday, November 30, 2020 at 12:21 PM
To: "Acee Lindem (acee)" , Alexander Okonnikov 
, "Peter Psenak (ppsenak)" 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] Link Data value for Multi-area links

The oddnes is that the architecture decision in RFC5185 to select 
remote-ip-address instead of local-ip-address for the ‘Link Data’ is making 
things much more complicated.
I am surprised to see that using the remote-ip-address is seen as the ‘better’ 
choice as selecting local-ip-address. To me it seems as a worse choice.

A question that was asked: How router will be able to match Link TLV (RFC 3630) 
to corresponding Link in Router LSA?

Answer:
For unnumbered links we can match Link TLV with Router TLV using the IfIndex 
when there is no stub type 3 link (=easy)
For numbered:

1.   we must first look if the there is a stub type 3 link

2.   If stub type 3 exists, then the RFC3630 local ip address must be used 
to identify the correspond link within the router TLV to the neighbor

3.   If the stub type 3 link did not exist in Router TLV link, then the 
maybe the link is unnumbered, and we try to match upon IfIndex… This may give a 
match or no match

4.   If there is no match, then maybe the link is MADJ and we must use the 
RFC3630 remote IP address to match upon the Link Data

5.   = over-complex. (If we used  for RFC5185 ‘Link Data = local ip 
address’ then (2) would given answer directly)

In addition, for a router it is much simpler to learn and advertise 
local-ip-address in Router LSAs then using a remote-ip-address.
I also believe that if we want to search something in TEDB after receiving a TE 
Link TLV. How can we identify from the TE Link TLV if multi-area or not 
multi-area? If we can not, then how can we create the correct key?

Looking at the above, the choice of using remote-ip-address for RFC5185 Link 
Data seems not the best design that we can do, and is adding OSPF complexity 
without benefits.

Should this not be corrected in RFC5185 and simply use local-ip-address instead 
of the remote-ip-address for Multi-area Link Data and avoid the additional 
unnecessary complexity the current RFC for numbered links?

Brgds,
G/


From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, November 30, 2020 18:01
To: Alexander Okonnikov ; Peter Psenak (ppsenak) 

Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX   OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF interface entry describes one interface
  from the viewpoint of OSPF.

  Information in this table is persistent and when this object
  is written the entity SHOULD save the change to non-volatile
  storage."
   INDEX { ospfIfIpAddress, ospfAddressLessIf }
   ::= { ospfIfTable 1 }

Note that if you really want to support this optimally, you could use a 
separate subnet pre-area and have adjacencies on secondary addresses. My 
Redback/Ericsson implementation allowed for this.

Thanks,
Acee


From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Alexander Okonnikov 
mailto:alexander.okonni...@gmail.com>>
Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" mailto:ppse...@cisco.com>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Peter,

30 нояб. 2020 г., в 12:56, Peter Psenak 
mailto:ppse...@cisco.com>> написал(а):

Hi Alex,

On 27/11/2020 13:49, Alexander Okonnikov wrote:
Hi Peter,
Which kind of ambiguity is meant? In case of numbered point-to-point each link 
has its own unique IP address, so there is no ambiguity.
Per my understanding this problem has appeared due to follow reasons:
1) In old versions of the draft (up to -05) it was proposed that multi-area 
links are treated as unnumbered. ifIndex to be encoded in Link Data field, 
irrespectively whether interface

Re: [Lsr] Link Data value for Multi-area links

2020-11-30 Thread Acee Lindem (acee)
Hi Alex,

Multi-Area interface disambiguation is required to support the OSPF MIB as 
specified in RFC 4750. The table indexing doesn’t include the area. For example:

--  OSPF Interface Table

  ospfIfTable OBJECT-TYPE
   SYNTAX   SEQUENCE OF OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF Interface Table describes the interfaces
  from the viewpoint of OSPF.
  It augments the ipAddrTable with OSPF specific information."
   REFERENCE
  "OSPF Version 2, Appendix C.3  Router interface
  parameters"
   ::= { ospf 7 }

  ospfIfEntry OBJECT-TYPE
   SYNTAX   OspfIfEntry
   MAX-ACCESS   not-accessible
   STATUS   current
   DESCRIPTION
  "The OSPF interface entry describes one interface
  from the viewpoint of OSPF.

  Information in this table is persistent and when this object
  is written the entity SHOULD save the change to non-volatile
  storage."
   INDEX { ospfIfIpAddress, ospfAddressLessIf }
   ::= { ospfIfTable 1 }

Note that if you really want to support this optimally, you could use a 
separate subnet pre-area and have adjacencies on secondary addresses. My 
Redback/Ericsson implementation allowed for this.

Thanks,
Acee


From: Lsr  on behalf of Alexander Okonnikov 

Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Peter,


30 нояб. 2020 г., в 12:56, Peter Psenak 
mailto:ppse...@cisco.com>> написал(а):

Hi Alex,

On 27/11/2020 13:49, Alexander Okonnikov wrote:

Hi Peter,
Which kind of ambiguity is meant? In case of numbered point-to-point each link 
has its own unique IP address, so there is no ambiguity.
Per my understanding this problem has appeared due to follow reasons:
1) In old versions of the draft (up to -05) it was proposed that multi-area 
links are treated as unnumbered. ifIndex to be encoded in Link Data field, 
irrespectively whether interface has its own IP address (numbered) or borrow it 
(unnumbered);
2) From -06 to -08 multi-area links are still treated as unnumbered, but if 
interface is numbered, then IP address of the neighbor (rather than local one) 
to be encoded into Link Data, in order to make the link look like unnumbered;
3) In version -09 of the draft and in RFC 5185 itself there is no more mentions 
that multi-area link to be treated as unnumbered. Rather, another approach is 
used - if router's interface is numbered, then link is also numbered; if 
router's interface is unnumbered, then link is unnumbered. The rule that 
specifies omitting corresponding type 3 link is added. Mention of 'unnumbered' 
link is also removed from section 3 in RFC 5185. >
Hence, in version -09 with removing unnumbered nature of multi-area links Link 
Data for numbered links had to be changed from Neighbor's IP address to own IP 
address, as it is specified in RFC 2328. From perspective of other routers this 
link can be treated as numbered or unnumbered, depending on configuration of 
neighbor's corresponding interface.

you are free to advertise the link as unnumbered. RFC5185 is not mandating to 
send IP address really.

The same valid for numbered ones. I.e. I'm free to advertise the link as 
numbered. This is straightforward when the link is numbered indeed. And if we 
would prefer to have deal with unnumbered interfaces, we would not need RFC 
5185 (section 1.2).


One question - how neighboring router will perform next-hop calculation (in 
case it needs to do so)? If neighbor is configured with numbered interface, it 
will treat Link Data as IP next hop, which will be its own IP interface address.
Another question - how router will be able to match Link TLV (RFC 3630) to 
corresponding Link in Router LSA? For example, we want to calculate RSVP-TE LSP 
based on IGP metric (RFC 3785) and thus router needs to match IGP link to TE 
link.

I don't believe you are going to do any traffic engineering over a multi-area 
adjacency. MADJ is there to address the OSPF route preference rules that may 
lead to sub-optimal routing. MADJ link is not advertised for TE purposes.

Why not? We need multi-area configuration and at the same time we need ability 
to build intra-area RSVP-TE LSPs within each of areas. And what about 
calculating IP next hop? Which compatibility is meant in section 3?

thanks,
Peter

Thank you.


Thank you.

27 нояб. 2020 г., в 14:50, Peter Psenak 
mailto:ppse...@cisco.com>> написал(а):

Alexander,

On 26/11/2020 17:58, Alexander Okonnikov wrote:

Hi WG,
RFC 5185 says that Neighbor's IP address to be encoded into Link Data field. 
Per RFC 2328 router's own IP address to be encoded into Link Data. What is the 
reason to advertise neighbor's IP address for multi-area links and not local IP 
address? It seems like bug. Could someone comment on this?

Advertising a neighbor address/ifindex helps to 

Re: [Lsr] IETF I09 LSR Meeting Minutes

2020-11-23 Thread Acee Lindem (acee)
Thanks Jie – fixed.
Acee

From: Jie Dong 
Date: Monday, November 23, 2020 at 4:59 AM
To: Acee Lindem , "lsr@ietf.org" 
Subject: RE: [Lsr] IETF I09 LSR Meeting Minutes

Hi Acee,

One small nit about the minutes for the first topic:

Peter: I commented earlier. The way the total constaints are being
   used. Basically a bundle must advertise the summary of all
   the included affinities of the individual members, can't
   use an exclude or combined exclude was included because
   that would break. So, if this is what the author had planned
   to do then the restriction should be clearly described
   in the draft.

I guess “can’t use an exclude or combined exclude was included” should be 
“can’t use an exclude or combined exclude with include”.

Hope this helps.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, November 20, 2020 6:17 AM
To: lsr@ietf.org
Subject: [Lsr] IETF I09 LSR Meeting Minutes

I have uploaded the minutes for the meeting on Monday morning. Thanks much to 
Yingzhen Qu for taking them. Please send me any additions or corrections to me.

https://datatracker.ietf.org/doc/minutes-109-lsr/

Presenters and draft authors, please note that if more discussion is need on 
your draft then it is up to you to initiate such discussion.

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


Re: [Lsr] Early Allocation for IS-IS TTZ

2020-11-20 Thread Acee Lindem (acee)
Les,
Thanks for coordinating the experts and getting this done.
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Friday, November 20, 2020 at 1:50 PM
To: "Les Ginsberg (ginsberg)" , Acee 
Lindem , Huaimo Chen , Christian 
Hopps , Hannes Gredler 
Cc: "lsr@ietf.org" , Alvaro Retana 
Subject: RE: Early Allocation for IS-IS TTZ

FYI –

This has been approved by the DEs and IANA has updated the registry.

   Les



From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ

Request noted.

Chris/Hannes/myself will discuss and get back to you.

   Les

From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ

+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] Responses for comments on "passive interface attribute" draft

2020-11-19 Thread Acee Lindem (acee)
Speaking as WG member and updating subject:

Hi Aijun,

We’re not going to add stub links back into Router-LSAs under any circumstance 
since that was an advantage of OSPFv3 over OSPFv2 (refer to section 2.8 of RFC 
5340). Additionally, we’re going to be careful as to what information we put 
into the topological LSAs.

With respect to your specific use case, you haven’t disclosed it other than 
you’re making some loose inference based on an interface being a passive 
interface  (which isn’t a standardized IGP concept). Rather, you should 
precisely design your use case and then we can talk about a solution.

Thanks,
Acee

From: Aijun Wang 
Date: Thursday, November 19, 2020 at 10:06 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: RE: [Lsr] IETF I09 LSR Meeting Minutes(Responses for comments on 
"passive interface attribute" draft)

HI, Acee:

Thanks for the minutes, and also thanks for Yingzhen.

Below are the responses for the comments regarding to 
draft-wang-lsr-passive-interface-attribute-06<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06>,
 please see whether they address your concern or not.
For simplicity, I just summary the key points of the comments.
【Chris】: Why not using the existed TLV to solve the Inter-as use case?
【Reply-from Aijun Wang】: For inter-AS use case, using the existed TLV has the 
constraints that described in 
https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/

【Chris】: Why not using prefix attributes to advertise application server’s 
information?
【Reply-from Aijun Wang】: It is possible to advertise these information together 
with prefix. But when we want to describe the resources(for example, link 
bandwidth, link utilization ratio etc.) to the prefix, it is more reasonable to 
associated them to link attributes.

On summary, considering the above two use case has the common characteristic, 
that is, the associated link is stub-link, we think that defines the stub-link 
TLV to contain the these information  is more extensible.

【Acee】: Why not just advertise the link is the inter-AS boundary or other , and 
doesn’t need to infer this conclusion?
【Reply-from Aijun Wang】: If necessary, we can add one flag field to indicate 
clearly the sub-type of the stub-link. But currently, they are all 
passive-interface, has no other distinguished differences.
The usage of such information, or the inferences method, may be different in 
different scenario. I think the standardization work should defines the 
fundamental common parts.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Friday, November 20, 2020 6:17 AM
To: lsr@ietf.org
Subject: [Lsr] IETF I09 LSR Meeting Minutes

I have uploaded the minutes for the meeting on Monday morning. Thanks much to 
Yingzhen Qu for taking them. Please send me any additions or corrections to me.

https://datatracker.ietf.org/doc/minutes-109-lsr/

Presenters and draft authors, please note that if more discussion is need on 
your draft then it is up to you to initiate such discussion.

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


[Lsr] IETF I09 LSR Meeting Minutes

2020-11-19 Thread Acee Lindem (acee)
I have uploaded the minutes for the meeting on Monday morning. Thanks much to 
Yingzhen Qu for taking them. Please send me any additions or corrections to me.

https://datatracker.ietf.org/doc/minutes-109-lsr/

Presenters and draft authors, please note that if more discussion is need on 
your draft then it is up to you to initiate such discussion.

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


Re: [Lsr] Early Allocation for IS-IS TTZ

2020-11-18 Thread Acee Lindem (acee)
+LSR list and Alvaro for information.

I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).

Thanks,
Acee

From: Huaimo Chen 
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem , Christian Hopps 
Subject: Early Allocation for IS-IS TTZ

Hi Acee and Chris,

We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/

 28 (suggested) - IS-IS Zone ID TLV

Thank you very much for your consideration.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-18 Thread Acee Lindem (acee)
Speaking as WG Co-Chair:

From: Aijun Wang 
Date: Wednesday, November 18, 2020 at 3:05 AM
To: Robert Raszuk , Jeff Tantsura 
Cc: 'Gyan Mishra' , Acee Lindem , 'lsr' 
, "'Acee Lindem (acee)'" 
Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases

Hi, Robert:

The trigger and propagation of PUA info can be standardized, the actions based 
on the PUA can be different in different situation.
We can discuss and describe the actions based on different scenarios after its 
WG adoption?

There will be no adoption call until there is a coherent draft with use case(s) 
and viable actions.

Thanks,
Acee


Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk 
Sent: Wednesday, November 18, 2020 3:49 PM
To: Jeff Tantsura 
Cc: Gyan Mishra ; Acee Lindem (acee) ; 
lsr ; Aijun Wang ; Acee Lindem (acee) 

Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff,

Please notice that WAN is not an IX.

While you can have full mesh of BFD sessions among all IXP participants each 
bombarding each over over TB fabric every 100 ms or so to map the same over 
global WAN is a different game. If nothing else RTT between IXP participants in 
healthy IX is around 1 ms while RTT between PEs distributed globally is often 
100-200 ms.

Just imagine 1000 PEs in 10 areas distributed all over the world. That means 
that in worst case scenario (say same mgmt VPN present on each PE) you will 
establish 1000*999 BFD sessions. Now for this to make sense timer needs to be 
100 ms or so with 3x or 5x multiplier. Anything slower will defeat the purpose 
as BGP withdraw will be faster.

Then we go into queuing issues. If BFD packets are queued at any interface 
meltdowns may occur which can be far worse in consequences then waiting for BGP 
service route removal. Such meltdowns often result in cascading effects to the 
applications itself.

So this is not at all about autodiscovery with which address to setup the BFD 
session. It is much more about operational aspects of going that direction.

With that I am supportive of this work even if we label it as experimental for 
some time. As each network is different what is optimal solution for one design 
and deployment may not be optimal for the other.

Many thx,
Robert


On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura 
mailto:jefftant.i...@gmail.com>> wrote:
We have been discussing for quite some time and in different wg's (there’s IX 
with RS use case) BFD verification based on next-hop extraction, Robert - you 
should know. (also built a well working prototype in previous life).

Very simple logic:

Upon route import (BGP update received and imported), extract next-hop, walk 
BFD session table, if no match (no existing session) - establish (S)BFD session 
(Discriminators distribution is a solved problem) to the next-hop, associate 
fate of all routes received from it, keep timers reasonable to prevent false 
positives.

State is limited to PE’s importing each others routes (sharing a service) only
High degree of automation
No IGP pollution

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) 
mailto:a...@cisco.com>>, wrote:


Speaking as WG member:

I think it would be good to hone in on the BGP PE failure convergence use case 
as suggested by Robert. It seems there is some interest here although I’m not 
convinced the IGP is the right place to solve this problem.

Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gyan 
Mishra mailto:hayabusa...@gmail.com>>
Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: lsr mailto:lsr@ietf.org>>, Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>, Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>, "Acee Lindem 
(acee)" mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases



On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:


   Robert, I believe the original intention was related to having the data 
plane converge quickly when summarization is used and flip so traffic converges 
from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both 
ABRs will get the same info. As mentioned before there is no practical use of 
PUA for making any routing or fwd decision on which ABR to use. If your ABRs 
are not connected with min redundancy this draft is a worst patch ever to work 
around such a design.

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track the 
component prefixes and in case where component is down and traffic is still 
forwarded to the ABR and dropped.  The other more important use case is when 
links are down within the area and the area is partitioned and so one ABR has 
all component prefixes however other ABR is missing half the component 
prefixes.  So since the ABR will by default advertise the summary as long as 
their is one com

Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

2020-11-17 Thread Acee Lindem (acee)


From: Aijun Wang 
Date: Tuesday, November 17, 2020 at 9:27 PM
To: Acee Lindem 
Cc: 'lsr' 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt


Hi, Acee:



-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, November 18, 2020 2:47 AM
To: Aijun Wang 
Cc: 'lsr' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-passive-interface-attribute-06.txt



Speaking as WG member and longtime steward  of the IGPs:



Hi Aijun,



My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs.

[WAJ] Putting the information in other regular TLVs, or putting them in LSA of 
one independent IGP instance(as you proposed in 109 meeting) will be more 
expensive. Do you agree this statement?



No – bloating the primary LSAs with non-routing information will be more 
expensive due to the dynamics of LSA origination and route computation.



Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

[WAJ] Passive Interfaces are already deployed within the network in many 
places, as stated in the 
draft-wang-lsr-passive-interface-attribute-06#section-1<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06#section-1>.
 What we want to know, is the position of passive interface. Previously, we 
want piggyback such information within its associated prefix, but after 
discussion on the mail list, define one new TLV to contain it and other future 
information may be more acceptable and extensible.



And how do identify and even define the position of the passive interface? As I 
stated previously, passive interfaces are not standardized.



Knowing these information, the controller can learn the inter-as links via some 
methods that we have discussed in another thread, can know the boundary of 
network, can learn the link characteristic that associated with server etc. We 
have also mentioned it in the 
draft-wang-lsr-passive-interface-attribute-06#section-1<https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-06#section-1>
 and think it is not appropriate to expand it intensely in one LSR draft.



I disagree. Precisely define your use case.



Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc).

[WAJ] In your 109 meeting presentation 
slides-109-lsr-5-ospf-transport-instance-00<https://datatracker.ietf.org/meeting/109/materials/slides-109-lsr-5-ospf-transport-instance-00>,
 you mentioned also the similar information that should be transferred via the 
OSPF protocol. I think this is the direction and we can prepare for it in 
advance. Putting such non-routing information in one independent TLV can 
certainly keep the stability of IGP protocol.



This was just an example of something that could be offloaded to a separate 
instance in the slides. It is not a specification.



Thanks,

Acee







Thanks,

Acee



On 11/17/20, 1:08 AM, "wang...@chinatelecom.cn on behalf of Aijun 
Wang<mailto:wang...@chinatelecom.cn%20on%20behalf%20of%20Aijun%20Wang>" 
mailto:wang...@chinatelecom.cn>> wrote:



Hi, Acee:



As discussed on the list and during the 109 meeting, we have updated the 
draft to reflect the comments from the LSR community.

Please see whether you have still other concerns or not and if there is no 
further comments on this direction, can we begin the WG adoption call then?

Thanks you and Peter for your intense discussions for this draft.



Thanks in advance.



Best Regards



Aijun Wang

China Telecom



> -Original Message-

> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>

> Sent: Sunday, November 15, 2020 7:44 AM

> To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang

> mailto:wang...@chinatelecom.cn>>; Gyan S. Mishra 
mailto:gyan.s.mis...@verizon.com>>;

> Gyan Mishra mailto:gyan.s.mis...@verizon.com>>

> Subject: New Version Notification for

> draft-wang-lsr-passive-interface-attribute-06.txt

>

>

> A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt

> has been successfully submitted by Aijun Wang and posted to the IETF

> repository.

>

> Name:   draft-wang-lsr-passive-interface-attr

Re: [Lsr] New Version Notification for draft-wang-lsr-passive-interface-attribute-06.txt

2020-11-17 Thread Acee Lindem (acee)
Speaking as WG member and longtime steward  of the IGPs:

Hi Aijun, 

My opinion is that we should not overload the base IGP topology advertisements 
with everyone's favorite obscure use case. Hence, I think it would be a big 
mistake to add this stub link TLV to the base LSAs. 

Rather, exactly what problem are you trying to solve? Previously, you were 
trying to associate the passive interface attribute with a prefix and making 
some inference related to an inter-AS boundary (this was not entirely clear). 
What problem are you trying to solve? Precisely, what do you want the 
controller to learn (i.e., address or interface index) and what is it going to 
do with it.

Please don't try and solve the CFN problem as the requirements are not clear 
(anycast, unicast, impact on routing, scope, etc). 

Thanks,
Acee

On 11/17/20, 1:08 AM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:

As discussed on the list and during the 109 meeting, we have updated the 
draft to reflect the comments from the LSR community.
Please see whether you have still other concerns or not and if there is no 
further comments on this direction, can we begin the WG adoption call then?
Thanks you and Peter for your intense discussions for this draft.

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Sunday, November 15, 2020 7:44 AM
> To: Zhibo Hu ; Aijun Wang
> ; Gyan S. Mishra ;
> Gyan Mishra 
> Subject: New Version Notification for
> draft-wang-lsr-passive-interface-attribute-06.txt
> 
> 
> A new version of I-D, draft-wang-lsr-passive-interface-attribute-06.txt
> has been successfully submitted by Aijun Wang and posted to the IETF
> repository.
> 
> Name: draft-wang-lsr-passive-interface-attribute
> Revision: 06
> Title:Passive Interface Attribute
> Document date:2020-11-15
> Group:Individual Submission
> Pages:10
> URL:
> 
https://www.ietf.org/archive/id/draft-wang-lsr-passive-interface-attribute-06.t
> xt
> Status:
> 
https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/
> Htmlized:
> 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribut
> e
> Htmlized:
> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-06
> Diff:
> 
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-attribute-06
> 
> Abstract:
>This document describes the mechanism that can be used to
>differentiate the passive interfaces from the normal interfaces
>within ISIS or OSPF domain.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 



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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-17 Thread Acee Lindem (acee)
Speaking as WG member:

I think it would be good to hone in on the BGP PE failure convergence use case 
as suggested by Robert. It seems there is some interest here although I’m not 
convinced the IGP is the right place to solve this problem.

Thanks,
Acee

From: Lsr  on behalf of Gyan Mishra 

Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk 
Cc: lsr , Jeff Tantsura , Aijun Wang 
, "Acee Lindem (acee)" 

Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases



On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:


   Robert, I believe the original intention was related to having the data 
plane converge quickly when summarization is used and flip so traffic converges 
from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both 
ABRs will get the same info. As mentioned before there is no practical use of 
PUA for making any routing or fwd decision on which ABR to use. If your ABRs 
are not connected with min redundancy this draft is a worst patch ever to work 
around such a design.

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track the 
component prefixes and in case where component is down and traffic is still 
forwarded to the ABR and dropped.  The other more important use case is when 
links are down within the area and the area is partitioned and so one ABR has 
all component prefixes however other ABR is missing half the component 
prefixes.  So since the ABR will by default advertise the summary as long as 
their is one component UP the summary is still advertised.  So this use case is 
severely impacting as now you have an ECMP path to the other area for the 
summary via the two ABRs and you drop half your traffic.  So now with PUA the 
problem is fixed and the PUA is sent and now traffic is only sent to the ABR 
that has the component prefixes.

Please present us a picture indicating before and after ABRs behaviour.

 Gyan> will do

   However PUA can be used in the absence of area segmentation within a single 
area when a link or node fails to converge the data plane quickly by sending 
PUA for the backup path so the active path.

If there is no area segmentation then there is no summaries. So what are we 
missing in the first place ?

Gyan> Sorry I am stating that PUA feature can also be used intra area where 
if a link or node goes down to improve data plane convergence.


With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA & RLFA 
for MPLS or TI-LFA for SR local protection - with those tweaks the convergence 
is well into sub second.  So for Intra area convergence with all the 
optimizations mentioned I am not sure how much faster the data plane will 
converge with PUA.

Even without any of the above listed chain of acronymous things will generally 
work well intra-area without PUAs.

Gyan> Agreed which is why I mentioned the BGP next hop self use case if I 
could figure out how PUA could help there that would be a major benefit of PUA.

Thx,
R.


--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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


Re: [Lsr] Prefix Unreachable Announcement Use Cases

2020-11-16 Thread Acee Lindem (acee)
When the PUA use cases were presented today in the LSR meeting, I made the 
comment that the RIB interactions for each use case would be different and 
needed to be specified.
Thanks,
Acee


From: Robert Raszuk 
Date: Monday, November 16, 2020 at 3:25 AM
To: Aijun Wang 
Cc: Jeff Tantsura , lsr , Acee Lindem 

Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

I was not bringing RIFT's negative routies example as something inherently 
negative. I was just pointing it out to illustrate that today's data plane 
lookup does not really support "if does not match" checks.
[WAJ] In data plane, the device do still the “match” check, not “does not 
match” check.  When the router receives the PUA information, it will install 
one black hole route for a short time.

So your idea is that you install route for unreachable prefix to /dev/null ?

And how would that help connectivity restoration ?

Moreover it seems that it will just also prevent any local protection to 
locally bypass the failed destination.

Bottom line is that I agree with one problem statement. However IMHO described 
actions upon reception of PUA are questionable at best.

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


[Lsr] Prefix Unreachable Announcement Use Cases

2020-11-14 Thread Acee Lindem (acee)
Speaking as WG member…

With respect to the use cases in section 3:

  3.1 Inter-Area Node Failure Scenario – With respect to this use case, the 
node in question is actually unreachable. In this case, the ABRs will normally 
install a reject route for the advertised summary and will send an ICMP 
unreachable when the packets are received for the unreachable prefix. This is 
the expected behavior and there really isn’t that much of advantage to move the 
point of unreachable detection a couple hops closer. If faster detection is 
required, BFD or other mechanisms are available.

  3.3 Intra-Area Node Failure Scenario – In the first place, multiple areas 
with overlapping summaries is just a bad network design. If the prefix is 
unreachable, the case digresses to getting the ICMP unreachable from the ABR 
with the invalid overlapping summary.

3.2 Inter-Area Links Failure Scenario – This is the case where the prefix is 
reachable but only through a subset of the area ABRs. This is really the only 
valid use case. IMO, it is better to solve this case with intra-area tunnels 
through the backbone as described in section 6.1. I think this is preferable to 
the complexity proposed in this draft and especially section 6. It is 
“interesting” when non-implementors specify implementation details.

Thanks,
Acee








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


Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-11-11 Thread Acee Lindem (acee)
Hi Aijun,

From:  on behalf of Aijun Wang 

Date: Tuesday, November 10, 2020 at 6:27 PM
To: Acee Lindem 
Cc: "Peter Psenak (ppsenak)" , Aijun Wang 
, "lsr@ietf.org" 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:
I have updated the draft according to the discussion with Peter on the list. 
The updated draft will be uploaded once the IETF repository reopen.
We define new TLV to contain the stub-link related information within OSPFv2/v3 
and ISIS respectively. The presentation will also align with it.

Ok - Keep in mind that passive interface is not standardized. Also, as I stated 
previously, my view is you should advertise precisely what your use case 
requires rather than making uncertain inferences from the fact that an 
interface is configured as passive.

Together with the use case that described in Linda’s draft 
https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01, we 
think this extension is necessary and should be considered within IGP.

I have the a similar comment that stub link should not be used in this draft.

Thanks,
Acee

Thanks in advance.
Aijun Wang
China Telecom


On Nov 11, 2020, at 02:01, Acee Lindem (acee)  wrote:
Aijun,

Speaking as WG member:

At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC 
5340. Hence, this purely a vendor concept.
Additionally, it is a property, albeit a vendor property, of a link and not a 
prefix. It would be both inappropriate and profligate (considering the 
scarcity) to allocate a prefix option for the purpose of identifying a passive 
link associated with the prefix. Given your narrow use case of identifying the 
edge of an IGP domain, it would certainly be better to allocate a new TLV 
specifically for purpose and perhaps this doesn't belong in the IGPs at all and 
should be something you propose solely for BGP-LS consumption.

Speaking as WG Co-chair:

Given strong objections to this draft in its current form, I don't really see a 
good reason for present it at IETF 109. I believe it would just be a rehash of 
the discuss that has already taken place.

Thanks,
Acee

On 11/9/20, 4:44 AM, "Peter Psenak"  wrote:

   Hi Aijun,

   On 09/11/2020 07:35, Aijun Wang wrote:

Hi, Peter:

Currently, the inter-AS link TLV is advertised within the Inter-AS-TE-LSA for 
OSPF and Inter-AS Reachability TLV for ISIS.
But I think these two places are not suitable for the stub-link information.

It seems that separating the stub-link information from the inter-as link 
information is better, because not all of the stub-links are inter-as link.
If so, can we put the newly defined Stub-Link TLV within the Router LSA for 
OSPF and make it one new top TLV for ISIS?

   Router LSA does not have TLVs, you would have to add the data to
   Extended Prefix Link TLV (RFC7684), or define a net top-level TLV under
   the OSPFv2 Extended Link Opaque LSA.

   For ISIS you don't have a choice really, you need to define a new
   top-level TLV.

   thanks,
   Peter




Best Regards

Aijun Wang
China Telecom

-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Saturday, November 7, 2020 1:56 AM
To: Aijun Wang 
Cc: Aijun Wang ; Acee Lindem (acee) 
; lsr@i
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] Requesting NOMCOM Feedback

2020-11-10 Thread Acee Lindem (acee)
NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC Board, 
and IETF Trust. We need more input from the community both on specific nominees 
and on over-arching topics regarding what the community wants from these 
specific groups and wants from its leadership in general. We need *your* input.

** Deadline for community feedback is Friday November 20. **

We've paid attention to discussions on the ietf list. Issues raised there have 
been brought up in interviews.

We've also asked questions of nominees based on feedback received, and based on 
the "Topics" that people said were important.
We're listening to you.

But most of the input to date has come from a few consistently vocal people. We 
need to hear from more of you.

I scheduled our office hours during the 2 weeks before next week's IETF, 
because IETF week is so busy. We have one more left (18:00-19:00 UTC November 
11). No-one but NomCom members showed up for our first 3. ☹ If there is demand 
for more office hours, I'll schedule them; but this really doesn't seem to be 
the preferred format for input.

Most input is coming in as either
- email to nomco...@ietf.org
- feedback on https://datatracker.ietf.org/nomcom/2020/feedback/
On the feedback page, the specific nominees are all listed at the top. General 
Topics are at the bottom.
We pay attention to all the comments we get through these channels.

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


Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-11-10 Thread Acee Lindem (acee)
Aijun, 

Speaking as WG member:

At least for OSPF, passive interfaces are not standardized in RFC 2328 or RFC 
5340. Hence, this purely a vendor concept. 
Additionally, it is a property, albeit a vendor property, of a link and not a 
prefix. It would be both inappropriate and profligate (considering the 
scarcity) to allocate a prefix option for the purpose of identifying a passive 
link associated with the prefix. Given your narrow use case of identifying the 
edge of an IGP domain, it would certainly be better to allocate a new TLV 
specifically for purpose and perhaps this doesn't belong in the IGPs at all and 
should be something you propose solely for BGP-LS consumption. 

Speaking as WG Co-chair:

Given strong objections to this draft in its current form, I don't really see a 
good reason for present it at IETF 109. I believe it would just be a rehash of 
the discuss that has already taken place.
 
Thanks,
Acee

On 11/9/20, 4:44 AM, "Peter Psenak"  wrote:

Hi Aijun,

On 09/11/2020 07:35, Aijun Wang wrote:
> Hi, Peter:
> 
> Currently, the inter-AS link TLV is advertised within the Inter-AS-TE-LSA 
for OSPF and Inter-AS Reachability TLV for ISIS.
> But I think these two places are not suitable for the stub-link 
information.
> 
> It seems that separating the stub-link information from the inter-as link 
information is better, because not all of the stub-links are inter-as link.
> If so, can we put the newly defined Stub-Link TLV within the Router LSA 
for OSPF and make it one new top TLV for ISIS?

Router LSA does not have TLVs, you would have to add the data to 
Extended Prefix Link TLV (RFC7684), or define a net top-level TLV under 
the OSPFv2 Extended Link Opaque LSA.

For ISIS you don't have a choice really, you need to define a new 
top-level TLV.

thanks,
Peter

> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Saturday, November 7, 2020 1:56 AM
    > To: Aijun Wang 
> Cc: Aijun Wang ; Acee Lindem (acee) 
; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt
> 
> Aijun,
> 
> On 05/11/2020 12:04, Aijun Wang wrote:
>> Hi, Peter:
>> Then how about defines one new top TLV to flood such information within 
the IGP? Fox example, Stub-Link TLV? If so, other characteristics associated 
with the Link can also be advertised accordingly.
> 
> yes, unless you can use or extend the existing inter-AS link 
advertisement.
> 
> thanks,
> Peter
> 
>>
>> If acceptable, we can forward this draft along this direction.
>>
>>
>> Aijun Wang
>> China Telecom
>>
>>> On Nov 5, 2020, at 17:15, Peter Psenak 
 wrote:
>>>
>>> Aijun,
>>>
>>> the point I was trying to make was that you should think of a similar 
mechanism for your use cases - e.g. define something that advertises the link 
without advertising the IS adjacency and not mess up with the prefix 
advertisement.
>>>
>>> thanks,
>>> Peter
>>>
>>>> On 05/11/2020 10:09, Aijun Wang wrote:
>>>> Hi, Peter:
>>>> Yes, RFC 5392 is the OSPF corresponding part for the inter-AS TE 
solution. But using these existing solutions has some limitation in deployment, 
as I explained in 
https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/.
>>>> And, in some situations, not all of the passive interfaces are 
connected with another AS, then flag these interfaces using RFC 5316 or RFC 
5392 is not appropriate.
>>>> Do you agree?
>>>> Best Regards
>>>> Aijun Wang
>>>> China Telecom
>>>> -Original Message-
>>>> From: ppse...@cisco.com [mailto:ppse...@cisco.com]
>>>> Sent: Thursday, November 5, 2020 4:26 PM
>>>> To: Aijun Wang ; 'Acee Lindem (acee)'
>>>> ; 'Aijun Wang' 
>>>> Cc: lsr@ietf.org
>>>> Subject: Re: [Lsr] FW: New Version Notification for
>>>> draft-wang-lsr-passive-interface-attribute-04.txt
>>>> Hi Aijun,
>>>> please look at rfc5316, ISIS already have a way to advertise inter-AS 
link without forming an adjacency.
>>>> thanks,
>>>> Peter
>>>>> On 05/11/2020 02:15, Aijun Wang wrote:
>>>>> Hi, Acee:
>>>>>
>>>>> Thanks for this comments.
>>>&g

Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-11-07 Thread Acee Lindem (acee)
The WG adoption call has ended and draft-chen-lsr-isis-rfc5316bis-02 has been 
accepted as a WG document. While we didn’t get as much response as I would have 
liked, every response was supportive of adopting this protocol maintenance 
draft as a WG document. When the draft submission window opens, please publish 
as draft-ietf-lsr-isis-rfc5316bis-00.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, October 23, 2020 at 10:43 AM
To: "lsr@ietf.org" 
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

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


Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

2020-11-04 Thread Acee Lindem (acee)
Exactly.
Thanks,
Acee

From: Jeff Tantsura 
Date: Wednesday, November 4, 2020 at 6:16 PM
To: Acee Lindem , Yingzhen Qu , 
"lsr@ietf.org" , "lsr-cha...@ietf.org" , 
Linda Dunbar 
Subject: Re: [Lsr] Question on using OSFPv2 extended Prefix TLV as the OSPF 
extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

For OSPFv3 use E-LSAs (RFC8362)

Cheers,
Jeff
On Nov 4, 2020, 2:44 PM -0800, Linda Dunbar , wrote:
Acee,

Thank you very much for suggesting using the Prefix TLV for carry the Running 
Status and environment of 5G Edge Computing servers.

In a nutshell, the 
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
proposes the extension to LSA that can carry the three SubTLVs that are used to 
represent the Running Status and Environment information of the 5G Edge 
Computing Servers attached to the router:

 • Load measurement sub-TLV
 • Capacity Index  Sub-TLV
 • Preference Index  Sub-TLV

Several sections of the draft are devoted to describe what those measurement 
are and why need them for 5G Edge Computing, which may have made it not so 
straightforward when reading in a rush.

The Goal of the OSPF extension is to carry those Sub-TLVs in the router’s LSA 
to be advertised to other routers in the 5G Local Data Network.

If using your suggested RFC7684 OSPFv2 Extended Prefix TLV, the extension does 
seem easier and cleaner:

We can have:
 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type| Prefix Length | AF| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Load Measurement Sub-TLV  |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| capacity Index Sub-TLV|
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Site Preference Sub-TLV   |
~   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


RFC7684 only has the Extended Prefix TLV for IPv4. If the App Server addresses 
are in IPv6, should we specify the extension to RFC8362 in the same draft? Or 
define a new AF type for the same extension to RFC7684?

Your guidance is greatly appreciated.

Thank you very much.

Linda Dunbar


From: Acee Lindem (acee) 
Sent: Tuesday, November 3, 2020 1:38 PM
To: Linda Dunbar ; Yingzhen Qu 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: Need 10 minute slot to discuss OSPF extension for 5G Edge 
Computing (was RE: [Lsr] IETF 109 LSR Presentation Slot Requests

We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
"lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>" 
mailto:lsr-cha...@ietf.org>>
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>>, Acee Lindem 
mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext%2F=04%7C01%7Clinda.dunbar%40futurewei.com%7C83f990f38fe14407efe208d880300245%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637400290992237706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-11-04 Thread Acee Lindem (acee)
Hi Aijun,
You still didn't answer the question as to why you didn't rework this draft for 
passive interface to be an interface attribute rather than a prefix attribute? 
Thanks,
Acee

On 10/1/20, 6:13 AM, "Acee Lindem (acee)"  wrote:

Hi Aijun, 
You didn't answer my question and pruned my message. Other than your 
attempt to expose the topology of areas outside the area, there is no other 
reason to associate the passive interface attribute with a prefix. We seem to 
be in a circular discussion 
Acee

On 9/30/20, 10:43 PM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:
Except the corner cases of unnumbered interface, would you like to 
illustrate other scenarios that the process does not apply?
As mentioned in last mail, knowing the passive interfaces can assist 
the nodes or controller know the boundaries of the network.

Aijun Wang
China Telecom

> On Sep 30, 2020, at 19:47, Acee Lindem (acee)  wrote:
> 



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


Re: [Lsr] Need 10 minute slot to discuss OSPF extension for 5G Edge Computing (was RE: IETF 109 LSR Presentation Slot Requests

2020-11-03 Thread Acee Lindem (acee)
We have a pretty full schedule and we add you as optional. I took a look at the 
draft and it is all over the place right now with standardization requested for 
one solution but 3 separate solutions partially specified. It could benefit 
from some WG mailing list discussion prior to a 10 minute presentation where we 
wouldn’t have time to discuss the many issues.

One major issue is that you should be extending RFC 7684 rather than RFC 3630 
and it seems you these app-server selection metrics should be associated with a 
prefix and NOT a stub link (i.e., the application server address).

I’ll try to read it in more depth before IETF 109.

Thanks,
Acee

From: Linda Dunbar 
Date: Monday, November 2, 2020 at 10:12 PM
To: Yingzhen Qu , "lsr@ietf.org" , 
"lsr-cha...@ietf.org" 
Subject: Need 10 minute slot to discuss OSPF extension for 5G Edge Computing 
(was RE: [Lsr] IETF 109 LSR Presentation Slot Requests
Resent-From: 
Resent-To: Yingzhen Qu , Acee Lindem , 
Christian Hopps 
Resent-Date: Monday, November 2, 2020 at 10:12 PM

LSR Chairs, YingZhen,

Can you give us 10 minute slot to present this new draft:
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/

This draft describes an OSPF extension that can distribute the 5G Edge 
Computing App running status and environment, so that other routers in the 5G 
Local Data Network can make intelligent decision on optimizing forwarding of 
flows from UEs. The goal is to improve latency and performance for 5G Edge 
Computing services.

Thank you very much,

Linda Dunbar

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Monday, October 19, 2020 3:52 PM
To: lsr@ietf.org; lsr-cha...@ietf.org
Subject: [Lsr] IETF 109 LSR Presentation Slot Requests

Hi all,

We're now accepting agenda requests for the LSR Working Grouping meeting IETF 
109. Please send your requests to 
lsr-cha...@ietf.org indicating draft name, speaker, 
and desired duration (covering presentation and discussion).

LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT.

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


Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-10-24 Thread Acee Lindem (acee)
Speaking as a WG member:

I support WG adoption of this draft.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, October 23, 2020 at 10:43 AM
To: "lsr@ietf.org" 
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS 
MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

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


[Lsr] IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-10-23 Thread Acee Lindem (acee)
Hi Mach, Les, Stefano, Xiaodong,

Are you aware of any IPR associated with the subject draft.

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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


[Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

2020-10-23 Thread Acee Lindem (acee)
This is simple BIS update to RFC 5316 is required to support IS-IS Inter-AS TE 
in IPv6 only networks. The authors have asked for WG adoption.

This begins a two week LSR Working Group Adoption Poll for “ISIS Extensions in 
Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering” - 
draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on 
November 7th, 2020. Please indicate your support of objection on this list 
prior to the end of the adoption poll.

Thanks,
Acee

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


Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-10-21 Thread Acee Lindem (acee)
Now the Routing Directorate review is complete, I will request publication. 
Thanks,
Acee

On 10/1/20, 11:32 AM, "Acee Lindem (acee)"  wrote:

The WG last call has ended. All comments have been addressed or concluded. 
There was considerable discussion regarding the requirement that alternate link 
metrics come from Application-Specific Link Attributes (ASLAs) and whether to 
allow them from TE advertisements as well. The consensus was to since this is a 
new application mandating a single source of truth for ASLAs. From a technical 
standpoint, this is especially true with OSPF where allowing them to come from 
TE advertisements requires correlation of an additional LSA per link and all 
the attendant complexity. 

The document will be submitted to the IESG for publication as soon as I 
complete the shepherd writeup. 

Thanks,
Acee 

On 8/17/20, 7:30 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after September 1st, 2020, 
for draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether 
you aware of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.



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


Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-19 Thread Acee Lindem (acee)
Speaking as WG chair: 

On 10/19/20, 1:06 PM, "Christian Hopps"  wrote:



> On Oct 16, 2020, at 4:47 AM, Aijun Wang  wrote:
> 
> Hi, Les and experts in LSR:
> 
> I am open to the removal of the this appendix to forward this draft.

That's good news, thank you Aijun.

Speaking for the chairs,

We believe we have reached WG consensus (seems better than just rough even 
with some authors asking for the change) at this point on the removal of the 
disputed use-case appendices.

Could you please republish the document w/o the disputed sections?

Thanks,
Chris.

I'll add that RFC 7221, section 1.2 
https://tools.ietf.org/html/rfc7221#section-1.2  includes a very good 
description of the IETF process for WG document ownership and consensus. 

Thanks,
Acee

> But as stated in previous mail, providing this can assist the user/reader 
of the draft. We often encounter the questions in the mail list that what the 
usage of protocol/bit definition in some drafts.
> 
> Actually, we did not expand the discussion of this part in this draft. 
The description of this part is very concise.
> 
> If you insist this, I can update the draft in recent days, together with 
other comments on this draft.
> 
> Other comments are welcome also!
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg)  
wrote:
>> 
>> Aijun -
>> 
>> The point I am making is very focused.
>> 
>> This draft is defining a protocol extension. As such it is necessary 
that this be Standards track as adhering to the normative statements in the 
draft are necessary for interoperability.
>> 
>> What is discussed in the Appendix is a use case. It is not normative and 
there are strong opinions on both sides as to whether this is an appropriate 
use case or not.
>> In the context of this draft, I have no interest in trying to resolve 
our difference of opinion on this use case. I simply want the protocol 
extension to move forward so that we have another tool available.
>> 
>> If you want to write a draft on the use case discussed in the Appendix 
please feel free to do so. That draft may very well not be normative - 
Informational or BCP may be more appropriate - because it will be discussing a 
deployment scenario and a proposal to use defined protocol extensions as one 
way to solve problems in that deployment scenario. Such a draft might also be 
more appropriate in another WG (e.g., TEAS). The merits of using prefix 
advertisements to build a topology could then be discussed on its own.
>> 
>> Please do not try to avoid having a full discussion of the merits of 
using prefix advertisements to derive topology by adding it to a draft that is 
(and should be) focused on simple protocol extensions.
>> 
>> Thanx.
>> 
>>  Les
>> 
>> 
>>> -Original Message-
>>> From: Aijun Wang 
>>> Sent: Thursday, October 15, 2020 6:51 PM
>>> To: 'Jeff Tantsura' ; 'John E Drake'
>>> 
>>> Cc: 'Christian Hopps' ; lsr-cha...@ietf.org; Les 
Ginsberg
>>> (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
draft-ietf-
>>> lsr-ospf-prefix-origina...@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>>> 
>>> Hi, Les, John and Jeff:
>>> 
>>> Let's reply you all together.
>>> In my POV, The standard document should not define solely the protocol
>>> extension, but their usages in the network deployment. As I known, 
almost
>>> all the IETF documents following this style.
>>> And, before adopting one work, we have often intense discussion for 
what's
>>> their usages.
>>> Such discussion in the mail list and statements in the doc
> 


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


Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-15 Thread Acee Lindem (acee)
Also, speaking as WG member and co-author, I support publication. 
Thanks,
Acee

On 10/15/20, 6:12 AM, "Acee Lindem (acee)"  wrote:

I am not aware of any IPR. 
Thanks,
Acee

On 10/15/20, 2:15 AM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related 
to this work.

Thanks,
Chris.


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


Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

2020-10-15 Thread Acee Lindem (acee)
I am not aware of any IPR. 
Thanks,
Acee

On 10/15/20, 2:15 AM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/

The following IPR has been filed https://datatracker.ietf.org/ipr/3448/

Authors,

  Please indicate to the list, your knowledge of any other IPR related to 
this work.

Thanks,
Chris.

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


Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-10-12 Thread Acee Lindem (acee)
Speaking WG member:

Hi Gyan, Aijun,

Even if I agreed with your use case assuming a passive interface denotes the 
boundary between two domains as shown in figure 1 in your draft (which I 
don’t), you still should not be trying to hack the prefixes with what is 
inherently link attribute. Can I state this anymore simply or are you are just 
going to restate your requirements again???

Acee

From: Gyan Mishra 
Date: Sunday, October 11, 2020 at 3:19 PM
To: Acee Lindem 
Cc: Aijun Wang , Aijun Wang 
, "Peter Psenak (ppsenak)" , 
"lsr@ietf.org" 
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt


Hi Acee

I believe what Aijun is trying to explain is that the primary purpose of PCE 
for active or passive path computation is for inter-as RSVP-TE PCALC path 
computation or SR-TE path computation.  So PCE is solving a well known PCALC 
bin packing problem due to pcalc over subscribing RSVP tunnel bandwidth which 
is inherent an RSVP issue, but a bigger problematic issue is with being able to 
build an inter-as TE path with a single or multiple PCE controllers that can 
take the LSDB link attributes in the TEDs dB opaque LSAs in the ospf case and 
ISIS TE TLVs and rebuild the topology topology from each TE domain to be able 
to build a congruent end to end RSVP TE or SR-TE traffic steered path 
instantiation.

Without the use of PCE controllers as the LSDB link attribute information is 
not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid loose 
path is built, failover due to crank back is impacted for reroute, due to not 
having a complete depiction of the other AS Link state topology by the head end 
or SR source node.

So to build that entire end to end inter-as path for that end to end RSVP TE or 
SR-TE path instantiation it is critical to indentify the inter-as link eBGP tie 
link that may have static routes or BGP LU for RSVP head end to tail end 
reachability and SR-TE reachability to build out the end to end path 
instantiation.  So the BGP-LS task to  rebuild the lsdb topology of each inter 
connected AS that the RSVP TE or SR-TE steered path traverses, we need the 
accurate depiction and that includes the Identification of the  critical 
inter-as tie link eBGP peering link that is passive for the PCE path 
computation logic for the end to end inter-as path instantiation.

As for other interfaces using passive in the context of a operator service 
provider or enterprise core P and PE routers all links are transit with 
neighbors except the inter-as tie so having this new IGP TLV will help to that 
end.  In the operator “core” network if there are other  interfaces that don’t 
need to be advertised as stub, they can easily be excluded from being added 
into IGP.

Kind Regards

Gyan

On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Aijun,

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 'Aijun Wang' 
mailto:wang...@chinatelecom.cn>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf Of Acee 
Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 'Aijun 
Wang' mailto:wang...@chinatelecom.cn>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun,

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 'Aijun Wang' 
mailto:wang...@chinatelecom.cn>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt


Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again along your original 
question.

Please see inline.[WAJ]



-Original Message-
From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 'Aijun 
Wang' mailto:wang...@chinatelecom.cn>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] FW: New Version Notificatio

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

2020-10-11 Thread Acee Lindem (acee)
Or possibly the prospect of Flex Algo flavors made you hungry ;^0. 

Acee

On 10/11/20, 1:39 PM, "Lsr on behalf of Jeff Tantsura"  wrote:

Thanks Ron, indeed!  Autocorrect works in mysterious ways  ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica  wrote:
> 
> Jeff,
> 
> I think that you mean the scope is different. 
> 
> Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: Jeff Tantsura  
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica 
> Cc: Dongjie (Jimmy) ; Peter Psenak 
; Yingzhen Qu ; Gyan Mishra 
; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for 
draft-bonica-lsr-ip-flexalgo-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Jie,
> 
> The scoop is different, for SR data plane entry uniqueness is in context 
of SR domain (SID = value + context), while for IP it is global to the routing 
domain, FIB entry is a destination, nothing more.
> 
> Regards,
> Jeff
> 
>> On Oct 10, 2020, at 05:47, Ron Bonica  wrote:
>> 
>> Hi Jimmie,
>> 
>> Inline.
>> 
>>   Ron
>> 
>> 
>> Juniper Business Use Only
>> 
>> -Original Message-
>> From: Dongjie (Jimmy) 
>> Sent: Friday, October 9, 2020 11:06 PM
>> To: Peter Psenak ; Ron Bonica
>> ; Yingzhen Qu ; Gyan 
>> Mishra 
>> Cc: lsr@ietf.org; Jeff Tantsura 
>> Subject: RE: [Lsr] FW: New Version Notification for 
>> draft-bonica-lsr-ip-flexalgo-00.txt
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Peter,
>> 
>> Thanks for your reply. It aligns with my understanding of FAD, which is 
just a set of constraints for path computation. Thus one Flex-Algo ID could be 
used with multiple different data planes. Is this understanding correct?
>> 
>> [RB] I never thought about this. Is there a use-case? I think that it 
will work, but I would have to try it before saying for sure.
>> 
>> If so, my question is about the scenario below:
>> 
>> A group of nodes in a network support FA-128, a sub-group of them bind 
FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When 
one node compute an SR path to a destination, can it compute the path to only 
pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind 
FA-128 to IP address?
>> 
>> [RB] I don't think so. However, you could achieve the same outcome using 
link colors.
>> 
>> If so, how could this node know the binding of FA to different data 
planes on other nodes?
>> 
>> Best regards,
>> Jie
>> 
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, October 9, 2020 11:58 PM
>>> To: Dongjie (Jimmy) ; Ron Bonica 
>>> ; Yingzhen Qu 
>>> ; Gyan Mishra 
>>> Cc: lsr@ietf.org; Jeff Tantsura 
>>> Subject: Re: [Lsr] FW: New Version Notification for 
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>> 
>>> Hi Jimmy,
>>> 
>>> 
> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
> Hi Ron,
> 
> Thanks for explaining the difference between IP Flex-Algo and SR 
> Flex-algo. As
>>> you said, the major difference is the data plane.
 
 If my understanding is correct, for one Flex-Algo to be used 
 correctly, the set
>>> of nodes need to apply consistent constraints in computation, and 
>>> bind the FAD to the same data plane.
 
 Is it possible that different nodes may use the same Flex-Algo with 
 different
>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with 
>>> pure IP etc., or each Flex-Algo is always associated with only one 
>>> data plane? In the former case, should the flex-algo definition also 
>>> indicate the data plane(s) to be used with the flex-algo?
>>> 
>>> let me respond to this query, as this is not specific to Ron's draft.
>>> 
>>> FAD is data plane agnostic and is used by all of them.
>>> 
>>> thanks,
>>> Peter
>>> 
 
 Best regards,
 Jie
 
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica
> Sent: Sunday, October 4, 2020 4:34 AM
> To: Yingzhen Qu ; Peter Psenak 
> ; Gyan Mishra 
> Cc: lsr@ietf.org; Jeff Tantsura 
> Subject: Re: [Lsr] FW: New Version Notification for 
> draft-bonica-lsr-ip-flexalgo-00.txt
> 
> Hi Yingzhen,
> 
> IP Flexible Algorithms are like SR Flexible Algorithms in the 
> following
>>> respects:
> 
> - Links have IGP metrics, TE metrics, delay metrics and 
> 

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-10-10 Thread Acee Lindem (acee)
Hi Aijun,

From: Aijun Wang 
Date: Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem , "Peter Psenak (ppsenak)" , 
'Aijun Wang' 
Cc: "lsr@ietf.org" 
Subject: RE: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Hi, Acee:

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 AM
To: Aijun Wang ; Peter Psenak (ppsenak) 
; 'Aijun Wang' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun,

From: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem mailto:a...@cisco.com>>, "Peter Psenak 
(ppsenak)" mailto:ppse...@cisco.com>>, 'Aijun Wang' 
mailto:wang...@chinatelecom.cn>>
Cc: "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: RE: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt


Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again along your original 
question.

Please see inline.[WAJ]



-Original Message-
From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; 'Aijun 
Wang' mailto:wang...@chinatelecom.cn>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt



Hi Aijun,

Other than your ill-conceived topology discovery heuristic

[WAJ] The topology discovery heuristic is not suitable for the corner use case 
when the unnumbered interface is used, as explained in 
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B.
  If you don’t agree, would you like to illustrate other non-applicable 
scenarios?



Right – and nobody other than yourself believes the IGPs should be modified to 
expose the abstracted topology of an area outside that area.

[WAJ]  The modification doesn’t change the way and complexity of route 
calculation within IGP. It just piggyback some extra information, the bulk of 
the reconstruction work is done by the controller.  Such extra information can 
also have other usage, as described in 
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#section-1

And, the proposal described in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-04
 is different with the problem you concerned.  It has no relation with the 
abstracted topology of an area.  Maybe you are confused by these two drafts?



It is a similar problem. You are still trying to overload the prefix 
advertisements with a link attribute (passive interface) so that it can be 
conveyed outside the domain. We certainly wouldn’t waste a limited prefix flag 
on this parochial application.





You can solve the problem with BGP-LS session(s) between the router with a 
BGP-LS session to the controller and a router in each area w/o  a router with a 
BGP-LS session to the controller.

[WAJ] This is possible, but not efficient. For operation, we must also consider 
the configuration/administration overhead.  BGP-LS is designed mainly for the 
northbound protocol, not east-west protocol.



what other possible reason would there be for associating the passive attribute 
with a prefix?

[WAJ] To know the boundary of the IGP domain. After knowing the boundary, the 
controller can safely apply and check the network security policy, the inbound 
traffic control policy etc.



It really isn’t relevant, but I have to ask…. How does the presence of a prefix 
associated with a passive interface allow you to make this deduction?

[WAJ] Passive interfaces are deployed mainly at the boundary of IGP domain.  Is 
there any other exception?

While passive interfaces are not standardized, there is nothing that limits 
their usage to an IGP boundary. They can and are deployed on any interface 
where adjacencies are not to be formed (e.g., a stub subnet containing hosts).



Thanks,
Acee



Thanks,

Acee



Thanks,

Acee



On 9/29/20, 10:39 PM, "Aijun Wang" 
mailto:wangai...@tsinghua.org.cn>> wrote:



Hi, Acee and Peter:

Passive interface is mainly used at the edge of the network, where the 
unnumbered interface will not be used.

And the information to flag the passive interfaces is for positioning the 
area boundary, not conflict with the abstract capabilities of the area inside.





Best Regards



Aijun Wang

China Telecom



-Original Message-----

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)

Sent: T

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-10-09 Thread Acee Lindem (acee)
Speaking as WG member:

Hi Aijun,

From: Aijun Wang 
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem , "Peter Psenak (ppsenak)" , 
'Aijun Wang' 
Cc: "lsr@ietf.org" 
Subject: RE: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt


Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again along your original 
question.

Please see inline.[WAJ]



-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang ; Peter Psenak (ppsenak) 
; 'Aijun Wang' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt



Hi Aijun,

Other than your ill-conceived topology discovery heuristic

[WAJ] The topology discovery heuristic is not suitable for the corner use case 
when the unnumbered interface is used, as explained in 
https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B.
  If you don’t agree, would you like to illustrate other non-applicable 
scenarios?



Right – and nobody other than yourself believes the IGPs should be modified to 
expose the abstracted topology of an area outside that area. You can solve the 
problem with BGP-LS session(s) between the router with a BGP-LS session to the 
controller and a router in each area w/o  a router with a BGP-LS session to the 
controller.



what other possible reason would there be for associating the passive attribute 
with a prefix?

[WAJ] To know the boundary of the IGP domain. After knowing the boundary, the 
controller can safely apply and check the network security policy, the inbound 
traffic control policy etc.



It really isn’t relevant, but I have to ask…. How does the presence of a prefix 
associated with a passive interface allow you to make this deduction?



Thanks,

Acee



Thanks,

Acee



On 9/29/20, 10:39 PM, "Aijun Wang" 
mailto:wangai...@tsinghua.org.cn>> wrote:



Hi, Acee and Peter:

Passive interface is mainly used at the edge of the network, where the 
unnumbered interface will not be used.

And the information to flag the passive interfaces is for positioning the 
area boundary, not conflict with the abstract capabilities of the area inside.





Best Regards



Aijun Wang

China Telecom



-Original Message-

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)

Sent: Tuesday, September 29, 2020 9:16 PM

To: Peter Psenak 
mailto:ppsenak=40cisco@dmarc.ietf.org>>;
 Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Aijun Wang' mailto:wang...@chinatelecom.cn>>

Cc: lsr@ietf.org<mailto:lsr@ietf.org>

Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt



Speaking as WG member:



Hi Aijun, Peter,

I agree with Peter - one of the main motivations for having areas is to 
abstract the topology within the area. Now you're trying to supplant this  - 
one topological detail at a time with ill-conceived IGP features.

Thanks,

Acee



On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20ppsenak=40cisco@dmarc.ietf.org>>
 wrote:



Hi Aijun,



On 29/09/2020 11:07, Aijun Wang wrote:

> Hi, Peter:

>

> Thanks for your comments.

> 1. For BGP-LS deployment, there normally only be one router that 
within the

> IGP domain to report the topology information, this router should 
know such

> passive links which exists mainly on other border routers via the IGP

> protocol. This is main reason to extension the IGP protocol. > 2. For 
the solution, normally, the link within the IGP connect two

ends, but

> passive interface is special and not fall in this space. We have 
studied the

> current TLVs that for link, and find no suitable container to append 
this

> information. This is the reason that we select the TLVs that 
associated with

> Prefix.



if the link is unnumbered, your solution does not work. As I said, if

you need a knowledge about the link, you can not advertise it as a 
prefix.



thanks,

Peter





>

>>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", 
which

> isolate the prefix information that associated with link into this

> container, contains the stub link, local interface information etc. 
Put such

> attribute along with the prefix is then acceptable?

>

>

> Best Regards

>

> Aijun Wang

> China Telecom


Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

2020-10-05 Thread Acee Lindem (acee)
Hi Ketan,

From: "Ketan Talaulikar (ketant)" 
Date: Monday, October 5, 2020 at 1:29 AM
To: Gyan Mishra , "Les Ginsberg (ginsberg)" 

Cc: "lsr@ietf.org" , 
"draft-ketant-lsr-ospf-l2bundles@ietf.org" 
, Christian Hopps 
, "lsr-cha...@ietf.org" 
Subject: RE: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Monday, October 5, 2020 at 1:29 AM

Hi Gyan,

Thanks for your support and comments on the draft.

The proposed encoding for L2 Bundle members and their attributes in OSPF is 
different than the ISIS encodings in RFC8668. ISIS encodings have “tighter” LSP 
space considerations that OSPF. The authors have proposed a simpler encoding 
scheme for OSPF – feedback/inputs are welcome.

You have the bundle member sub-TLVs in the right place for OSPFv2 and OSPFv3.

Thanks,
Acee

The list of attributes in Figure 2 and 3 also includes L2 Bundle member Adj 
SID. Since the encoding scheme is similar to Layer 3 attributes, we can re-use 
the same sub-TLVs.

Thanks,
Ketan

From: Lsr  On Behalf Of Gyan Mishra
Sent: 03 October 2020 04:07
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles@ietf.org; Christian Hopps 
; lsr-cha...@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01


I support WG adoption of this draft.

I agree that OSPF needs the functionality equivalent to that defined for IS-IS 
in RFC 8668.

I think the draft should include similar to RFC 8668 section 3 parallel layer 3 
adjacencies 3 similar Sub TLVs mentioned flag for multiple parallel adjacencies.

Also maybe section 4 of RFC 8668 would apply as well to ospf advertisement of 
L2 bundle Adj sid.

Thanks

Gyan

On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
I support WG adoption of this draft.

OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Christian Hopps

> Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org

> Cc: lsr-cha...@ietf.org; Christian Hopps 
> mailto:cho...@chopps.org>>; draft-ketant-

> lsr-ospf-l2bundles@ietf.org

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

>

> This begins a 2 week WG adoption call for the following draft:

>

>   https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

>

> Please indicate your support or objection by October 16, 2020.

>

> Authors, please respond to the list indicating whether you are aware of any

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.



___

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mailman/listinfo/lsr
--

[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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


Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01

2020-10-02 Thread Acee Lindem (acee)
Speaking as WG member:
 
I support WG adoption of this document. It is needed for IS-IS parity and there 
are already other non-WG documents referencing it. 

Thanks,
Acee

On 10/2/20, 8:05 AM, "Christian Hopps"  wrote:

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

Please indicate your support or objection by October 16, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.

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


[Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt

2020-10-01 Thread Acee Lindem (acee)
Authors,

The following IPR has been disclosed (excerpted from 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo):

Date
ID
Statement
2018-08-08
3248
Cisco's Statement about IPR related to 
draft-ietf-lsr-flex-algo
2019-12-05
3910
Huawei Technologies Co.,Ltd's Statement about IPR related to 
draft-ietf-lsr-flex-algo


Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee


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


Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

2020-10-01 Thread Acee Lindem (acee)
Speaking as WG member... 

I agree that an independent calculation is required for IP Flex Algorithm and 
SR Flex Algorithm and this should be documented. However, it doesn't seem to me 
a normal use case would be to deploy them in the same IGP area. 

Thanks,
Acee

On 10/1/20, 4:07 AM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Ron,

I can only guess the use-case, but it may be worth of documenting it in 
the draft.

Your proposal is basically mimicking SRv6 Locator behavior for regular 
IPv6 and IPv4 prefixes. One can even argue that for IPv6 you can use a 
Locator advertisement with no SIDs, but I agree that would be a hack and 
separate encoding is cleaner.

One thing that needs further work is the algo participation part. Given 
that we have a separate participation for SR and IP flex-algo, one would 
have to run a separate calculation each in the context of the same 
flex-algo. Even though in most cases one would expect the set of 
participating routers to be the same for both. I don't see an easy way 
out, actually this is what the base FA draft requires it in section 
10.2. What I would suggest is to clearly document the fact that the 
computation for the IP flex-algo is independent of the other flex-algo 
computations (e.g. SR) and that IP flex-algo is an application of its 
own from the flex-algo perspective.

Les has commented on ISIS encoding, I have a question on OSPF one - have 
you considered using the OSPFv2 Extended Prefix Opaque LSA with OSPFv2 
Extended Prefix TLV (rfc7684) and define a new "IP Felex-algo" metric 
sub-TLV?

thanks,
Peter




On 29/09/2020 15:37, Ron Bonica wrote:
> 
> Please review and comment
> 
> Ron
> 
> 
> 
> Juniper Business Use Only
> 
>> -Original Message-
>> From: internet-dra...@ietf.org 
>> Sent: Tuesday, September 29, 2020 9:36 AM
>> To: Parag Kaneriya ; Shraddha Hegde
>> ; Ron Bonica ; Rajesh M
>> ; William Britto A J 
>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
>> has been successfully submitted by Ron Bonica and posted to the IETF
>> repository.
>>
>> Name:   draft-bonica-lsr-ip-flexalgo
>> Revision:   00
>> Title:  IGP Flexible Algorithms (Flexalgo) In IP Networks
>> Document date:  2020-09-29
>> Group:  Individual Submission
>> Pages:  14
>> URL:
https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
>> Status:
>> 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr-
>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
>> Htmlized:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
>> Htmlized:   
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>>
>>
>> Abstract:
>> An IGP Flexible Algorithm computes a constraint-based path and maps
>> that path to an identifier.  As currently defined, Flexalgo can only
>> map the paths that it computes to Segment Routing (SR) identifiers.
>> Therefore, Flexalgo cannot be deployed in the absence of SR.
>>
>> This document extends Flexalgo, so that it can map the paths that it
>> computes to IP addresses.  This allows Flexalgo to be deployed in any
>> IP network, even in the absence of SR.
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> 

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

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


Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

2020-10-01 Thread Acee Lindem (acee)
The WG last call has ended. All comments have been addressed or concluded. 
There was considerable discussion regarding the requirement that alternate link 
metrics come from Application-Specific Link Attributes (ASLAs) and whether to 
allow them from TE advertisements as well. The consensus was to since this is a 
new application mandating a single source of truth for ASLAs. From a technical 
standpoint, this is especially true with OSPF where allowing them to come from 
TE advertisements requires correlation of an additional LSA per link and all 
the attendant complexity. 

The document will be submitted to the IESG for publication as soon as I 
complete the shepherd writeup. 

Thanks,
Acee 

On 8/17/20, 7:30 PM, "Christian Hopps"  wrote:

This begins a 2 week WG Last Call, ending after September 1st, 2020, for 
draft-ietf-lsr-flex-algo

  https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

All authors, please indicate by sending an email to the list, whether you 
aware of any other IPR beyond what is already posted:

  [From 
https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-flex-algo]

  https://datatracker.ietf.org/ipr/3910/
  https://datatracker.ietf.org/ipr/3248/

Thanks,
Chris & Acee.


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


Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-10-01 Thread Acee Lindem (acee)
Hi Aijun, 
You didn't answer my question and pruned my message. Other than your attempt to 
expose the topology of areas outside the area, there is no other reason to 
associate the passive interface attribute with a prefix. We seem to be in a 
circular discussion 
Acee

On 9/30/20, 10:43 PM, "wang...@chinatelecom.cn on behalf of Aijun Wang" 
 wrote:

Hi, Acee:
Except the corner cases of unnumbered interface, would you like to 
illustrate other scenarios that the process does not apply?
As mentioned in last mail, knowing the passive interfaces can assist the 
nodes or controller know the boundaries of the network.

Aijun Wang
China Telecom

> On Sep 30, 2020, at 19:47, Acee Lindem (acee)  wrote:
> 


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


Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-05.txt

2020-09-30 Thread Acee Lindem (acee)
This version addresses Tom Petch's comments. 
Thanks,
Acee

On 9/30/20, 11:08 AM, "Lsr 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 Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-05.txt
Pages   : 29
Date: 2020-09-30

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-05

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-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/


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

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


Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt

2020-09-30 Thread Acee Lindem (acee)
Hi Tom, 

See inline  . I've addressed your comments in 05. 

On 9/30/20, 6:14 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 29 September 2020 22:44

Hi Tom,

We can add the references. See ACEE>.

Yes please - it will make it easier for me to review

On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch"  wrote:

From: Lsr  on behalf of internet-dra...@ietf.org 

Sent: 13 August 2020 05:37

I said before that it was tough to review because of a lack of 
references in the YANG module and that remains true.
You have two Boolean to enable extended LSA on for ospf, one for area.  
Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it 
took me some time to find it.  RFC8362 defines two parameters 
ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the 
model; yes you have a Boolean under area but I think its meaning requires a 
reading of RFC8362 Appendix B and that is missing and the description is 
unclear and the name is wrong.  Also the RFC has a SHOULD in it which the model 
does not implement.  You reference s.6.2 but I think that wrong, that it is 
Appendices A and B that describe this.

ACEE> What is the SHOULD that isn't implemented?


The very last sentence of RFC8362 about the interaction of 
ExtendedLSASupport and AreaExtendedLSASupport; YANG has 'must' not 'should' and 
I would be inclined to make this a YANG 'must' but it you think that that is 
too much, then a comment in the description is needed IMHO

On type, you say there are three possible values. Precisely.  Can you 
have the type set to 'ospf' and support ospfv3?  If so, your model fails.  Or 
does ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of 
ospf per se?

 Ok - I've changed this quite a bit by removing the default for the area 
level and adding the SHOULD as a YANG must. 


ACEE>"ospf" is the base identity for  "ospfv2" and "ospfv3". So, if a 
container is applicable to both, no when constraint is needed. However, if it 
is applicable to the one or the other, a "when" constraint. It is common to do 
this in YANG. This module is applicable only to OSPFv3.


Yes, my question is more about the base ospf model about the valid values 
that can appear in rt:type; is ospf per se a valid value of type or must it be 
either ospfv2 or ospfv3?

The reference statement after the description could do with a title as 
you have for the revision description

My point about link type is that you are augmenting ospf-yang which 
uses an enum so in places users will be required to use an enum and in others a 
uint8 which could be confusing

ACEE> I don't get this. We don’t augment link-type.


Yes,  In base ospf.yang  link type is YANG type enum but in this it is type 
unit8 so modelling the same object with two different data types I think might 
be confusing.

I see now. I've used the type ospf:link-type consistent with 
ietf-ospf.yang. 


Thanks,
Acee

Tom Petch

Thanks,
Acee

Tom Petch

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
Pages   : 27
Date: 2020-08-12

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04


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/


___
Lsr mailing lis

Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-09-30 Thread Acee Lindem (acee)
Hi Aijun, 
Other than your ill-conceived topology discovery heuristic, what other possible 
reason would there be for associating the passive attribute with a prefix? 
Thanks,
Acee

On 9/29/20, 10:39 PM, "Aijun Wang"  wrote:

Hi, Acee and Peter:
Passive interface is mainly used at the edge of the network, where the 
unnumbered interface will not be used. 
And the information to flag the passive interfaces is for positioning the 
area boundary, not conflict with the abstract capabilities of the area inside.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, September 29, 2020 9:16 PM
To: Peter Psenak ; Aijun Wang 
; 'Aijun Wang' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for 
draft-wang-lsr-passive-interface-attribute-04.txt

Speaking as WG member:

Hi Aijun, Peter, 
I agree with Peter - one of the main motivations for having areas is to 
abstract the topology within the area. Now you're trying to supplant this  - 
one topological detail at a time with ill-conceived IGP features.
Thanks,
Acee

On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Aijun,

On 29/09/2020 11:07, Aijun Wang wrote:
> Hi, Peter:
> 
> Thanks for your comments.
> 1. For BGP-LS deployment, there normally only be one router that 
within the
> IGP domain to report the topology information, this router should 
know such
> passive links which exists mainly on other border routers via the IGP
> protocol. This is main reason to extension the IGP protocol. > 2. For 
the solution, normally, the link within the IGP connect two 
ends, but
> passive interface is special and not fall in this space. We have 
studied the
> current TLVs that for link, and find no suitable container to append 
this
> information. This is the reason that we select the TLVs that 
associated with
> Prefix.

if the link is unnumbered, your solution does not work. As I said, if 
you need a knowledge about the link, you can not advertise it as a 
prefix.

thanks,
Peter


> 
>>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", 
which
> isolate the prefix information that associated with link into this
> container, contains the stub link, local interface information etc. 
Put such
> attribute along with the prefix is then acceptable?
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of 
Peter
> Psenak
> Sent: Tuesday, September 29, 2020 4:29 PM
> To: Aijun Wang 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-wang-lsr-passive-interface-attribute-04.txt
> 
> Hi Aijun,
> 
> here's my comments:
> 
> The purpose of this draft is to advertise passive links.
> 
> 1. I'm not sure the problem needs to be solved by IGPs. I tend to 
believe
> ietf-idr-bgpls-inter-as-topology-ext is sufficient.
> 
> 2. the solution that you proposed is wrong. You are trying to derive
> topological data about the passive links from the prefix 
advertisement.
> This is semantically incorrect and only works under very specific 
condition.
> If you need to advertise a link, advertise it as a "special"
> link, not as a "special" prefix.
> 
> thanks,
> Peter
> 
> On 29/09/2020 03:17, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Would you like to review and give comments on the updates version of 
this
> draft?
>> We have also added the protocol extension proposal for OSPFv3.
>>
>> The update version of this draft can refer to
>> 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface
>> -attribute
>> Thanks in advance.
>>
>>
>> Best Regards
>>
>> Aijun Wang
>> China Telecom
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Monday, September 28, 2020 3:17 PM
>>> To: Zhibo Hu ; Gyan Mishra
>

Re: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt

2020-09-29 Thread Acee Lindem (acee)
Hi Tom, 

We can add the references. See ACEE>. 

On 8/13/20, 6:03 AM, "Lsr on behalf of tom petch"  wrote:

From: Lsr  on behalf of internet-dra...@ietf.org 

Sent: 13 August 2020 05:37

I said before that it was tough to review because of a lack of references 
in the YANG module and that remains true.
You have two Boolean to enable extended LSA on for ospf, one for area.  
Yes, the answer is in RFC8362 but it tells me the YANG module is wrong - and it 
took me some time to find it.  RFC8362 defines two parameters 
ExtendedLSASupport and AreaExtendedLSASupport and the latter is not in the 
model; yes you have a Boolean under area but I think its meaning requires a 
reading of RFC8362 Appendix B and that is missing and the description is 
unclear and the name is wrong.  Also the RFC has a SHOULD in it which the model 
does not implement.  You reference s.6.2 but I think that wrong, that it is 
Appendices A and B that describe this.

ACEE> What is the SHOULD that isn't implemented? 

On type, you say there are three possible values. Precisely.  Can you have 
the type set to 'ospf' and support ospfv3?  If so, your model fails.  Or does 
ospf-yang only allow the type to be ospfv2 or ospfv3 and bar the use of ospf 
per se?

ACEE>"ospf" is the base identity for  "ospfv2" and "ospfv3". So, if a container 
is applicable to both, no when constraint is needed. However, if it is 
applicable to the one or the other, a "when" constraint. It is common to do 
this in YANG. This module is applicable only to OSPFv3. 


The reference statement after the description could do with a title as you 
have for the revision description

My point about link type is that you are augmenting ospf-yang which uses an 
enum so in places users will be required to use an enum and in others a uint8 
which could be confusing

ACEE> I don't get this. We don’t augment link-type. 

Thanks,
Acee

Tom Petch

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : YANG Model for OSPFv3 Extended LSAs
Authors : Acee Lindem
  Sharmila Palani
  Yingzhen Qu
Filename: draft-ietf-lsr-ospfv3-extended-lsa-yang-04.txt
Pages   : 27
Date: 2020-08-12

Abstract:
   This document defines a YANG data model augmenting the IETF OSPF YANG
   model to provide support for OSPFv3 Link State Advertisement (LSA)
   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
   extensible TLV-based LSAs for the base LSA types defined in RFC 5340.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-04


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/


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

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

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


Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt

2020-09-29 Thread Acee Lindem (acee)
Speaking as WG member:

Hi Aijun, Peter, 
I agree with Peter - one of the main motivations for having areas is to 
abstract the topology within the area. Now you're trying to supplant this  - 
one topological detail at a time with ill-conceived IGP features.
Thanks,
Acee

On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Aijun,

On 29/09/2020 11:07, Aijun Wang wrote:
> Hi, Peter:
> 
> Thanks for your comments.
> 1. For BGP-LS deployment, there normally only be one router that within 
the
> IGP domain to report the topology information, this router should know 
such
> passive links which exists mainly on other border routers via the IGP
> protocol. This is main reason to extension the IGP protocol. > 2. For the 
solution, normally, the link within the IGP connect two 
ends, but
> passive interface is special and not fall in this space. We have studied 
the
> current TLVs that for link, and find no suitable container to append this
> information. This is the reason that we select the TLVs that associated 
with
> Prefix.

if the link is unnumbered, your solution does not work. As I said, if 
you need a knowledge about the link, you can not advertise it as a prefix.

thanks,
Peter


> 
>>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix LSA", which
> isolate the prefix information that associated with link into this
> container, contains the stub link, local interface information etc. Put 
such
> attribute along with the prefix is then acceptable?
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of 
Peter
> Psenak
> Sent: Tuesday, September 29, 2020 4:29 PM
> To: Aijun Wang 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for
> draft-wang-lsr-passive-interface-attribute-04.txt
> 
> Hi Aijun,
> 
> here's my comments:
> 
> The purpose of this draft is to advertise passive links.
> 
> 1. I'm not sure the problem needs to be solved by IGPs. I tend to believe
> ietf-idr-bgpls-inter-as-topology-ext is sufficient.
> 
> 2. the solution that you proposed is wrong. You are trying to derive
> topological data about the passive links from the prefix advertisement.
> This is semantically incorrect and only works under very specific 
condition.
> If you need to advertise a link, advertise it as a "special"
> link, not as a "special" prefix.
> 
> thanks,
> Peter
> 
> On 29/09/2020 03:17, Aijun Wang wrote:
>> Hi, Peter:
>>
>> Would you like to review and give comments on the updates version of this
> draft?
>> We have also added the protocol extension proposal for OSPFv3.
>>
>> The update version of this draft can refer to
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface
>> -attribute
>> Thanks in advance.
>>
>>
>> Best Regards
>>
>> Aijun Wang
>> China Telecom
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Monday, September 28, 2020 3:17 PM
>>> To: Zhibo Hu ; Gyan Mishra
>>> ; Aijun Wang ;
>>> Gyan S. Mishra 
>>> Subject: New Version Notification for
>>> draft-wang-lsr-passive-interface-attribute-04.txt
>>>
>>>
>>> A new version of I-D,
>>> draft-wang-lsr-passive-interface-attribute-04.txt
>>> has been successfully submitted by Aijun Wang and posted to the IETF
>>> repository.
>>>
>>> Name:   draft-wang-lsr-passive-interface-attribute
>>> Revision:   04
>>> Title:  Passive Interface Attribute
>>> Document date:  2020-09-28
>>> Group:  Individual Submission
>>> Pages:  7
>>> URL:
>>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.
>>> txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att
>>> r
>>> ibute/
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac
>>> e
>>> -attribut
>>> e
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut
>>> e
>>> -04
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-passive-interface-at
>>> t
>>> ribute-04
>>>
>>> Abstract:
>>>  This document describes the mechanism that can be used to
>>>  differentiate the passive interfaces from the normal interfaces
>>>  within ISIS or OSPF domain.
>>>
>>>
>>>
>>>
>>> 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.
>>>

Re: [Lsr] RFC 8918 on Invalid TLV Handling in IS-IS

2020-09-24 Thread Acee Lindem (acee)
Authors, 
Thanks for the swift work on this document. 
Acee

On 9/24/20, 6:19 PM, "Lsr on behalf of rfc-edi...@rfc-editor.org" 
 wrote:

A new Request for Comments is now available in online RFC libraries.


RFC 8918

Title:  Invalid TLV Handling in IS-IS 
Author: L. Ginsberg,
P. Wells,
T. Li,
T. Przygienda,
S. Hegde
Status: Standards Track
Stream: IETF
Date:   September 2020
Mailbox:ginsb...@cisco.com, 
pauwe...@cisco.com, 
tony...@tony.li,
p...@juniper.net, 
shrad...@juniper.net
Pages:  8
Updates:RFC 5305, RFC 6232

I-D Tag:draft-ietf-lsr-isis-invalid-tlv-03.txt

URL:https://www.rfc-editor.org/info/rfc8918

DOI:10.17487/RFC8918

The key to the extensibility of the Intermediate System to
Intermediate System (IS-IS) protocol has been the handling of
unsupported and/or invalid Type-Length-Value (TLV) tuples. Although
there are explicit statements in existing specifications, deployment
experience has shown that there are inconsistencies in the behavior
when a TLV that is disallowed in a particular Protocol Data Unit
(PDU) is received.

This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized.

This document updates RFCs 5305 and 6232.

This document is a product of the Link State Routing Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

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


Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt

2020-09-24 Thread Acee Lindem (acee)
H Joel, 

Can you reference the specific section in the IS-IS SRv6 draft you are 
commenting on? I seem to remember this discussion but it was at least a month 
back, if not more. 

Thanks,
Acee

On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern"  wrote:

The announcement prompted me to look again and think about an 
interaction between this and the network programming draft.  To be 
clear, I am NOT objecting to either this or the network programming 
draft.  I am just wondering what I am missing.

The NP draft, and the advertisement mechanism allows a router to 
advertise the number of bits for the ARG portion of a SID.

Q1: The point presumably is to avoid needing to advertise each of the 
individual values?

An example of this is, I think, and ARG for the table selection where 
the ARG is the table number for the packet to be looked up in?

Q2: If so, how does the head end know what table number corresponds to 
what meaning?If this requires a separate advertisement there seems 
to be no savings.  if this requires out-of-band knowledge then we seem 
to have lost the benefit of advertising all of this in the routing protocol.

I suspect I am simply missing a piece.  can someone explain please?

Thank you,
Joel

On 9/23/2020 4:40 PM, 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 Link State Routing WG of the IETF.
> 
>  Title   : IS-IS Extension to Support Segment Routing 
over IPv6 Dataplane
>  Authors : Peter Psenak
>Clarence Filsfils
>Ahmed Bashandy
>Bruno Decraene
>Zhibo Hu
>   Filename: draft-ietf-lsr-isis-srv6-extensions-10.txt
>   Pages   : 25
>   Date: 2020-09-23
> 
> Abstract:
> Segment Routing (SR) allows for a flexible definition of end-to-end
> paths by encoding paths as sequences of topological sub-paths, called
> "segments".  Segment routing architecture can be implemented over an
> MPLS data plane as well as an IPv6 data plane.  This draft describes
> the IS-IS extensions required to support Segment Routing over an IPv6
> data plane.
> 
> 

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

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


Re: [Lsr] some doubt about RFC 5185 (Multi Area Adjacency)

2020-09-24 Thread Acee Lindem (acee)
Hi Meicong,

From: Lsr  on behalf of meicong 
Date: Thursday, September 24, 2020 at 2:23 AM
To: "lsr@ietf.org" 
Cc: Huzhibo , "Jiangyu (China)" 
Subject: [Lsr] some doubt about RFC 5185 (Multi Area Adjacency)



Hi ALL,
About rfc5185  OSPF Multi-Area Adjacency section 2.7 Advertising Multi-Area 
Adjacencies:

 Link ID = Remote's Router ID



I have the following questions:



1、I'm not sure whether “Neighbor's IP Address” means “local interface IP 
address” or “remote interface IP address”.

2、If it is remote interface IP address, why not use local interface IP address, 
 Any special considerations?



In looking at this again, I believe using the remote interface IP address is 
unnecessary since the interface area ID can be used to disambiguate the usage 
for multiple adjacencies.



Thanks,
Acee







Thanks,

In section 2.7,
Link Data = Neighbor's IP Address


2.7.  Advertising Multi-Area Adjacencies



   Multi-area adjacencies are announced as point-to-point links.  Once

   the router's multi-area adjacency reaches the FULL state, it will be

   added as a link type 1 to the Router Link State Advertisement (LSA)

   with:



  Link ID = Remote's Router ID



  Link Data = Neighbor's IP Address or IfIndex (if the underlying

  interface is unnumbered).


rfc5185  OSPF Multi-Area Adjacency

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


Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt

2020-09-15 Thread Acee Lindem (acee)
It looks like some unfortunate tab settings at least for the OSPF model...  
Note that pyang can be used for formatting.

pyang -f yang  --yang-line-length 68

On 9/15/20, 11:47 AM, "Lsr on behalf of tom petch"  wrote:

The formatting of this I-D seems to have gone wrong making it hard to read 
and review.  The indentation of successive lines of the YANG module is more 
than it usually is.  This was a problem with -01 that was not present in -02 
but has now returned in -03

Tom Petch

From: I-D-Announce  on behalf of 
internet-dra...@ietf.org 
Sent: 14 September 2020 22:15
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


Title   : YANG Data Model for Dynamic Flooding
Authors : Srinath Dontula
  Tony Li
Filename: draft-dontula-lsr-yang-dynamic-flooding-03.txt
Pages   : 26
Date: 2020-09-14

Abstract:
   This document defins YANG data models that can be used to configure
   and manage Dynamic Flooding for IS-IS and OSPF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dontula-lsr-yang-dynamic-flooding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-03

https://datatracker.ietf.org/doc/html/draft-dontula-lsr-yang-dynamic-flooding-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-dontula-lsr-yang-dynamic-flooding-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/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

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


Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-09-14 Thread Acee Lindem (acee)
The WG adoption poll has completed.  There is both quite a bit of support for 
the document as well as some who have concerns for the necessity of the TTZ 
mechanisms. Given the support as well as the fact that the draft is 
experimental track, our reading is that we have sufficient basis for 
experimentation. As discussions of IS-IS area abstraction mechanisms have 
progressed, it has become apparent that we are not going to reach consensus on 
a single mechanism. It is our feeling that having multiple mechanisms adopted 
by the WG on the experimental track is preferable to WG paralysis.

Please republish the draft as draft-ietf-lsr-isis-ttz-00.txt with experimental 
status.

Acee and Chris



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, August 18, 2020 at 10:17 AM
To: "lsr@ietf.org" 
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-09-04 Thread Acee Lindem (acee)
Speaking as WG member….

This is in no way comparable. This solution presented in the draft is full of 
holes and non-backward compatible. The problem may be solvable but the question 
is whether or not the required complexity is  worse than a problem that could 
be solved with proper network design.

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" 
Date: Friday, September 4, 2020 at 3:00 PM
To: Tony Przygienda , Aijun Wang 

Cc: Gyan Mishra , Robert Raszuk , 
Huzhibo , Aijun Wang , Peter 
Psenak , lsr , Acee Lindem 
, Xiaoyaqun 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

In support of what Tony has said, I think any comparison between what RIFT is 
doing and what is proposed in this draft is inappropriate.

RIFT is able to determine what destinations exist in the network but are not 
reachable via a certain subset of the topology – and then generate negative 
advertisements appropriately. There is also full determinism in knowing when 
the negative advertisement should be removed.

draft-wang-lsr-prefix-unreachable-announcement by contrast tries to provide an 
advertisement for a destination that no longer exists. This leads to the lack 
of determinism which necessitates arbitrary timers and creates problems for 
nodes who connect to the network after the disappearance of the destination.

Not comparable at all IMO…

   Les

From: Lsr  On Behalf Of Tony Przygienda
Sent: Friday, September 04, 2020 11:12 AM
To: Aijun Wang 
Cc: Gyan Mishra ; Robert Raszuk ; 
Huzhibo ; Aijun Wang ; Peter 
Psenak ; lsr ; Acee Lindem 
(acee) ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

I read the draft since the longish thread triggered my interest. As Peter said 
very thin ice walking with magic soft-state-timers for (to me) entirely unclear 
benefit and lots of interesting questions completely omitted like e.g. what 
will happen if a mix of old and new routers are in the network.

RIFT works completely differently BTW (and I don't think we _also_ noticed the 
problem, AFAIK RIFT is the first protocol that defined the concept of at least 
negative disaggregation to deal with black-hole avoidance in presence of 
summaries). RIFT defines precisely how negative disaggregation state is 
transitively propagated (if necessary) and next-hop resolved via recursive 
inheritance to provide black-hole and loop free routing in case of links 
failures on IP fabrics. No soft-timers or undescribed magic there. However, to 
do what RIFT is doing a sense of direction on the graph is needed (this is 
relatively easy on semi-lattice RIFT supports but would precondition uniform 
topological sorting on generic graphs, probably ending up in RPL type of 
solutions [which still need a direction indicator on arc to work and would take 
out a lot of links out of the topology possibly {but Pascal is better to judge 
that}]).

-- tony

On Mon, Aug 24, 2020 at 11:11 AM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:
Hi, Gyan:

Sorry for replying you so late.
You are right about the summary address behavior, but the summary address is 
configured by manually, and if one of the specific prefix within this summary 
range is down, the black hole(route to this specific prefix) will be formed.  
PUA mechanism just want to amend this.
Glad to know Rift has also noticed such issues.  In OSPF/ISIS, such problem 
needs also be solved.

If you are interested this topic, welcome to join us to the solution.


Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
[mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf Of Gyan 
Mishra
Sent: Thursday, August 6, 2020 4:44 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>; Robert 
Raszuk mailto:rob...@raszuk.net>>; Huzhibo 
mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Xiaoyaqun 
mailto:xiaoya...@huawei.com>>
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Aijun and authors

I am catching up with this thread after reading through this draft.

I understand the concept that we are trying to send a PUA advertisement which 
sounds similar to Rift Negative Disaggregation prefix now with a  null setting 
when a longer match component prefix that is part of a summary range is down to 
detect prefix down conditions with longer match component prefixes that are 
part of a summary.

Basically how summarization works with both OSPF and ISIS is that at minimum a 
single longer match within the defined IA summary range must exist for the IA 
summary to be sent.  So the summary is sent conditionally similar to a BGP 
conditional advertisement or even a

[Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

2020-08-18 Thread Acee Lindem (acee)
Authors,

The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here:

https://datatracker.ietf.org/ipr/4029/


Are you aware of any other IPR that applies to draft-chen-isis-ttz?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

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

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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


[Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Acee Lindem (acee)

Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.

Thanks,
Acee and Chris

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


Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02

2020-08-05 Thread Acee Lindem (acee)
Hi Tony, Bruno, Les,

From: Lsr  on behalf of Tony Li 
Date: Tuesday, August 4, 2020 at 11:26 AM
To: Bruno Decraene 
Cc: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" 

Subject: Re: [Lsr] draft-ietf-lsr-isis-area-proxy-02


Hi Bruno,




[Bruno] Agreed so far.
Do we agree that draft-ietf-lsr-isis-area-proxy uses the SID/Label sub-TLV? We 
both agree that this sub-TLV has no mention of the global flag nor the routing 
algoto be used.


So far, we do NOT have agreement on that.  Your argument yesterday (backed by 
Robert) is pretty compelling: go ahead and assign a prefix and now the Area SID 
may be advertised as a Node SID in the Proxy LSP. If we take that direction, 
this discussion is moot.

Why wouldn’t we take this approach? Since the border routers are abstracting 
the area as a node, why wouldn’t we do the same for the Node-SID?

Thanks,
Acee

Tony

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


Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Acee Lindem (acee)

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Monday, August 3, 2020 at 12:32 PM
To: Bruno Decraene , Tony Li 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

Inline.

From: bruno.decra...@orange.com 
Sent: Monday, August 03, 2020 8:52 AM
To: Les Ginsberg (ginsberg) ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Les,


From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, August 3, 2020 5:22 PM
To: DECRAENE Bruno TGI/OLN 
mailto:bruno.decra...@orange.com>>; 
tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] New Version Notification for 
draft-ietf-lsr-isis-area-proxy-02.txt

Bruno –

The concept of “Area SID” – at least to me – is “please forward to any node in 
the Area advertising the Area SID”.
[Bruno] How is that different from “anycast”? i.e. your option b?

[Les:] It would differ because it would not be associated with a prefix but 
with an area. Any node in the area could make use of the SID.

You, however, seem to be asking for either:

a)The node originating the Proxy LSP to advertise a Node SID for a loopback 
address on that node

OR

b)The node originating the Proxy LSP to advertise an anycast SID which is 
shared by the IERs in the Proxy Area

To do so, it seems to me we need not invent a new type of SID, we can simply 
advertise using the existing Prefix Reachability/Prefix SID sub-TLVs.

So it seems you are not interested in an “Area SID”.

Can you please clarify?

[Bruno] I’m interested in the forwarding behavior defined in the draft: “all of 
the Inside Edge Nodes […] should consume this SID at forwarding time.” How we 
call this, I don’t really care. Could be area SID, or proxy SID or anycast SID… 
but for the external L2 nodes, there is no anycast behavior: just one single 
node/LSP/SID, so calling it anycast could be strange.

[Les:] Agreed – which is why a new type of SID was chosen.

[Acee] I know you guys have all thought about this a lot more than myself. 
However, I’d envisioned this new Area SID as taking one to the closest entry to 
the abstracted area. The next SID in the stack would either take you to a 
destination inside the area or would use the abstracted area as transit to 
another SID.

Thanks,
Acee


For me, the reason to invent a new type of SID and new forms of SID 
advertisements is because we were defining a SID with new functionality i.e., 
send this to another area – which entry point into the area is used should not 
matter.
[Bruno] From the external L2 nodes, the “area” is seen as a single node. “which 
entry point into the area is used ” equals “which interface of the (proxy) node 
is used. I’m not sure that we need a new concept.
From within area internal nodes, we do see the detail of the topology and need 
to advertise & agree on the area SID.
[Les:] You are correct in terms of usage within Area Proxy.
But I was allowing that other use cases for Area SID might be defined in the 
future and the abstraction that is present in Area Proxy would not be relevant.
But if the proposal is to use a SID associated with a prefix then I see no need 
to invent a new SID advertisement.

This seems like a property which might be useful – and might be useful outside 
of Area Proxy use cases as well. If however, we (the WG) see no need for this 
type of SID then we should remove these definitions and simply use the existing 
Prefix-SID advertisements.
[Bruno] The property is useful. I’m fine with the name & encoding in current 
and past draft.
I’m simply raising the point that this new advertisement will not be understood 
by vanilla external L2 nodes. Hence unless you upgrade all those external 
nodes, you have regression in the network, at least in the following use case: 
replacing a big chassis with a set of smaller nodes grouped in one area.

[Les:] A fair point. But currently the draft is defining a SID which is NOT 
associated with a prefix. And you are correctly pointing out that this has an 
impact on both the IER nodes (which MUST support the Area Proxy extensions) and 
the external L2 nodes – which theoretically need not be upgraded at all.
If the impact on external nodes is unacceptable, then a prefix-SID 
advertisement MUST be used. Any new advertisement – whether associated with a 
prefix or not – would raise the same interoperability issue you mention.


One other comment regarding your reference to 
https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-03 .

https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-02#section-2.1 
already specifies that all inside nodes MUST have the “same SRGB”. So I do not 
see that your reference is relevant – unless you are proposing to change that.
[Bruno] You can safely forget about this reference.
I was trying to say that anycast SID is not new. And no, I’m not proposing to 
change that 

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)

On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" 
 wrote:



On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 18:03, Acee Lindem (acee) wrote:
> So, how do we define a reachable route - is it any route subsumed by 
the summary LSA that we knew about in the past that becomes unreachable? When 
the PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope.

I'm not suggesting the unreachable stuff to affect forwarding in any 
way.

That would be better. Also, as I stated offline, it would also be better to 
use encodings that would be ignored by routers that don't support the 
extension. I tried to dissuade the authors of PUA not to overload the 
prefix-originator LSA but was unsuccessful. 

Of course, I meant prefix-originator Sub-TLV and the existing LSAs indicating 
reachability - 
https://www.ietf.org/id/draft-ietf-lsr-ospf-prefix-originator-06.txt

Thanks,
Acee

Thanks,
Acee

thanks,
Peter


> Thanks,
> Acee
> 
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
 wrote:
> 
>  On 30/07/2020 16:30, Robert Raszuk wrote:
>  > Hey Peter,
>  >
>  > Not sure how smart you really want to be here but keep in mind 
that BGP
>  > say option C may never hear about it all the way to the egress 
PE in
>  > other domain or area ... It is almost always incongruent with 
IGP.
>  >
>  > So if the BGP path is installed it will indeed be at risk to 
resolve via
>  > less specific when it is still active BGP path and you too 
quickly
>  > remove info about unreachability.
> 
>  again, if you are smart you can use this info to your advantage, 
even
>  without putting it in the forwarding and leaving the less 
specific stuff
>  intact.
> 
>  Peter
> 
> 
>  >
>  > Thx
>  > R.
>  >
>  > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak   > <mailto:ppse...@cisco.com>> wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  >  > 2:For bgp example,when the pe node down,the bgp 
peer
>  > must down
>  >  > within
>  >  >  > 30 mintus,It will not get it up via cancle 
advertise pua.
>  >  >
>  >  > for the above it is sufficient to advertise the
>  > unreachability for few
>  >  > seconds from each ABR independently. That would be 
a much
>  > more solid
>  >  > proposal.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > implementations is 180 sec :) .. but few minutes will 
work for sure.
>  >
>  > depends how you use it.
>  >
>  > If you can use the unreachable info in a smart way, it's 
sufficient if
>  > it is present for a very short time interval.
>  >
>  > thanks,
>  > Peter
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  Lsr mailing list
>  Lsr@ietf.org
>  https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> 

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

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

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)


On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 18:03, Acee Lindem (acee) wrote:
> So, how do we define a reachable route - is it any route subsumed by the 
summary LSA that we knew about in the past that becomes unreachable? When the 
PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope.

I'm not suggesting the unreachable stuff to affect forwarding in any way.

That would be better. Also, as I stated offline, it would also be better to use 
encodings that would be ignored by routers that don't support the extension. I 
tried to dissuade the authors of PUA not to overload the prefix-originator LSA 
but was unsuccessful. 

Thanks,
Acee

thanks,
Peter


> Thanks,
> Acee
> 
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" 
 wrote:
> 
>  On 30/07/2020 16:30, Robert Raszuk wrote:
>  > Hey Peter,
>  >
>  > Not sure how smart you really want to be here but keep in mind 
that BGP
>  > say option C may never hear about it all the way to the egress PE 
in
>  > other domain or area ... It is almost always incongruent with IGP.
>  >
>  > So if the BGP path is installed it will indeed be at risk to 
resolve via
>  > less specific when it is still active BGP path and you too quickly
>  > remove info about unreachability.
> 
>  again, if you are smart you can use this info to your advantage, even
>  without putting it in the forwarding and leaving the less specific 
stuff
>  intact.
> 
>  Peter
> 
> 
>  >
>  > Thx
>  > R.
>  >
>  > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak   > <mailto:ppse...@cisco.com>> wrote:
>  >
>  > On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  >  > 2:For bgp example,when the pe node down,the bgp peer
>  > must down
>  >  > within
>  >  >  > 30 mintus,It will not get it up via cancle advertise 
pua.
>  >  >
>  >  > for the above it is sufficient to advertise the
>  > unreachability for few
>  >  > seconds from each ABR independently. That would be a 
much
>  > more solid
>  >  > proposal.
>  >  >
>  >  >
>  >  > Not sure about "few seconds" ... IBGP def hold time in 
number of
>  >  > implementations is 180 sec :) .. but few minutes will work 
for sure.
>  >
>  > depends how you use it.
>  >
>  > If you can use the unreachable info in a smart way, it's 
sufficient if
>  > it is present for a very short time interval.
>  >
>  > thanks,
>  > Peter
>  >
>  >  >
>  >  > Thx,
>  >  > R.
>  >  >
>  >
> 
>  ___
>  Lsr mailing list
>  Lsr@ietf.org
>  https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> 

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

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)
Hi Zhibo,

From: Lsr  on behalf of Huzhibo 
Date: Thursday, July 30, 2020 at 12:14 PM
To: Acee Lindem , Peter Psenak 
, Robert Raszuk 
Cc: lsr , Aijun Wang , Xiaoyaqun 
, Aijun Wang 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


HI acee:

PUA does not advertise reachable or unreachable details, it advertise events 
with prefix from up to down.

I don’t see the distinction here and it is not described in the latest version 
of the draft (posted Monday). You must be envisioning some protocol behavior 
that is yet to be documented.

Thanks,
Acee



thanks

Zhibo







--
胡志波 Hu Zhibo
Mobile: +86-18618192287
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>
发件人:Acee Lindem (acee) 
收件人:Peter Psenak ;Robert Raszuk 

抄 送:Aijun Wang ;Xiaoyaqun 
;Huzhibo ;Aijun Wang 
;lsr 
时 间:2020-07-31 00:04:02
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

So, how do we define a reachable route - is it any route subsumed by the 
summary LSA that we knew about in the past that becomes unreachable? When the 
PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope.
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 16:30, Robert Raszuk wrote:
> Hey Peter,
>
> Not sure how smart you really want to be here but keep in mind that BGP
> say option C may never hear about it all the way to the egress PE in
> other domain or area ... It is almost always incongruent with IGP.
>
> So if the BGP path is installed it will indeed be at risk to resolve via
> less specific when it is still active BGP path and you too quickly
> remove info about unreachability.

again, if you are smart you can use this info to your advantage, even
without putting it in the forwarding and leaving the less specific stuff
intact.

Peter


>
> Thx
> R.
>
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  <mailto:ppse...@cisco.com>> wrote:
>
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2:For bgp example,when the pe node down,the bgp peer
> must down
>  > within
>  >  > 30 mintus,It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
>
> depends how you use it.
>
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
>
> thanks,
> Peter
>
>  >
>  > Thx,
>  > R.
>  >
>

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Acee Lindem (acee)
So, how do we define a reachable route - is it any route subsumed by the 
summary LSA that we knew about in the past that becomes unreachable? When the 
PUA is withdrawn, how do we know whether it is because of expiration of the 
interval or the route becoming reachable again? This is a slippery slope. 
Thanks,
Acee

On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"  wrote:

On 30/07/2020 16:30, Robert Raszuk wrote:
> Hey Peter,
> 
> Not sure how smart you really want to be here but keep in mind that BGP 
> say option C may never hear about it all the way to the egress PE in 
> other domain or area ... It is almost always incongruent with IGP.
> 
> So if the BGP path is installed it will indeed be at risk to resolve via 
> less specific when it is still active BGP path and you too quickly 
> remove info about unreachability.

again, if you are smart you can use this info to your advantage, even 
without putting it in the forwarding and leaving the less specific stuff 
intact.

Peter


> 
> Thx
> R.
> 
> On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak  > wrote:
> 
> On 30/07/2020 16:14, Robert Raszuk wrote:
>  >  > 2:For bgp example,when the pe node down,the bgp peer
> must down
>  > within
>  >  > 30 mintus,It will not get it up via cancle advertise pua.
>  >
>  > for the above it is sufficient to advertise the
> unreachability for few
>  > seconds from each ABR independently. That would be a much
> more solid
>  > proposal.
>  >
>  >
>  > Not sure about "few seconds" ... IBGP def hold time in number of
>  > implementations is 180 sec :) .. but few minutes will work for 
sure.
> 
> depends how you use it.
> 
> If you can use the unreachable info in a smart way, it's sufficient if
> it is present for a very short time interval.
> 
> thanks,
> Peter
> 
>  >
>  > Thx,
>  > R.
>  >
> 

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

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


Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" -draft-lz-lsr-igp-sr-service-segments-02

2020-07-29 Thread Acee Lindem (acee)
Thanks Hannes – this is exactly what I was suggesting rather than advertising 
the BGP-LS information in the IGPs.
Acee

From: Hannes Gredler 
Date: Wednesday, July 29, 2020 at 3:14 AM
To: "liu.ya...@zte.com.cn" 
Cc: Acee Lindem , "zzhang_i...@hotmail.com" 
, "lsr@ietf.org" 
Subject: Re: [Lsr] "IGP Extensions for Segment Routing Service Segment" 
-draft-lz-lsr-igp-sr-service-segments-02

Yao,

BGP-LS was designed to solve also the distribution of link-state information 
between BGP speakers (see Figure 1 from RFC 7752 below).
Just ask yourself: why would one want to use a point to multipoint state 
replication protocol as complex as BGP for *just* client server alike 
replication ?

We wanted from day-1 to leverage the graph independent replication abilities of 
BGP - so doing inter BGP-LS graphs is a legit use-case.

HTH,

/hannes

---



   The collection of link-state and TE information and its distribution

   to consumers is shown in the following figure.



   +---+

   | Consumer  |

   +---+

 ^

 |

   +---+

   |BGP|   +---+

   |  Speaker  |   | Consumer  |

   +---+   +---+

 ^   ^   ^   ^

 |   |   |   |

 +---+   |   +---+   |

 |   |   |   |

   +---+   +---+ +---+

   |BGP|   |BGP| |BGP|

   |  Speaker  |   |  Speaker  |. . .|  Speaker  |

   +---+   +---+ +---+

 ^   ^ ^

 |   | |

IGP IGP   IGP



   Figure 1: Collection of Link-State and TE Information

---


On 29.07.2020, at 03:57, liu.ya...@zte.com.cn 
wrote:

Hi Acee,
Thanks for reading the draft.
Yes, the main purpose of this draft is to carry the segment segment information 
via IGP so only one node per AS need to be connected with the controller 
through BGP-LS.
With the existing BGP-LS extension draft, it is certainly one solution to 
configure BGP sessions between all the service function nodes and controller, 
and each node sends the SF information to the controller individually.
And if I get you right, we can also select one node to have a BGP session with 
the controller and configure BGP sessions between the selected node and SF 
nodes.
But how the selected node get the SF information from SF nodes via BGP needs to 
be solved, since BGP-LS is typically used for exchanging information between 
the south and north rather than nodes of the same level, and there's no other 
existing BGP extension for distribute SIDs information between nodes .
This draft aims to provide an alternate way if the operators prefer running IGP 
on SF nodes.
So we would like to collect comments on the WG session to see how others think 
about it.

Regards,
Yao



原始邮件
发件人:AceeLindem(acee) mailto:a...@cisco.com>>
收件人:刘尧00165286;zzhang_i...@hotmail.com 
mailto:zzhang_i...@hotmail.com>>;
抄送人:lsr@ietf.org mailto:lsr@ietf.org>>;
日 期 :2020年07月29日 01:53
主 题 :"IGP Extensions for Segment Routing Service Segment" 
-draft-lz-lsr-igp-sr-service-segments-02
Speaking as WG member:

It seems the sole purpose of this draft is to get service segment information 
from nodes in the IGP domain to the IGP node that has a BGP session with the 
controller. You don’t need to put this information into the IGP in order to do 
this. Simply configure BGP sessions for the BGP-LS AF between the nodes with 
service functions and the node selected to have a BGP session with the 
controller.

Speaking as WG Chair – please let me know if we can omit this draft from the 
agenda.

Thanks,
Acee

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

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


[Lsr] "IGP Extensions for Segment Routing Service Segment" - draft-lz-lsr-igp-sr-service-segments-02

2020-07-28 Thread Acee Lindem (acee)
Speaking as WG member:

It seems the sole purpose of this draft is to get service segment information 
from nodes in the IGP domain to the IGP node that has a BGP session with the 
controller. You don’t need to put this information into the IGP in order to do 
this. Simply configure BGP sessions for the BGP-LS AF between the nodes with 
service functions and the node selected to have a BGP session with the 
controller.

Speaking as WG Chair – please let me know if we can omit this draft from the 
agenda.

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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread Acee Lindem (acee)
An interesting encoding – note that the draft doesn’t use it for forwarding.
Acee

From: Bruno Decraene 
Date: Tuesday, July 28, 2020 at 5:51 AM
To: Robert Raszuk , Acee Lindem 
Cc: Aijun Wang , Zhibo Hu , Yaqun 
Xiao , "lsr@ietf.org" 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) 
Cc: Aijun Wang ; Zhibo Hu ; Yaqun 
Xiao ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hello Acee,

I would like to question your assessment that signalling unreachable routes is 
unnecessary.

Imagine hierarchical network with areas. Under no failures area 1 advertises to 
area 0 summary LSA with 1.1.1.0/24<http://1.1.1.0/24>. That block covers PE's 
loopbacks which within the area are /32s. Those loopbacks are also BGP next 
hops.

Now imagine PE1 with 1.1.1.1/32<http://1.1.1.1/32> fails. Well till BGP 
reconverges all paths advertised by this PE with 1.1.1.1/32<http://1.1.1.1/32> 
are still valid as this next hop is still reachable entire network wide. That 
means that traffic is being sent to this failed PE1 for relatively long period 
of time.

It seems natural that without breaking benefits of summarization across areas 
or domains in the above scenario we could continue to advertise 
1.1.1.0/24<http://1.1.1.0/24> - 1.1.1.1/32<http://1.1.1.1/32>. That is when I 
see most benefits of advertising unreachability aka negative routing.

Of course said all of the above - if you search your employer's archives - you 
will see a proposal where the above mechanism can be done within BGP itself 
with no touch to the IGP - just using a bit of twisted next hop validation 
steps and BGP native recursion. I am not going to make any judgements here 
which method is better or easier - naturally I personally like BGP one more :).

But I hope this is clear why at least discussion on the subject is important. 
It also illustrates why the below statement is not necessarily correct:

"Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR. "

Kind regards,
Robert.


On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" 
mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>> wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
mailto:xiaoya...@huawei.com>>
Subject: New Version Notification f

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread Acee Lindem (acee)
See my response to Aijun... Please provide topologies where the section 6.1 
solution doesn't work. 
Acee

On 7/27/20, 10:03 PM, "Huzhibo"  wrote:

Hi Acee:

In fact, we have meet some scenarios where redundant paths cannot be 
deployed within a area. Especially when the access area uses the nearby access 
principle, ABRs form disordered combinations, which makes it difficult to 
deploy physical or tunnel connections. In addition, advertising unreachable 
prefixes can prevent traffic detours. Of course, This draft also has some other 
attempts to use Segment Routing to automatically establish connections between 
ABRs.

Thanks

Zhibo Hu

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: Huzhibo ; Xiaoyaqun 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among 
ABRs, when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible 
solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang 
; Yaqun Xiao 
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

Abstract:
   This document describes the mechanism that can be used to announce
   the unreachable prefixes for service fast convergence.




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.

The IETF Secretariat



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


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


Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread Acee Lindem (acee)
Hi Aijun,

You did misunderstand me so let me be brief.


  1.  By summarized prefix, I mean an unreachable prefix subsumed by the 
summary advertisement. I thought this would be clear from the context of your 
draft. So my point is that signaling unreachability from one ABR is only useful 
if the subsumed prefix is reachable though another ABR.
  2.  What I’m suggesting is provide connectivity between the ABRs. For 
example, you use the tunneling defining in section 6.1 whenever a subsumed 
prefix is unreachable. Please don’t come back with another circular argument.
Thanks,
Acee

From: Aijun Wang 
Date: Monday, July 27, 2020 at 9:57 PM
To: Acee Lindem , 'Aijun Wang' , 
"lsr@ietf.org" 
Cc: 'Zhibo Hu' , 'Yaqun Xiao' 
Subject: RE: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


Hi, Acee:

Let me try to answer your concerns.

Please see the below inline.

If I missed your comments, please correct me.



Best Regards



Aijun Wang

China Telecom



-Original Message-
From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, July 28, 2020 1:51 AM
To: Aijun Wang ; lsr@ietf.org
Cc: 'Zhibo Hu' ; 'Yaqun Xiao' 
Subject: Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt



Speaking as an LSR Working Group member:



Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff.

[WAJ] Let’s confirm it is not cliff ☺, but traffic black hole that should be 
notified and repaired.



Rather than messing up OSPF and IS-IS with these complex and unnecessary 
mechanisms, it would be better to address the requirement in your network 
design.

[WAJ] section 3 of this 
draft<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3>
 has demonstrated the problem/scenarios that needs to be addressed. We think 
this will be normal phenomena in the IPv6 era.



Note that the unreachability of a given summarized prefix is only relevant if 
it is reachable through another ABR.

[WAJ] it is not the unreachability of a given summarized prefix, but the more 
specific prefix that within the summary address.



In this case, the network design should provide adequate intra-area redundancy 
to provide communications between the ABRs.

[WAJ] Even there is adequate intra-area redundancy communication between the 
ABRs, the failure of one specific prefix within the summary address that 
advertised by the ABR will lead to traffic black hole.



If this cannot be accomplished, an intra-area adjacency should be established 
over a tunnel between the ABRs in the backbone.

[WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to 
another ABR, when such ABR router can reach the specified prefix.  But this 
additional mechanism will be used only when the ABR all reach the PUA limit. If 
not, the PUA mechanism described in section 
4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4>
 can be used to guide the traffic.



Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries.

[WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t 
reach.  But there is situation that when the tunnel that is pre-established 
among ABRs, and each tunnel claim it can reach the specified prefix, the 
traffic loop may arise if the received ABR send traffic via another tunnel.



Acee



On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn>>
 wrote:



Hi, LSR experts:



We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:

1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.

2) Describe fast rerouting to avoid routing black hole.

3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.



There are also some arguments about the current solution for PUA, for 
example:

1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?

2) if not, what's the consideration? What's the other convincible solution?



Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.



Best Regards



Aijun Wang

China Telecom



-Original Message-

From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
[mailto:internet-dra...@ietf.org]

Sent: Monday, July 27, 2020 9:16 AM

To: Zhibo Hu mailto:huzh...@huawei.com>>; Aijun Wang 
mailto:wang...@chinatelecom.cn>>; Y

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-27 Thread Acee Lindem (acee)
Speaking as an LSR Working Group member:

Asking the WG precisely how to advertise prefix unreachability is the wrong 
question - it is analogous to asking whether to use a car or truck to drive off 
the edge of a cliff. Rather than messing up OSPF and IS-IS with these complex 
and unnecessary mechanisms, it would be better to address the requirement in 
your network design. Note that the unreachability of a given summarized prefix 
is only relevant if it is reachable through another ABR. In this case, the 
network design should provide adequate intra-area redundancy to provide 
communications between the ABRs. If this cannot be accomplished, an intra-area 
adjacency should be established over a tunnel between the ABRs in the backbone. 
Contrary to section 6.1, Looping is normally not a problem as ABRs should add 
back hole routes for their advertised summaries. 

Acee

On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, LSR experts:

We have uploaded the new version of this PUA(Prefix Unreachable 
Announcement) draft. The main updates are the followings:
1) Describes the solution that using tunnel to redirect traffic among ABRs, 
when all ABRs reaches the PUA limit.
2) Describe fast rerouting to avoid routing black hole.
3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS.

There are also some arguments about the current solution for PUA, for 
example:
1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to 
indicate the prefix is unreachable?
2) if not, what's the consideration? What's the other convincible solution?

Wish to hear comments and suggestions on the above issues. We will also 
have the presentation on the coming IETF LSR meeting.

Best Regards

Aijun Wang
China Telecom 

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu ; Aijun Wang ; 
Yaqun Xiao 
Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-03.txt
has been successfully submitted by Aijun Wang and posted to the IETF 
repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   03
Title:  Prefix Unreachable Announcement
Document date:  2020-07-27
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03

Abstract:
   This document describes the mechanism that can be used to announce
   the unreachable prefixes for service fast convergence.




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.

The IETF Secretariat



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

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-15 Thread Acee Lindem (acee)
Speaking as WG member…

See inline.

From: Lsr  on behalf of Uma Chunduri 
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit 
Cc: "lsr@ietf.org" , Huaimo Chen 
Subject: Re: [Lsr] Request WG adoption of TTZ



On Wed, Jul 15, 2020 at 5:22 AM Henk Smit 
mailto:henk.i...@xs4all.nl>> wrote:
Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> block or piece of an IS-IS area, which is to be abstracted. This seems
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.

I actually think not  having more configuration across the network to enable a 
new feature is more useful even if
you don't do this operation every single day (especially if you want to roll 
back).


Link-state protocols are not easy to understand. And we already
have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the
concept of an area makes things only more complex.

Agree in general.

I would say this is no more complex than what has been adopted already or the 
slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one proposal 
by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been accepted as 
WG experimental track, and given the interest/support on this particular topic
I would think it's reasonable to continue this experiment in IS-IS too as is 
done in OSPF.

I think that the two proposals that have already been adopted as experimental 
are VERY different in the way they solve the problem of better LSDB scalability 
across an IS-IS routing domain. Conversely, now that the IS-IS TTZ has adopted 
the Area Proxy mechanisms of having an Area/Zone leader generate a single LSP 
representing the Area/Zone, the two proposals are very similar. I agree with 
Henk, Les, and John that the purported advantages of TTZ are not required. 
These advantages being arbitrary abstraction boundaries and a description of 
the transition mechanisms.

Thanks,
Acee


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


Re: [Lsr] Request WG adoption of TTZ

2020-07-14 Thread Acee Lindem (acee)
Linda, 

On 7/14/20, 1:57 PM, "Linda Dunbar"  wrote:

Acee, 

Many networks have BGP or/and ISIS. 
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS 
is discussed LSR WG. 
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion 
should be in the LSR Wg, instead of RTGwg (in my opinion). 

Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But 
this TTZ zone draft is not about replacing BGP. 

But you just said "TTZ is another option?" And if IS-IS isn't running over the 
SDWAN overlay, how is IS-IS TTZ even applicable to solving any problem in SDWAN?

Thanks,
Acee

Linda 

-Original Message-
    From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one 
entity and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  
SDWAN Fabric setup. However, that is probably a topic that would be better 
addressed in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-----
    From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in 
geographically different locations to be one TTZ zone being treated as one 
Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat 
a bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a 
zone and a single node will improve customer experience. The work on TTZ should 
be moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
 wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of 
"Topology-Transparent Zone"
> 
> (TTZ for short) 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3Dreserved=0
 .
> 
> 
> 
> This draft comprises the following solutions for helping to 
improve scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
>

Re: [Lsr] Request WG adoption of TTZ

2020-07-14 Thread Acee Lindem (acee)
Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity 
and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  SDWAN 
Fabric setup. However, that is probably a topic that would be better addressed 
in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a 
bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone 
and a single node will improve customer experience. The work on TTZ should be 
moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
 wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of 
"Topology-Transparent Zone"
> 
> (TTZ for short) 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%3Dreserved=0
 .
> 
> 
> 
> This draft comprises the following solutions for helping to 
improve scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo 
node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone 
or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in 
the sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few zones to a few pseudo nodes.
> 
> 
> 
> While a zone is being abstracted (or transferred) to a single 
pseudo node,
> 
> the network is stable. There is no or minimum service interruption.
> 
> 
> 
> After abstracting a few zones to a few pseudo nodes, if we want 
to reconstruct
> 
> them, we can transfer (or roll) any of the pseudo nodes back to its 
zone smoothly
> 
> with no or minimum service interruption.
> 
> 
> 
> We had a p

Re: [Lsr] Request WG adoption of TTZ

2020-07-14 Thread Acee Lindem (acee)
Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed 
this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo 
Chen ; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  
wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. 
The proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch 
of nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
single node will improve customer experience. The work on TTZ should be moved 
forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen  
wrote:
> Hi Chris and Acee, and everyone,
> 
> 
> 
> I would like to request working group adoption of 
"Topology-Transparent Zone"
> 
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
> 
> 
> 
> This draft comprises the following solutions for helping to improve 
scalability:
> 
> 1) abstracting a zone to a single pseudo node in IS-IS,
> 
> 2) abstracting a zone to a single pseudo node in OSPF,
> 
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
> 
> 4) transferring smoothly between a zone and a single pseudo node.
> 
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
> 
> non-backbone area).
> 
> 
> 
> When a network area becomes (too) big, we can reduce its size in the 
sense
> 
> of its LSDB size through abstracting a zone to a single pseudo node or
> 
> abstracting a few zones to a few pseudo nodes.
> 
> 
> 
> While a zone is being abstracted (or transferred) to a single pseudo 
node,
> 
> the network is stable. There is no or minimum service interruption.
> 
> 
> 
> After abstracting a few zones to a few pseudo nodes, if we want to 
reconstruct
> 
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
smoothly
> 
> with no or minimum service interruption.
> 
> 
> 
> We had a prototype implementation of abstracting a zone to zone 
edges' full
> 
> mess in OSPF. The procedures and related protocol extensions for 
transferring
> 
> smoothly from a zone to zone edges' full mess are implemented and tested.
> 
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full 
mess
> 
> without any routing disruptions. The routes on every router are stable 
while
> 
> the zone is being transferred to its edges' mess. It is very easy to 
operate
> 
> the transferring.
> 
> 
> 
> There are two other drafts for improving scalability: "Area Proxy for 
IS-IS"
> 
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
short).
> 
> 
> 
> "Area Proxy" 
https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
> 
> abstracts an existing IS-IS L1 area to a single pseudo node.
> 
> 
> 
> "Flood Reflection" 
https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
> 
> abstracts an existing IS-IS L1 area to its edges' connections via one or 
more
> 
> flood reflectors.
> 
> 
> 
> We believe that TTZ has some special advantages even though
> 
> Area Proxy and Flood Reflection are very worthy. We would like
> 
> to ask for working group adoption of TTZ.
> 
> 
> 
> Best Regards,
> 
> Huaimo
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> 

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-14 Thread Acee Lindem (acee)
Hi Les, Roman, 

On 7/14/20, 7:15 AM, "Roman Danyliw"  wrote:

Hi Les and Acee!

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Monday, July 13, 2020 11:43 PM
    > To: Acee Lindem (acee) ; Roman Danyliw ;
> The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: RE: [Lsr] Roman Danyliw's No Objection on 
draft-ietf-lsr-isis-invalid-tlv-
> 02: (with COMMENT)
> 
> Roman (and Acee) -
> 
> After a suggestion from Ben, I have reworded the sentence to read:
> 
> " When new protocol behaviors are specified that are not backwards
>compatible, it is RECOMMENDED that implementations provide controls
>for their enablement.  This serves to prevent interoperability issues
>and allow for non-disruptive introduction of the new functionality
>into an existing network."
> 
> Let me know if this resolves the concerns.

I appreciate the quick response.  No need to further debate the definition 
of "controls".  The proposal above resolves my concerns. Thank you!

This works for me.

Thanks,
Acee

Regards,
Roman

>Les
> 
> 
> > -Original Message-
> > From: Acee Lindem (acee) 
> > Sent: Monday, July 13, 2020 9:38 AM
> > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > ; The IESG 
> > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org;
> > draft- ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > Subject: Re: [Lsr] Roman Danyliw's No Objection on
> > draft-ietf-lsr-isis-invalid-
> > tlv-02: (with COMMENT)
> >
> >
> >
> > On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)" 
> > wrote:
> >
> > Acee -
> >
> > Inline.
> >
> > > -Original Message-
> > > From: Acee Lindem (acee) 
> > > Sent: Monday, July 13, 2020 9:04 AM
> > > To: Les Ginsberg (ginsberg) ; Roman Danyliw
> > > ; The IESG 
> > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com;
> > cho...@chopps.org;
> > draft-
> > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > > Subject: Re: [Lsr] Roman Danyliw's No Objection on
> > draft-ietf-lsr-isis-
> > invalid-
> > > tlv-02: (with COMMENT)
> > >
> > > Hi Les,
> > >
> > > On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" 

> > > wrote:
> > >
> > > Roman -
> > >
> > > Thanx for the review.
> > > Inline.
> > >
> > > > -Original Message-
> > > > From: Lsr  On Behalf Of Roman Danyliw 
via
> > > > Datatracker
> > > > Sent: Monday, July 13, 2020 7:40 AM
> > > > To: The IESG 
> > > > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com;
> cho...@chopps.org;
> > > draft-
> > > > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > > > Subject: [Lsr] Roman Danyliw's No Objection on 
draft-ietf-lsr-isis-
> > invalid-
> > > tlv-
> > > > 02: (with COMMENT)
> > > >
> > > > Roman Danyliw has entered the following ballot position for
> > > > draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> > > >
> > > >
> > >  

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Acee Lindem (acee)


On 7/13/20, 12:23 PM, "Les Ginsberg (ginsberg)"  wrote:

Acee -

Inline.

> -Original Message-
    > From: Acee Lindem (acee) 
> Sent: Monday, July 13, 2020 9:04 AM
> To: Les Ginsberg (ginsberg) ; Roman Danyliw
> ; The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: Re: [Lsr] Roman Danyliw's No Objection on 
draft-ietf-lsr-isis-invalid-
> tlv-02: (with COMMENT)
> 
> Hi Les,
> 
> On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)" 
> wrote:
> 
> Roman -
> 
> Thanx for the review.
> Inline.
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Roman Danyliw via
> > Datatracker
> > Sent: Monday, July 13, 2020 7:40 AM
> > To: The IESG 
> > Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org;
> draft-
> > ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> > Subject: [Lsr] Roman Danyliw's No Objection on 
draft-ietf-lsr-isis-invalid-
> tlv-
> > 02: (with COMMENT)
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> >
> >
> >
> > 
--
> > COMMENT:
> > 
--
> >
> > I'm glad to see language clarifying error handling.  Thanks for the 
work on
> it.
> >
> > Section 3.2.  Per “It is RECOMMENDED that implementations provide
> controls
> > for
> > the enablement of behaviors that are not backward compatible”, I 
want
> to
> > double
> > check that I’m understanding this  sentence correctly. RFC5304 
provides
> > normative guidance that isn’t backward compatible with ISO10589.
> RFC6233
> > provide guidance that isn’t backward compatible with either RFC5304 
or
> > ISO10589.  Is the initial sentence effectively saying that 
implementations
> > should support deployments in configurations that are not backward
> > compatible
> > (i.e., those using the newer TLVs)?  As these changes are covering
> security
> > matters, I read “controls” in the cyber mitigation sense -- they 
prevent an
> > action, not enable one.
> 
> [Les:] The recommendation is for implementations to provide control 
as to
> when the new (non-backwards compatible) behavior is used.
> Without that, an implementation which adds support for (to use one
> example) sending the Purge Originator TLV in the presence of MD5
> authentication would simply start sending it and risk the PDU not being
> accepted by implementations which had not yet added the support.
> 
> One way of reading this is that "including the POI TLV in purges w MD5
> authentication" is "enablement" of a new feature. Another way of reading 
it
> might be "disablement" of the use of a new feature.
> This seems to me to be a semantical distinction.
> 
> The recommendation to use "controls" also does not specify what the
> default behavior should be - that is up to the implementation.
> 
> Since there was some confusion, maybe "configurable specification" would
> be clearer than "controls".
> 
[Les:] I will certainly wait for Roman's input, but to me the term 
"controls" means there is a way to control whether a particular behavior is 
used/not used. (An "on/off" switch comes to mind.)
Frankly, I don’t know what the term "configuration specification" means. 
Maybe if I wo

Re: [Lsr] Roman Danyliw's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)

2020-07-13 Thread Acee Lindem (acee)
Hi Les, 

On 7/13/20, 11:53 AM, "Les Ginsberg (ginsberg)"  wrote:

Roman -

Thanx for the review.
Inline.

> -Original Message-
> From: Lsr  On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Monday, July 13, 2020 7:40 AM
> To: The IESG 
> Cc: lsr-cha...@ietf.org; aretana.i...@gmail.com; cho...@chopps.org; draft-
> ietf-lsr-isis-invalid-...@ietf.org; lsr@ietf.org
> Subject: [Lsr] Roman Danyliw's No Objection on 
draft-ietf-lsr-isis-invalid-tlv-
> 02: (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-lsr-isis-invalid-tlv-02: 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-lsr-isis-invalid-tlv/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I'm glad to see language clarifying error handling.  Thanks for the work 
on it.
> 
> Section 3.2.  Per “It is RECOMMENDED that implementations provide controls
> for
> the enablement of behaviors that are not backward compatible”, I want to
> double
> check that I’m understanding this  sentence correctly. RFC5304 provides
> normative guidance that isn’t backward compatible with ISO10589. RFC6233
> provide guidance that isn’t backward compatible with either RFC5304 or
> ISO10589.  Is the initial sentence effectively saying that implementations
> should support deployments in configurations that are not backward
> compatible
> (i.e., those using the newer TLVs)?  As these changes are covering 
security
> matters, I read “controls” in the cyber mitigation sense -- they prevent 
an
> action, not enable one.

[Les:] The recommendation is for implementations to provide control as to 
when the new (non-backwards compatible) behavior is used.
Without that, an implementation which adds support for (to use one example) 
sending the Purge Originator TLV in the presence of MD5 authentication would 
simply start sending it and risk the PDU not being accepted by implementations 
which had not yet added the support.

One way of reading this is that "including the POI TLV in purges w MD5 
authentication" is "enablement" of a new feature. Another way of reading it 
might be "disablement" of the use of a new feature.
This seems to me to be a semantical distinction.

The recommendation to use "controls" also does not specify what the default 
behavior should be - that is up to the implementation.

Since there was some confusion, maybe "configurable specification" would be 
clearer than "controls".

Thanks,
Acee

   Les

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

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


Re: [Lsr] Request WG adoption of TTZ

2020-07-08 Thread Acee Lindem (acee)
On PTO so will be brief… Inline

From: Huaimo Chen 
Date: Tuesday, July 7, 2020 at 11:22 PM
To: Acee Lindem , Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo
________
From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 4:33 PM
To: Huaimo Chen ; Christian Hopps 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



Hi Huaimo,



Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.



1.   You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an 
update to RFC 8099.



Just not in the IS-IS TTZ draft. OSPF and IS-IS have different protocol 
mechanisms and completely different terminology.

Thanks,

Acee



2.   The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS 
as a specific LSP to represent a multi-access network. I don’t know if the 
usage of the terminology was meant to differentiate the mechanisms from Area 
Proxy but I find the repurposing of the term pseudo-node in the context of 
IS-IS very confusing.
[HC]: We will change it to another term.

3.   The document keeps referring to  “edges full mess” and I believe you 
mean “edges full mesh”.
[HC]: You are right. It should be "edges full mesh".



Thanks,

Acee



From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred

Re: [Lsr] Request WG adoption of TTZ

2020-07-08 Thread Acee Lindem (acee)
Huaimo,
The LSR WG has been discussing IS-IS Area Abstraction in the context of 
flooding overhead in DC topologies for over a year now. Why are you are trying 
to hijack this discussion in favor of OSPF Area Abstraction??? The fact that 
your draft includes some OSPF encodings is NOT a differentiating feature in the 
context of this discussion. In fact, both Chris and I have asked that you 
remove the OSPF encodings from your IS-IS TTZ draft. Furthermore, if you want 
to respin RFC 8099 applying the IS-IS Area proxy mechanisms to OSPF, that is a 
totally separate discussion.
Thanks,
Acee

From: Huaimo Chen 
Date: Tuesday, July 7, 2020 at 8:42 PM
To: Acee Lindem , Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee and Chris,

Thank you very much for your comments.


> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.



Thanks,

Acee

There are really some differences between TTZ and Area Proxy, which are 
listed below for OSPF and IS-IS:
Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
defined in the Area Proxy draft) include:
1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF TTZ 
abstracts a zone to a single pseudo node. This abstraction is supported by the 
extensions to OSPF, and some of these extensions are not defined in OSPF Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in OSPF Area Proxy.
2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece or 
block of an OSPF area. An OSPF area is different from a zone in general.
3). The ways in which they are applied to an OSPF area for scalability are 
different. When an OSPF area becomes bigger and bigger, we may have scalability 
issues. Using OSPF TTZ, we can abstract one or a few zones in the OSPF area to 
one or few pseudo nodes smoothly without any interface down. Using OSPF Area 
Proxy, we need split the existing OSPF area into multiple OSPF areas, and then 
abstract one or a few OSPF areas to one or few pseudo nodes. Some people may 
like the one step operation in OSPF TTZ. Others may like the two step 
operations in OSPF Area Proxy.
4). The user experiences are different. For splitting an existing OSPF area 
into multiple OSPF areas, users may need put more efforts since it causes 
service interruptions in general. While splitting an OSPF area into multiple 
OSPF areas, the area numbers configured on some interfaces will be changed and 
each of these interfaces will be down with its old area number and then up with 
its new area number. These interface downs and ups will cause service 
interruptions in general. For defining zones in an OSPF area, users may need 
less efforts since abstracting a zone to a single pseudo node is smooth without 
any interface down.
5). OSPF TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.

Best Regards,
Huaimo
________
From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen ; Christian Hopps 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.



Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To:

Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Acee Lindem (acee)
Speaking as WG member:

Hi Huaimo,

Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.


  1.  You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as 
a specific LSP to represent a multi-access network. I don’t know if the usage 
of the terminology was meant to differentiate the mechanisms from Area Proxy 
but I find the repurposing of the term pseudo-node in the context of IS-IS very 
confusing.
  3.  The document keeps referring to  “edges full mess” and I believe you mean 
“edges full mesh”.


Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> 

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

2020-07-07 Thread Acee Lindem (acee)
Gunter is on vacation... 
Thanks,
Acee

On 7/6/20, 1:14 PM, "Amanda Baber via RT"  wrote:

Hi Ketan, Peter,

I believe we're waiting for Gunter to approve as the remaining expert, but 
we can move ahead if Peter confirms that we don't need to wait.

Best regards,
Amanda

On Mon Jul 06 03:46:02 2020, ket...@cisco.com wrote:
> Hi Amanda/All,
> 
> I thought that there was an agreement to assign bit 0x0010 for
> draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for draft-ietf-lsr-
> dynamic-flooding?
> 
> Thanks,
> Ketan
> 
> -Original Message-
>  From: Amanda Baber via RT 
    > Sent: 04 July 2020 07:53
> To: Acee Lindem (acee) 
> Cc: Peter Psenak (ppsenak) ; mraj...@juniper.net;
> lsr@ietf.org; Ketan Talaulikar (ketant) ;
> gunter.van_de_ve...@nokia.com; aretana.i...@gmail.com;
> alvaro.ret...@futurewei.com; acee=40cisco@dmarc.ietf.org
> Subject: [IANA #1173602] Re: IANA early allocation request for draft-
> ietf-lsr-ospf-bfd-strict-mode
> 
> Hi Peter, all,
> 
> > > For both Peter and Gunter: the Flooding Request bit registration is
> > > described in the registry as a temporary allocation, but this may
> > > have been an mistake The RFC 7120 temporary early allocation
> > > procedure is meant for registries that require RFC publication for
> > > permanent registration. In theory, if the experts agree, permanent
> > > registrations can be made in Expert Review registries at any time.
> > > Would there be an issue with removing the "TEMPORARY" designation
> > > from that registration?
> >
> > please go ahead and remove the TEMPORARY.
> 
> The "TEMPORARY" designation has been removed from the draft-ietf-lsr-
> dynamic-flooding registration in LLS Type 1 Extended Options and
> Flags, currently still assigned 0x0010:
> 
> https://www.iana.org/assignments/ospf-lls-tlvs
> 
> thanks,
> Amanda


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


Re: [Lsr] Request WG adoption of TTZ

2020-07-07 Thread Acee Lindem (acee)
Speaking as WG member:

I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.

Thanks,
Acee
From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can 

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

2020-07-02 Thread Acee Lindem (acee)
Right - the in-progress dynamic flooding implementations are IS-IS rather than 
OSPF. I agree that moving the OSPF dynamic flooding is safter. 

Thanks,
Acee

On 7/2/20, 3:49 AM, "Ketan Talaulikar (ketant)"  wrote:

+1

-Original Message-
From: Peter Psenak  
Sent: 02 July 2020 13:11
    To: Acee Lindem (acee) ; iana-prot-pa...@iana.org
Cc: lsr@ietf.org; Ketan Talaulikar (ketant) ; 
gunter.van_de_ve...@nokia.com; alvaro.ret...@futurewei.com
Subject: Re: [IANA #1173602] Re: IANA early allocation request for 
draft-ietf-lsr-ospf-bfd-strict-mode

Hi Ketan, Acee,

On 01/07/2020 23:24, Acee Lindem (acee) wrote:
> Hi Amanda,
> 
> On 7/1/20, 5:10 PM, "Amanda Baber via RT"  
wrote:
> 
>  Hi Acee, Alvaro, all,
> 
>  Alvaro: can you approve the request for early registration of the 
B-bit in the LLS Type 1 Extended Options and Flags registry at 
https://www.iana.org/assignments/ospf-lls-tlvs?
> 
>  Acee, Ketan: the document says that it's registering 0x0010, but 
that value was allocated to draft-ietf-lsr-dynamic-flooding last year. If 
Alvaro approves, should we register 0x0020 instead?

I doubt there is any OSPF implementation of 
draft-ietf-lsr-dynamic-flooding, so it may be safer to use the
0x0010 for draft-ietf-lsr-ospf-bfd-strict-mode and 0x0020 for 
draft-ietf-lsr-dynamic-flooding.

thanks,
Peter

> 
> Yes. While a few implementations have the BFD strict-mode configuration, 
I don't believe any have shipped the LLS signaling yet.
> 
>  Acee, Ketan, Gunter, Peter: because it's using a different 
registration procedure, I'm creating a separate ticket for the Link Local 
Signalling TLV Identifiers (LLS Types) registration. I'll send an expert review 
request from that ticket.
> 
> Fine - Thanks,
> Acee
> 
>  Best regards,
> 
>  Amanda Baber
>  Lead IANA Services Specialist
> 
>  On Wed Jul 01 19:38:00 2020, a...@cisco.com wrote:
>  > Hi Ketan,  IANA, Alvaro,
>  > I don't see any problem with early allocation of this LLS bit and 
TLV
>  > - pretty straight forward. It would make sense to put the 
respective
>  > registries in the IANA section (included below for info).
>  >
>  > Open Shortest Path First (OSPF) Link Local Signalling (LLS) -
>  > Type/Length/Value Identifiers (TLV)
>  >   Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
>  >   IETF Review
>  >   LLS Type 1 Extended Options and Flags RFC 5613
>  >  Expert Review (Expert: Gunter Van De Velde, Peter 
Psenak)
>  >
>  > For the flag, the designated experts are Gunter and Peter (copied).
>  >
>  > Please initiate the early allocation process pending expert and AD
>  > approval.
>  > Thanks,
>  > Acee
>  >
>  > On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)" 
>  > wrote: ts
>  >
>  > Hello Acee/Chris,
>  >
>  > The authors would like to request IANA early allocations for this
>  > draft.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  >  From: Ketan Talaulikar (ketant)
>  > Sent: 30 June 2020 14:25
>  > To: lsr@ietf.org
>  > Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-
>  > 01.txt
>  >
>  > Hi All,
>  >
>  > This is mostly a refresh with editorial updates. We look forward to
>  > review and feedback.
>  >
>  > Thanks,
>  > Ketan (on behalf of co-authors)
>  >
>  > -Original Message-
>  > From: Lsr  On Behalf Of 
internet-dra...@ietf.org
>  > Sent: 30 June 2020 14:20
>  > To: i-d-annou...@ietf.org
>  > Cc: lsr@ietf.org
>  > Subject: [Lsr] I-D Action: 
draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
>  >
>  >
>  > A New Internet-Draft is available from the on-line Internet-Drafts
>  > directories.
>  > This draft is a work item of the Link State Routing WG of the IETF.
>  >
>  > Title   : OSPF Strict-Mode for BFD
>  > Authors : Ketan Talaulikar
>  >   Peter Psenak
>  >

Re: [Lsr] [IANA #1173602] Re: IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

2020-07-01 Thread Acee Lindem (acee)
Hi Amanda, 

On 7/1/20, 5:10 PM, "Amanda Baber via RT"  wrote:

Hi Acee, Alvaro, all,

Alvaro: can you approve the request for early registration of the B-bit in 
the LLS Type 1 Extended Options and Flags registry at 
https://www.iana.org/assignments/ospf-lls-tlvs?

Acee, Ketan: the document says that it's registering 0x0010, but that 
value was allocated to draft-ietf-lsr-dynamic-flooding last year. If Alvaro 
approves, should we register 0x0020 instead?

Yes. While a few implementations have the BFD strict-mode configuration, I 
don't believe any have shipped the LLS signaling yet. 

Acee, Ketan, Gunter, Peter: because it's using a different registration 
procedure, I'm creating a separate ticket for the Link Local Signalling TLV 
Identifiers (LLS Types) registration. I'll send an expert review request from 
that ticket.

Fine - Thanks,
Acee

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Wed Jul 01 19:38:00 2020, a...@cisco.com wrote:
> Hi Ketan,  IANA, Alvaro,
> I don't see any problem with early allocation of this LLS bit and TLV
> - pretty straight forward. It would make sense to put the respective
> registries in the IANA section (included below for info).
> 
> Open Shortest Path First (OSPF) Link Local Signalling (LLS) -
> Type/Length/Value Identifiers (TLV)
>   Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
>   IETF Review
>   LLS Type 1 Extended Options and Flags RFC 5613
>  Expert Review (Expert: Gunter Van De Velde, Peter Psenak)
> 
> For the flag, the designated experts are Gunter and Peter (copied).
> 
> Please initiate the early allocation process pending expert and AD
> approval.
> Thanks,
> Acee
> 
> On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)" 
> wrote: ts
> 
> Hello Acee/Chris,
> 
> The authors would like to request IANA early allocations for this
> draft.
> 
> Thanks,
> Ketan (on behalf of co-authors)
> 
> -Original Message-
>  From: Ketan Talaulikar (ketant)
> Sent: 30 June 2020 14:25
> To: lsr@ietf.org
> Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-
> 01.txt
> 
> Hi All,
> 
> This is mostly a refresh with editorial updates. We look forward to
> review and feedback.
> 
> Thanks,
> Ketan (on behalf of co-authors)
> 
> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: 30 June 2020 14:20
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
> Title   : OSPF Strict-Mode for BFD
> Authors : Ketan Talaulikar
>   Peter Psenak
>   Albert Fu
>   Rajesh M
> Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
> Pages   : 10
> Date: 2020-06-30
> 
> Abstract:
>This document specifies the extensions to OSPF that enable an OSPF
>router to signal the requirement for a Bidirectional Forwarding
>Detection (BFD) session prior to adjacency formation.  Link-Local
>Signaling (LLS) is used to advertise this requirement of "strict-
>mode" of BFD session establishment for OSPF adjacency.  If both
> OSPF
>neighbors advertise the "strict-mode" of BFD, adjacency formation
>will be blocked until a BFD session has been successfully
>established.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-
> mode-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-
> 01
> 
> 
> 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/
> 
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 


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


Re: [Lsr] IANA early allocation request for draft-ietf-lsr-ospf-bfd-strict-mode

2020-07-01 Thread Acee Lindem (acee)
Hi Ketan,  IANA, Alvaro, 
I don't see any problem with early allocation of this LLS bit and TLV - pretty 
straight forward. It would make sense to put the respective registries in the 
IANA section (included below for info). 

Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value 
Identifiers (TLV)
  Link Local Signalling TLV Identifiers (LLS Types) RFC 5613
  IETF Review
  LLS Type 1 Extended Options and Flags RFC 5613
 Expert Review (Expert: Gunter Van De Velde, Peter Psenak)

For the flag, the designated experts are Gunter and Peter (copied). 

Please initiate the early allocation process pending expert and AD approval.
Thanks,
Acee

On 6/30/20, 4:58 AM, "Ketan Talaulikar (ketant)"  wrote: ts

Hello Acee/Chris,

The authors would like to request IANA early allocations for this draft.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Ketan Talaulikar (ketant) 
Sent: 30 June 2020 14:25
To: lsr@ietf.org
Subject: RE: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt

Hi All,

This is mostly a refresh with editorial updates. We look forward to review 
and feedback.

Thanks,
Ketan (on behalf of co-authors)

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: 30 June 2020 14:20
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : OSPF Strict-Mode for BFD
Authors : Ketan Talaulikar
  Peter Psenak
  Albert Fu
  Rajesh M
Filename: draft-ietf-lsr-ospf-bfd-strict-mode-01.txt
Pages   : 10
Date: 2020-06-30

Abstract:
   This document specifies the extensions to OSPF that enable an OSPF
   router to signal the requirement for a Bidirectional Forwarding
   Detection (BFD) session prior to adjacency formation.  Link-Local
   Signaling (LLS) is used to advertise this requirement of "strict-
   mode" of BFD session establishment for OSPF adjacency.  If both OSPF
   neighbors advertise the "strict-mode" of BFD, adjacency formation
   will be blocked until a BFD session has been successfully
   established.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-ospf-bfd-strict-mode-01
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-bfd-strict-mode-01


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/


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

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


Re: [Lsr] draft-ietf-lsr-flex-algo

2020-06-30 Thread Acee Lindem (acee)
Speaking as WG chair:

I'm delighted to see discussion on a draft that isn't in WG last call.

Speaking as WG member:

Maybe I'm missing something but do we really think we’re going to run out of 
non-flexible algorithms with 128? I just don't see it happening in my lifetime. 

Thanks,
Acee



On 6/30/20, 12:27 PM, "Lsr on behalf of Peter Psenak"  wrote:

Hi Bruno,

On 30/06/2020 18:08, bruno.decra...@orange.com wrote:
> Hi Peter,
> 
> Thanks for your reply.
> 
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>>
>> Hi Bruno,
>>
>> please see inline:
>>
>> On 30/06/2020 16:53, bruno.decra...@orange.com wrote:
>>> Hi all,
>>>
>>> I can live with the current text, but I'm just raising the point for 
discussion
>> (better safe than sorry).
>>>
>>> "16.1.1.  IGP Algorithm Types Registry
>>>
>>>  This document makes the following registrations in the "IGP 
Algorithm
>> Types" registry:
>>>
>>> Type: 128-255.
>>>
>>> Description: Flexible Algorithms.
>>> "
>>> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07#section-16.1.1
>>>
>>> This is essentially burning half of the registry for flex-algo. Indeed, 
any
>> network operator could use any value, e.g. 222, hence the IETF could 
never
>> define a different usage for this value without creating interop issues 
for the
>> network operator.
>>
>> what is the real problem? Is the space 2-127 that is free not sufficient
>> for other standardized algorithms that may come?
>>
>>>
>>> We could discuss whether we really need 127 values for this. (i.e. a
>> network operator requiring 127 flex algo, typically multiplying its IGP 
FIB
>> entries by 127...).
>>
>> above is not necessarily true and more importantly completely irrelevant
>> to the number of algos we reserve for FA.
>>
>>
>>> We could also discuss whether this range could be change to the IANA 
well-
>> known "Private Use" [1]. This would allow for alternative private usages 
in
>> the future (e.g. Flexible Alorithms v2).
>>> [1] https://tools.ietf.org/html/rfc8126#section-4.1
>>>
>>> It seems to me that the latter would equally work for flex algo, but 
would
>> provide more flexibility :-) for the future.
>>
>> I don't think so. We need an allocated range of algos for FA for
>> compatibility.
> 
> The allocated range of algos for FA would be the same. Just not dedicated 
to FA.

this would not work. If I have a mix of routers, one set using value 222 
for flex-algo and another set for something else, how are they going to 
interoperate?

We need a standardized range, using Private Use is not an option here.

thanks,
Peter

> 
> --Bruno
>   
>>
>> thanks,
>> Peter
>>>
>>> Regards,
>>> --Bruno
>>>
>>>
>> __
>> __
>> _
>>>
>>> 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.
>>>
>>> ___
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>>
> 
> 
> 
_
> 
> 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 

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-invalid-tlv-02

2020-06-26 Thread Acee Lindem (acee)
Hi Ron, 
Thanks for the review.
Acee

On 6/26/20, 1:36 PM, "Ron Bonica via Datatracker"  wrote:

Reviewer: Ron Bonica
Review result: Ready

This draft is well tought out and ready for publication



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


Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-18 Thread Acee Lindem (acee)
Hi Les, Deborah,
I agree with Les. Especially since we’ve discussed and evolved these encodings 
in the LSR WG for over 3 years now. With the zero-length attribute bit mask, we 
essentially have the equivalent of the legacy advertisements, as well as all 
the limitations. As long as configuration is provided to dictate which 
encodings are used, I don’t see that the draft needs to specify the default.
Thanks,
Acee


From: "Les Ginsberg (ginsberg)" 
Date: Wednesday, June 17, 2020 at 7:18 PM
To: Deborah Brungard , The IESG 
Cc: "draft-ietf-isis-te-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Acee Lindem , Alvaro Retana 
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Deborah –

We have a protocol extension that provides alternative ways of supporting 
legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to 
which advertisements they use.
There is nothing in the document to specify which choice is the default – nor 
should there be.
To do so  implies that you believe that an implementation which is otherwise 
compliant (i.e., it sends/receives TLVs in accordance with the specification) 
could or should be considered in violation of the specification because it 
chose to use new advertisements as the default with an option to select legacy 
advertisements rather than use legacy advertisements as the default with an 
option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is 
likely to change over time. Initially the existence of legacy routers will be 
large and the upgraded routers few. This argues for legacy being the default. 
But a few years down the road and the numbers will be reversed – in which case 
the “better” default will be “new”. Declaring conformant implementations in 
violation simply because they decide to align their defaults with their most 
common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of 
the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially 
it made sense to default to old style advertisements – but over time it made 
more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what 
we should do here.

I also take issue with your assumption that a default MUST be specified in the 
corresponding YANG model. I am far from a YANG expert – and will happily defer 
to those with more experience – but I see no reason why this cannot be modeled 
as a leaf which can take on one enumerated value – but there need not be a 
default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A 
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Les-

To shortcut the discussion on the need for adding a default for “control”, 
these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require 
implementations to provide controls specifying which type of advertisements are 
to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”



[Les:] What is being described here is a “hitless transition strategy”. It is 
wrong to assume that the use of “enable” here means that the default is 
“disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy 
only.

None of this says or implies anything about what defaults are nor what config 
commands (if any) were needed to place the box in the state specified at Step 1.



This document is not a vendor configuration guide – and I do not want to make 
it one.



Les





If one is “enabling” then the default is “OFF”? So this document already 
assumes it. I don’t understand the reluctance to add also to section 6.1.1. 
When the YANG model is defined, this will be the config default. So either you 
specify now or later – later, may result in every vendor/platform having a 
different default if they don’t read section 6.3.3. That will be a major 
interoperability problem – even potentially among the same vendor for different 
platforms.



This same comment is for the OSPF document – it needs to specify a default.



More notes below.

Thanks,
Deborah

[Les:] “Legacy” refers to routers which do not support the extensions defined 
in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all 
of the applications discussed in 

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-13 Thread Acee Lindem (acee)
Speaking as WG  member:

I support WG adoption of this draft on the experimental track. I think it is 
better for the WG to move forward and get some data points on these competing 
solutions than to be gridlocked.

Thanks,
Acee

On 6/10/20, 3:28 PM, "Christian Hopps"  wrote:

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.


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


Re: [Lsr] WG adoption call for draft-przygienda-lsr-flood-reflection-01

2020-06-13 Thread Acee Lindem (acee)
Speaking as WG  member: 

I support WG adoption of this draft on the experimental track. I think it is 
better for the WG to move forward and get some data points on these competing 
solutions than to be gridlocked. 

I'm not that concerned with the tunneling requirement for L1/L2 routers given 
that this can be accomplished very easily with segment routing (e.g., as in 
TI-LFA). 

One technical comment:

   If the client has a direct L2 adjacency with the flood reflector it SHOULD 
  use it instead of instantiating a new tunnel.

Perhaps this would be clearer:

If the client has a direct L1 adjacency with the flood reflector it SHOULD
not instantiate a tunnel for the L2 flooding reflector adjacency. 

Thanks,
Acee
   


On 6/10/20, 3:29 PM, "Christian Hopps"  wrote:

This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any 
IPR that applies to this draft.

Thanks,
Chris and Acee.

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


Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-13 Thread Acee Lindem (acee)
Hi Deborah,

I hope Les has assuaged your concerns with the RSVP-TE encoding. We have 
discussed these drafts in the LSR WG extensively and our intention is not to 
force upgrade. We are encouraging use of the more modern encodings while 
providing backward compatibility. This is even more important in OSPF where 
fewer LSAs for the same link will need to be correlated – for OSPFv3 Extended 
LSAs, all the link information will be advertised in a single LSA.

Thanks,
Acee

From: Deborah Brungard 
Date: Saturday, June 13, 2020 at 9:22 AM
To: Acee Lindem 
Cc: "Les Ginsberg (ginsberg)" , The IESG , 
"draft-ietf-isis-te-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Alvaro Retana 
Subject: Re: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Hi Acee,

Thanks- I didn’t mean processed in TEAS, I meant a heads up at least at WG Last 
Call. They also are doing SR routing (RFC8426).

Ok, if no impact on RSVP-TE routers is the intention, as I noted, the draft 
should clarify it is discussing legacy SR routers. I agree with you this is 
then not an RFC update. Most important, the default does need to be specified 
as off. Otherwise as Bruno noted, this puts a huge burden on the operators and 
it then is an update.

Thanks,
Deborah
Sent from my iPhone


On Jun 12, 2020, at 9:05 PM, Acee Lindem (acee)  wrote:
Hi Deborah,


Point of process…

From: Deborah Brungard 
Date: Friday, June 12, 2020 at 7:15 PM
To: "Les Ginsberg (ginsberg)" , The IESG 
Cc: "draft-ietf-isis-te-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Acee Lindem , Alvaro Retana 
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Hi Les,

On my Discuss, that’s good.

On my comments, I’m still confused then on the scope of the draft. If it was 
(2) below only, it would seem that this is an extension of current capabilities 
(my first reading). Considering (1), “unambiguously”, and the use of the terms 
“legacy” and “all routers are upgraded” in the document, I wonder why this is 
not considered an update to RFC5305 – is this updating RSVP-TE routers too? If 
not, and it is only referring to (legacy) SR routers which are doing “legacy 
advertisements” then I would agree this would not be an update as there is no 
RFC saying how an SR router should advertise.

Depending on the intention, it would really help to clarify “legacy”, e.g., it 
is not an RSVP-TE router but a router with SR capabilities still doing “legacy” 
advertisements. I think Bruno was trying to say this in his rtgdir review. It 
is really confusing, e.g., here in Section 3, suggest:
Section 3. Legacy Advertisements/s/Legacy SR Advertisements, and “in support of 
RSVP-TE”/s/”in support of SR” (as it’s an SR “legacy” router)

But if the intention is to upgrade ALL RSVP-TE routers too, and this is an 
UPDATE to 5305, here can say “in support of RSVP-TE and SR”. Though if this is 
the intention, it clashes with 6.1 where it says there is no need to do 
anything for RSVP-TE.


For 6.1, the 2nd bullet, you should add: RSVP-TE is not deployed/s/RSVP-TE is 
not deployed or planned to be deployed. Here, I agree with Bruno, you really 
need to provide guidance on “control”, otherwise you will most likely not have 
interoperability. Suggest: The default SHALL be use of legacy advertisements. 
Otherwise this is an UPDATE to 5305 as different vendors will choose different 
defaults.



If this is updating RSVP-TE routers, this should have been shared with TEAS (I 
don’t recall anything).



RFC 5305 is an IS-IS WG (now LSR WG) document NOT a TEAS document. It doesn’t 
impact RSVP-TE procedure per se – only the IGP protocol encoding of the 
attributes which is under the purview of the LSR WG.



Thanks,

Acee



Thanks,
Deborah

From: Les Ginsberg (ginsberg) 
Sent: Thursday, June 11, 2020 11:05 AM
To: BRUNGARD, DEBORAH A ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)


Deborah -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Deborah Brungard via Datatracker 
> mailto:nore...@ietf.org>>

> Sent: Wednesday, June 10, 2020 3:17 PM

> To: The IESG mailto:i...@ietf.org>>

> Cc: draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>; 
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
> lsr@ietf.org<mailto:lsr@ietf.org>; Acee

> Lindem (acee) mailto:a...@cisco.com>>; 
> aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; Acee Lindem

> (acee) mailto:a...@cisco.com>>

> Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

>

> Deborah Brungard has entered th

Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

2020-06-12 Thread Acee Lindem (acee)
Hi Deborah,

Point of process…

From: Deborah Brungard 
Date: Friday, June 12, 2020 at 7:15 PM
To: "Les Ginsberg (ginsberg)" , The IESG 
Cc: "draft-ietf-isis-te-...@ietf.org" , 
"lsr-cha...@ietf.org" , "lsr@ietf.org" , 
Acee Lindem , Alvaro Retana 
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)

Hi Les,

On my Discuss, that’s good.

On my comments, I’m still confused then on the scope of the draft. If it was 
(2) below only, it would seem that this is an extension of current capabilities 
(my first reading). Considering (1), “unambiguously”, and the use of the terms 
“legacy” and “all routers are upgraded” in the document, I wonder why this is 
not considered an update to RFC5305 – is this updating RSVP-TE routers too? If 
not, and it is only referring to (legacy) SR routers which are doing “legacy 
advertisements” then I would agree this would not be an update as there is no 
RFC saying how an SR router should advertise.

Depending on the intention, it would really help to clarify “legacy”, e.g., it 
is not an RSVP-TE router but a router with SR capabilities still doing “legacy” 
advertisements. I think Bruno was trying to say this in his rtgdir review. It 
is really confusing, e.g., here in Section 3, suggest:
Section 3. Legacy Advertisements/s/Legacy SR Advertisements, and “in support of 
RSVP-TE”/s/”in support of SR” (as it’s an SR “legacy” router)

But if the intention is to upgrade ALL RSVP-TE routers too, and this is an 
UPDATE to 5305, here can say “in support of RSVP-TE and SR”. Though if this is 
the intention, it clashes with 6.1 where it says there is no need to do 
anything for RSVP-TE.


For 6.1, the 2nd bullet, you should add: RSVP-TE is not deployed/s/RSVP-TE is 
not deployed or planned to be deployed. Here, I agree with Bruno, you really 
need to provide guidance on “control”, otherwise you will most likely not have 
interoperability. Suggest: The default SHALL be use of legacy advertisements. 
Otherwise this is an UPDATE to 5305 as different vendors will choose different 
defaults.



If this is updating RSVP-TE routers, this should have been shared with TEAS (I 
don’t recall anything).



RFC 5305 is an IS-IS WG (now LSR WG) document NOT a TEAS document. It doesn’t 
impact RSVP-TE procedure per se – only the IGP protocol encoding of the 
attributes which is under the purview of the LSR WG.



Thanks,

Acee



Thanks,
Deborah

From: Les Ginsberg (ginsberg) 
Sent: Thursday, June 11, 2020 11:05 AM
To: BRUNGARD, DEBORAH A ; The IESG 
Cc: draft-ietf-isis-te-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee 
Lindem (acee) ; aretana.i...@gmail.com
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with 
DISCUSS and COMMENT)


Deborah -



Thanx for your review.

Responses inline.



> -Original Message-

> From: Deborah Brungard via Datatracker 
> mailto:nore...@ietf.org>>

> Sent: Wednesday, June 10, 2020 3:17 PM

> To: The IESG mailto:i...@ietf.org>>

> Cc: draft-ietf-isis-te-...@ietf.org<mailto:draft-ietf-isis-te-...@ietf.org>; 
> lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; 
> lsr@ietf.org<mailto:lsr@ietf.org>; Acee

> Lindem (acee) mailto:a...@cisco.com>>; 
> aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>; Acee Lindem

> (acee) mailto:a...@cisco.com>>

> Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

>

> Deborah Brungard has entered the following ballot position for

> draft-ietf-isis-te-app-14: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU=Sxxeqg1sPR25hOlFdq6FdXJ9FDoxb36lV9tKE8EC6ZI=>

> 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-isis-te-app/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Disis-2Dte-2Dapp_=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=6UhGpW9lwi9dM7jYlxXD8w=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU=NU8WByfd9_z3-C2bkJPB9eCdI-EuaRt4JQL5MFWKnEc=>

>

>

>

> --

> DISCUSS:

> --

>

> This should be simple to resolve - the use of the SR-TE term is

> out-of-alignment with other drafts

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-11 Thread Acee Lindem (acee)
Thanks Sarah – as a co-author, please state your awareness of IPR.
Acee

From: Sarah Chen 
Date: Thursday, June 11, 2020 at 2:34 PM
To: Robert Raszuk 
Cc: Christian Hopps , "lsr@ietf.org" , 
"lsr-...@ietf.org" , "lsr-cha...@ietf.org" 

Subject: Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
Resent-From: 
Resent-To: Christian Hopps , Acee Lindem , 
Yingzhen Qu 
Resent-Date: Thursday, June 11, 2020 at 2:33 PM

Support, as co-author.

Thanks,
Sarah

On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps 
mailto:cho...@chopps.org>> wrote:
This begins a 2 week WG adoption call for the following draft:

  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Thanks,
Chris and Acee.

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


[Lsr] FW: Nomcom 2020-2021 Second Call For Volunteers

2020-06-11 Thread Acee Lindem (acee)
FYI – Please consider volunteering for NOMCOM.

Thanks,
Acee


Begin forwarded message:
From: NomCom Chair 2020 
Date: June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List 
Cc: "i...@ietf.org" 
Subject: Nomcom 2020-2021 Second Call For Volunteers
This is the second sending of the call for volunteers for the 2020-2021 NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks ago):
- I've fixed the URL at the bottom of the email to point to 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_nomcom_2020_=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=NgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34=
  instead of /2019/. This was a test to see if anyone was paying attention. 
Apparently, some people were. ;)
- The IETF 108 registration form includes a checkbox that will let you 
volunteer. You can use this instead of emailing me, when you register for IETF 
108.
- I currently have 39 volunteers. Last year had 149. I need more volunteers!
-
The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, 
the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random way from 
a pool of volunteers. The more volunteers, the better chance we have of 
choosing a random yet representative cross section of the IETF population.

The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). 
RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788 (one-off 
update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

 Members of the IETF community must have attended at least three of
 the last five in-person IETF meetings in order to volunteer.

 The five meetings are the five most recent in-person meetings that
 ended prior to the date on which the solicitation for NomCom
 volunteers was submitted for distribution to the IETF community.
 Because no IETF 107 in-person meeting was held, for the 2020-2021
 Nominating Committee those five meetings are IETFs
   102 [Montreal, Canada; July 2018],
   103 [Bangkok, Thailand; November 2018],
   104 [Prague, Czech Republic; March 2019],
   105 [Montreal, Canada; July 2019], and
   106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the five 
listed meetings. You can check your eligibility at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_registration_nomcom.py=DwIDaQ=LFYZ-o9_HUMeMTSQicvjIg=LoGzhC-8sc8SY8Tq4vrfog=ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI=7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo=
 .

If you qualify, please volunteer. Before you decide to volunteer, please 
remember that anyone appointed to this NomCom will not be considered as a 
candidate for any of the positions that the 2020 - 2021 NomCom is responsible 
for filling.

People commonly volunteer by ticking the box on IETF registration forms. The 
IETF 106 form did not ask whether people were willing to volunteer. IETF 107 
did ask, but all those registrations were canceled. I have asked the 
Secretariat if it is possible to get the list if volunteers from canceled IETF 
107 registrations. If that list is available, I will contact all who are 
verified as eligible. But given the uncertainty of this process, I would 
encourage people to volunteer directly (see the bottom of this email for 
instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF meeting, 
and thus the positions for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja Andjelkovic

IAB:
   Jari Arkko
   Jeff Tantsura
   Mark Nottingham
   Stephen Farrell
   Wes Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
   Deborah Brungard, RTG AD
   Éric Vyncke, INT AD
   Magnus Westerlund, TSV AD
   Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the General 
area has 1; all other areas have 2 ADs. Thus, all areas (that have more than 
one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should be 
completed in January 2021.  The NomCom will have regularly scheduled conference 
calls to ensure progress. There will be activities to collect requirements from 
the community, review candidate questionnaires, review feedback from community 
members about candidates, and talk to candidates.

While being a NomCom member does require some time commitment it is also a very 
rewarding experience.

As a member of the NomCom it is very important that you be willing and able to 
attend either videoconference or in-person meetings (which may not happen) 
during 14-20 November (IETF 109 - 

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-ospf-te-link-attr-reuse-14: (with COMMENT)

2020-06-09 Thread Acee Lindem (acee)
Hi Peter, Murray, 

On 6/9/20, 6:53 AM, "Peter Psenak"  wrote:

Hi Murray,

thanks for your comments, please see inline:

On 08/06/2020 08:00, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ospf-te-link-attr-reuse-14: 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-te-link-attr-reuse/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Three main things from me:
> 
> (1) I found I'm in agreement below with some of the points raised in the 
posted
> OPSDIR review.  Please give that another once-over.

which ones in particular? I've responded to all of them, so it's hard 
for me to figure out which ones do you have in mind.

I think I've changed all the instances where "which" was being used with a 
defining clause. See attached diff.

Thanks,
Acee

> 
> (2) A grammatical point: I think nearly every instance in this document of
> "which" should be replaced by "that".

I let this be checked by the English language experts :)

> 
> (3) In Section 12.3.3, I don't think it's appropriate to use MUST-type 
language
> to constrain future document authors.

What we are saying is that if there is a router in the network that does 
not understand this new way of advertising the link attributes, all 
routers MUST continue to advertise it in the old way (on top of possibly 
advertising new way). What constrain would this pose to future documents?


> 
> And now, my nit-storm:
> 
> Section 1:
> * "... attribute advertisements - examples of which ..." -- hyphen should 
be a
> comma * "... for a link that is not enabled for RSV-TE." -- s/RSV/RSVP/ * 
"...
> path via that link it will result ..." -- comma after "link"

fixed.

> 
> Section 3:
> * Please define, or provide a reference for, "GMPLS".


fixed

> 
> Section 4.1:
> * "... not inspected by OSPF, that acts as ..." -- s/that/which instead/
> 

fixed

> Section 5:
> * Several changes to this paragraph suggested:
> OLD:
> On top of advertising the link attributes for standardized
> applications, link attributes can be advertised for the purpose of
> application that is not defined as standardized one.  We call such
> application a user defined application.  What such application might
> be is not subject to the standardization and is outside of the scope
> of this specification.
> NEW:
> On top of advertising the link attributes for standardized
> applications, link attributes can be advertised for the purpose of
> applications that are not standardized.  We call such an
> application a "User Defined Application" or "UDA".  These 
applications are
> not subject to standardization and are outside of the scope
> of this specification.

done.

> 
> * Is the snapshot of the current content of the Link Attribute Application
> Identifier Registry needed?  The rest of the document doesn't seem to 
reference
> it. * 

I believe it is useful to mention it here.


"... to advertise all UDAs." -- although it's fairly clear at this point
> what a UDA is, I suggest defining it somewhere above, maybe by hanging it 
off
> one of the other places where the full name is used such as in the 
paragraph
> above


I thought the edited paragraph

"On top of advertising the link attributes for standardized 
applications"

defines UDAs clearly.



> 
> Section 6.1:
> * Please expand "IPFRR" on first use.

done

> 
> Section 6.2:
> * "All these can be used ..." -- s/All/All of/

fixed.

> 
> Section 11:
> * "- e.g.  RSVP-TE -" -- comma after "e.g."
> * "... one need to make sure ..." -- s/need/needs/
> * "... applications, where the enablement ..." -- remove comma
> * "... such application - e.g.  LFA." -- change to "such application.  An
> example of this is LFA."

fixed

> 
> Section 12.3.4:
> * "Link attributes that are NOT allowed  ..." -- s/NOT/not/

fixed.

thanks,
Peter
> 
> 
> 
> 
> 


<<< text/html; name="Diff_ draft-ietf-ospf-te-link-attr-reuse-14.txt.orig - 

Re: [Lsr] Genart last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-06-09 Thread Acee Lindem (acee)
Hi Linda,
One more point... 

On 6/9/20, 4:52 AM, "Peter Psenak"  wrote:

Linda,

On 09/06/2020 02:37, Linda Dunbar wrote:
> Peter,
> 
> Thank you very much for adding the extra text to explain.
> 
> But SR is supposed to be transparent to all intermediate nodes. Does your 
draft require a node to be specifically configured for each link to support or 
not support SR or RSVP-TE?

the draft does not pose any new requirements in terms of how 
applications are enabled.

Please note that RSVP-TE is typically enabled per interface, SRTE is 
typically enabled on a per node basis.

For SR, these attributes are attributes are advertised in OSPF so that any OSPF 
router or controller in the OSPF domain can make use of them to compute the SR 
path. 

Thanks,
Acee


> 
> In addition, there is no new attributes described in the document. So if 
a node is advertising TE related attributes for a specific link, such as 
bandwidth, delay,  what kind problems this node will encounter if a remote node 
utilize those TE specific attributes?

the problem is when the link attributes advertise for the purpose of 
application other than RSVP-TE is mistakenly used by RSVP-TE.

thanks,
Peter



> 
> Linda Dunbar
> 
> -Original Message-
> From: Peter Psenak 
> Sent: Monday, June 1, 2020 11:01 AM
> To: Linda Dunbar ; gen-...@ietf.org
> Cc: last-c...@ietf.org; lsr@ietf.org; 
draft-ietf-ospf-te-link-attr-reuse@ietf.org
> Subject: Re: Genart last call review of 
draft-ietf-ospf-te-link-attr-reuse-12
> 
> Hi Linda,
> 
> 
> On 01/06/2020 17:30, Linda Dunbar wrote:
>> Peter,
>> You said:
>> /“//the problem with existing advertisement is that RSVP-TE will use
>> it, even if it was not intended to be used by RSVP-TE.//”/ What is the
>> problem if RSVP-TE use the advertisement? What specific attributes
>> that RSVP-TE shouldn’t use?
> 
> Following text has been added to the draft based on comments from Scott.
> 
> "An example where this ambiguity causes problem is a network which has 
RSVP-TE enabled on one subset of links, and SRTE enabled on a different subset. 
A link attribute is advertised for the purpose of some other application (e.g. 
SRTE) for a link that is not enabled for RSV-TE. As soon as the router that is 
an RSVP-TE head-end sees the link attribute being advertised for such link, it 
assumes RSVP-TE is enabled on that link, even though in reality, RSVP-TE is not 
enabled on it. If such RSVP-TE head-end router tries to setup an RSVP-TE path 
via link where RSVP-TE is not enabled it will result in the path setup failure."
> 
> Hope it makes it clear and addresses your question.
> 
> thanks,
> Peter
> 
> 
> 
> 
> 
>> Linda Dunbar
>> -Original Message-
>> From: Peter Psenak 
>> Sent: Friday, May 29, 2020 10:00 AM
>> To: Linda Dunbar ; gen-...@ietf.org
>> Cc: last-c...@ietf.org; lsr@ietf.org;
>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> Subject: Re: Genart last call review of
>> draft-ietf-ospf-te-link-attr-reuse-12
>> Linda,
>> On 29/05/2020 16:52, Linda Dunbar wrote:
>>> Peter,
>>> You said:
>>> /we are not defining any new attributes./ /We are allowing an
>>> existing link attributes to be used by other applications, including,
>>> but not limited to SRTE./ What prevent a node (or an application on
>>> the node) receiving the LSA from using the attributes carried by the 
LSA?
>> the problem with existing advertisement is that RSVP-TE will use it,
>> even if it was not intended to be used by RSVP-TE.
>> We are providing a way to explicitly advertised apps that are allowed
>> to use the advertised attributes.
>>> If no new attributes are
>>> to be added, then why need a new ASLA sub-TLV?
>> to be able to use the existing attributes for new apps, other than 
RSVP-TE.
>> thanks,
>> Peter
>>> Linda
>>> -Original Message-
>>> From: Peter Psenak mailto:ppse...@cisco.com>>
>>> Sent: Friday, May 29, 2020 5:51 AM
>>> To: Linda Dunbar >> >;
>> gen-...@ietf.org 
>>> Cc: last-c...@ietf.org ; lsr@ietf.org
>> ;
>>> draft-ietf-ospf-te-link-attr-reuse@ietf.org
>> 
>>> Subject: Re: Genart last call review of
>>> draft-ietf-ospf-te-link-attr-reuse-12
>>> Hi Linda,
>>> On 28/05/2020 19:02, Linda Dunbar via Datatracker wrote:
 Reviewer: Linda Dunbar
 Review result: Not 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.  

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-06-06 Thread Acee Lindem (acee)
The WG adoption call has completed and the document has significant support for 
adoption. I’m anticipating that we’ll have more than one algorithm document so 
it would be better to have a less generic name. For example, 
draft-ietf-lsr-flooding-topo-min-degree.txt. The replaces meta-data can be set 
independent of the WG document name so we have freedom here.

Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, May 15, 2020 at 3:40 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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


Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-06-06 Thread Acee Lindem (acee)
Hi Huaimo,

From: Huaimo Chen 
Date: Friday, June 5, 2020 at 9:03 PM
To: Acee Lindem , "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Acee,

Thank you very much for your valuable comments.
My answers/explanations are inline below.

Best Regards,
Huaimo

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Friday, June 5, 2020 12:52 PM
To: lsr@ietf.org 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Speaking as WG Member:



Hi Authors,



I have a couple technical comments on the draft.



1.  The algorithm only computes a single graph with single path to each 
node. While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
[HC]: The flooding topology (or say a graph) computed by the algorithm has at 
least two paths to each node. At step 4 of the algorithm on page 5 of the 
draft, for each node B that has only one path to it on the flooding topology 
(i.e., the Degree of node B is one) , another path is added to it. Thus the 
final flooding topology (or say graph) computed by the algorithm has  two or 
more paths to every node.

Ok – I see this now.





2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
[HC]: You are right. All the routers must use the same value for MaxD. We will 
update the draft for this accordingly. For now, MaxD has an initial value of 3 
(i.e., every router uses this initial value of 3 for MaxD).  The algorithm 
increases MaxD by one and restarts to compute the flooding topology with this 
new MaxD if it can not compute a flooding topology with the old MaxD. After 
some iterations in some cases, the flooding topology is computed. It is a good 
idea to pass some parameters from the area leader to every router when the 
leader advertises the algorithm number to every router.  MaxD can be one of the 
parameters.

3.   Similarly, the constraints in section 4.2 must be applied uniformly 
and different constraints would require new IANA algorithm allocation.
[HC]: You are right. All the routers must use the same constraints.  A new (or 
different) set of constraints need a new algorithm number. We will update the 
draft for this accordingly.



I see you’ve updated this in the latest.



Thanks,

Acee



Thanks,
Acee



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, May 15, 2020 at 3:40 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7C1a7e82ec42fa40a9ad8e08d80970ea4c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637269727959858751=eG3iR27JyxGL6qCsqlMow47twBhMpf0%2BsgJo6Q9hBJg%3D=0>



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


  1   2   3   4   5   6   >