Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Susan Hares]

Jeff:

 

I agree your BGP-LS only deployment in the MSD document were not well defined.  
  

 

Starting a new set of work to define BGP-LS use in BGP-only is important.  If 
this document start the process to refine how BGP-only works, this will help 
defined this usage.   I stand by the agreement that the BGP-LS that exposes the 
OSPF/ISIS Link MTU proposal can be adopted in LSR.  However, this discussion 
has confirmed that the BGP-LS support for BGP-only needs some BGP focus. 

 

If there are other drafts on this topic, it would be good to suggest this 
drafts on the list.   Ketan suggested he had one. 

 

Cheers, Sue 

 

 

From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
Sent: Friday, November 13, 2020 8:52 PM
To: Les Ginsberg (ginsberg)
Cc: Ketan Talaulikar (ketant); Susan Hares; Stephane Litkowski (slitkows); 
i...@ietf.org; Acee Lindem (acee); lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

To add to Les’s point of BGP only scenario, during MSD IESG reviews, BGP-LS 
only deployment was found not well characterized and had been removed from the 
draft. It will require much better discussion to have it included.

Regards,

Jeff





On Nov 13, 2020, at 15:57, Les Ginsberg (ginsberg)  wrote:

 

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

 

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

 

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

 

>From my perspective, WG adoption of this draft in ANY WG is premature.

This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

 

So I therefore oppose WG adoption of this draft by IDR.

 

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.

At that point we could then have a far more meaningful WG adoption call.

 

   Les

 

 

From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

Hi Authors,

 

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

 

Hi Sue,

 

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR. 

 

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

 

The MTU sub-TLV is used to optionally announce the MTU of a link as

   specified in [RFC6325], Section 
  4.2.4.4.

 

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

 

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

 

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

 

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and 

Re: [Lsr] [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Susan Hares]

Les: 

 

As you know, part of the chair’s duty is to determine if the authors have 
missed mentioning something in their draft proposal.  My questions were about 
the BGP-only features since it seemed obvious to me after working with the 
draft-ietf-idr-tunnel-encaps as a shepherd.   BGP has had direct routes since 
BGP-v3.  

 

There is appears to be interest in working on the BGP-only network and this 
topic.   The authors plan to resubmit the draft with a different name and 
details on BGP-only.  

 

One way to accomplish the evaluation of the “BGP only” service is to extend 
this WG Adoption call 1 week to allow discussion of that the revision that 
contains that information.   

 

Cheerily, Susan Hares 

 

 

 

 

 

 

 

 

From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 
Sent: Friday, November 13, 2020 6:58 PM
To: Ketan Talaulikar (ketant); Susan Hares; 'Jeff Tantsura'; 'Stephane 
Litkowski (slitkows)'; i...@ietf.org; 'Acee Lindem (acee)'
Cc: lsr@ietf.org
Subject: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend upon the TRILL 
specific MTU-probe/MTU-ack procedures defined in 
https://www.rfc-editor.org/rfc/rfc6325#section-4.4.3. These procedures are not 
currently applicable to non-TRILL environments.

 

So, there are no existing IGP advertisements defined which can support the 
goals of this draft.

 

As Ketan has also indicated, there is no discussion in the draft of how a BGP 
only network (for example) could provide the information of interest.

 

>From my perspective, WG adoption of this draft in ANY WG is premature.

This might be a useful functionality to have – but at the moment we simply have 
an idea with no definition of how to implement/deploy it.

 

So I therefore oppose WG adoption of this draft by IDR.

 

Continuing the discussion is certainly useful – and I would encourage the 
current authors to investigate and propose relevant mechanisms in all the 
protocols of interest in some future version of the draft.

At that point we could then have a far more meaningful WG adoption call.

 

   Les

 

 

From: Idr  On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, November 13, 2020 1:35 AM
To: Susan Hares ; 'Jeff Tantsura' ; 
'Stephane Litkowski (slitkows)' ; 
i...@ietf.org; 'Acee Lindem (acee)' 
Cc: lsr@ietf.org
Subject: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

 

Hi Authors,

 

I believe this work is useful and should be taken up. It has value in providing 
the link MTU as part of the topology information via BGP-LS. However, as 
pointed out by others on this thread, the draft should remain scoped to just 
that – i.e. providing link MTU information. The discussion related to Path MTU 
and applicability to SR networks are best left outside the scope of this 
standards track draft.

 

Hi Sue,

 

I would support the points made by Acee for not taking up this draft in IDR WG 
and instead doing this in LSR. 

 

Besides the missing coverage for OSPFv2/v3, there are also issues with how this 
would work with ISIS. The reference to the ISIS Trill specification points to 
this TLV https://tools.ietf.org/html/rfc7176#section-2.4 – if you see, there is 
more here than just the MTU value. What is more critical is the ISIS procedures 
(in non-Trill deployments) on how this value is determined. Please do not mix 
the following :

 

The MTU sub-TLV is used to optionally announce the MTU of a link as

   specified in [RFC6325], Section 
  4.2.4.4.

 

Are the authors trying to specify that these Trill procedures for testing MTU 
need to be adopted for regular ISIS deployments.

 

My take is that while the ISIS TLV defined for Trill may be re-used in normal 
ISIS deployments, its usage and procedures need to be specified. Copying the 
LSR WG so that I may be corrected if I am wrong here.

 

Coming to the point of BGP-only networks, the draft has zero text related to 
that scenario. Moreover, the procedures for BGP-LS advertisements in BGP only 
fabric need to be specified as a base. The 
https://datatracker.ietf.org/doc/draft-ketant-idr-bgp-ls-bgp-only-fabric/ was 
my attempt to specify those procedures and it would be great if the IDR WG 
could review and provide feedback to this document and consider for adoption so 
we can cover the BGP-only networks.

 

I would also like to offer support/help to the authors in adding the necessary 
OSPFv2/v3 support for the same in an LSR draft where we could tackle both the 
IGPs and BGP-LS encoding and procedures together.

 

Thanks,

Ketan

 

From: Idr  On Behalf Of Susan Hares
Sent: 13 November 2020 00:20
To: 'Jeff Tantsura' ; 'Stephane Litkowski (slitkows)' 
; i...@ietf.org; 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Aijun Wang]

Hi, Robert:

 

Does the following responses satisfy your concerns If I understand your 
questions correctly? 

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Robert 
Raszuk
Sent: Monday, November 16, 2020 4:04 AM
To: Jeff Tantsura 
Cc: lsr ; Aijun Wang ; Acee Lindem 
(acee) 
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

 

Jeff, 

 

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 if you intend to use unreachable prefixes in data plane as result you need 
to break summary into as atomic prefixes as your unreachable advertisement 
mask. 

[WAJ] When the number of unreachable prefixes is limited(this is the common 
situation),  Summary Route+PUA is the most efficient solution.

 

Hence my recommendation to use IGP to flood unreachable only for the purpose of 
control plane (namely BGP paths invalidation). 

[WAJ]  PUA and “Smart Disaggregation” in RIFT aim to the same problems, but 
there are some differences:

1. In RIFT, the parallel node will advertise the detailed prefix when it 
detects that another node on the same level can’t reach the mentioned prefix. 
But for PUA, the decision/advertisement is made by the ABR node itself that 
knows the failure of links/nodes. 

2. The advertisement information is different. In RIFT, the detail prefix 
information is advertised(by another node that can reach the failure prefix); 
in PUA, the detail unreachable prefix information is advertised instead(by the 
node that can’t reach the failure prefix). 

 After knowing this information, the receiver node can switch the path to send 
the traffic, or trigger the BGP control plane switchover as you said.

 

Cheers,

R.

 

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura mailto:jefftant.i...@gmail.com> > wrote:

As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather 
 unfortunate, in RIFT disaggregation is conditional and well contained within 
its context, it doesn’t  affect overall scalability.

Regards,

Jeff





On Nov 15, 2020, at 08:44, Robert Raszuk mailto:rob...@raszuk.net> > wrote:



Hi Aijun,

 

I would in fact only propose that the presented mechanism is narrowed down to 
invalidate BGP (service) routes - in fact their next hops. 

 

The reason being that the moment you make the solution generic, moreover the 
moment you want it to be used in RIB and data plane I am afraid you are running 
into similar (even if local) deaggregation mechanism like recently described in 
RIFT. That would kill all the scalability of advertising summary routes in the 
first place and I bet would face lots of opposition. 

 

Thx,

R.

 

I would actually trim most use cases leaving just one - to signal remote 
service node (ex: PE) going down in the presence of summary route being 
advertised from remote area or pop. 

 [WAJ] Yes, this may be the most useful use case, but the PUA mechanism can 
also apply to other scenarios. We want to make it one general solution.

___
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 for draft-wang-lsr-hbh-process-00

[wangyali]

Hi Huanan,

Thanks for your review and comments. Please see inline [Yali].

Please feel free let us know your thoughts.

From: chenhu...@chinatelecom.cn [mailto:chenhu...@chinatelecom.cn]
Sent: Monday, November 16, 2020 10:00 AM
To: wangyali ; lsr@ietf.org
Subject: Re: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hello WG and Authors,
 I have read the draft.
 It is a good idea to use IGP extension to notification the HBH ablility.
 Commments as follow:

1. How to enable the IGP extensions for HBH？
[Yali] The Hop-by-Hop Options header processing action TLVs defined in this 
draft, for example, can be enabled in IGP through configuration.

2. Does the IGP use the HBH option as criterion to genernate a new topology?
[Yali] The topology are not changed and affected. Such advertisements can allow 
entities (e.g. centralized controllers) to exclude nodes that are not 
HbH-capable when paths are computed for specific services. For example, if you 
need a private line that must be measured by IOAM or IFIT, you can exclude 
nodes that are not HbH-capable during path computation for making sure 
performance data can be collected and exported at every HbH-capable nodes in 
the private line.

BR.
Huanan Chen

From: wangyali
Date: 2020-10-29 21:19
To: lsr@ietf.org
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hello WG,

Considering the Hop-by-Hop Options header has been used for IOAM 
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method 
[I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the 
Hop-by-Hop Options header is only examined and processed if it is explicitly 
configured. In this case, nodes may be configured to ignore the Hop-by-Hop 
Options header, drop packets containing a Hop-by-Hop Options header, or assign 
packets containing a Hop-by-Hop Options header to a slow processing path. Thus, 
the performance measurement does not account for all links and nodes along a 
path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, 
which gravely deteriorates network performance.

Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop 
Options header processing action at node and link granularity. Such 
advertisement is useful for entities (e.g., the centralized controller) to 
gather each router's processing action for achieving the computation of TE 
paths that be able to support a specific service encoded in the Hop-by-Hop 
Options header.

Please let us know your opinion. Questions and comments are very welcome.

Best regards,
Yali


-Original Message-
From: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; 
Huzhibo mailto:huzh...@huawei.com>>; wangyali 
mailto:wangyal...@huawei.com>>
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt


A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.

Name:   draft-wang-lsr-hbh-process
Revision:   00
Title:  IGP Extensions for Advertising Hop-by-Hop Options Header 
Processing Action
Document date:  2020-10-29
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt
Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process
Htmlized:   https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00


Abstract:
   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  Such advertisements
   allow entities (e.g., centralized controllers) to determine whether
   the Hop-by-Hop Options header and specific services can be supported
   in a given network.





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] New Version for draft-wang-lsr-hbh-process-00

[chenhu...@chinatelecom.cn]

Hello WG and Authors,
 I have read the draft.
 It is a good idea to use IGP extension to notification the HBH ablility.
 Commments as follow:
 1. How to enable the IGP extensions for HBH？
 2. Does the IGP use the HBH option as criterion to genernate a new topology? 

BR.
Huanan Chen

From: wangyali
Date: 2020-10-29 21:19
To: lsr@ietf.org
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00
Hello WG,
 
Considering the Hop-by-Hop Options header has been used for IOAM 
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method 
[I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the 
Hop-by-Hop Options header is only examined and processed if it is explicitly 
configured. In this case, nodes may be configured to ignore the Hop-by-Hop 
Options header, drop packets containing a Hop-by-Hop Options header, or assign 
packets containing a Hop-by-Hop Options header to a slow processing path. Thus, 
the performance measurement does not account for all links and nodes along a 
path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, 
which gravely deteriorates network performance.
 
Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop 
Options header processing action at node and link granularity. Such 
advertisement is useful for entities (e.g., the centralized controller) to 
gather each router's processing action for achieving the computation of TE 
paths that be able to support a specific service encoded in the Hop-by-Hop 
Options header.
 
Please let us know your opinion. Questions and comments are very welcome.
 
Best regards,
Yali
 
 
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou ; Huzhibo ; 
wangyali 
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt
 
 
A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.
 
Name:   draft-wang-lsr-hbh-process
Revision:   00
Title:  IGP Extensions for Advertising Hop-by-Hop Options Header 
Processing Action
Document date:  2020-10-29
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-hbh-process-00.txt
Status: https://datatracker.ietf.org/doc/draft-wang-lsr-hbh-process/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-wang-lsr-hbh-process
Htmlized:   https://tools.ietf.org/html/draft-wang-lsr-hbh-process-00
 
 
Abstract:
   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  Such advertisements
   allow entities (e.g., centralized controllers) to determine whether
   the Hop-by-Hop Options header and specific services can be supported
   in a given network.
 
 
 
 
 
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] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-01.txt

[Ron Bonica]

FYI


Juniper Business Use Only

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Sunday, November 15, 2020 6:52 PM
> To: Shraddha Hegde ; Peter Psenak
> ; Ron Bonica ; Parag Kaneriya
> ; Rajesh M ; William Britto A J
> 
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-01.txt
> 
> [External Email. Be cautious of content]
> 
> 
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-01.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
> repository.
> 
> Name:   draft-bonica-lsr-ip-flexalgo
> Revision:   01
> Title:  IGP Flexible Algorithms (Flex-Algorithm) In IP Networks
> Document date:  2020-11-15
> Group:  Individual Submission
> Pages:  17
> URL:
> https://www.ietf.org/archive/id/draft-bonica-lsr-ip-flexalgo-01.txt
> Status:
>  https://datatracker.ietf.org/doc/draft-bonica-lsr- ip-flexalgo
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft bonica-lsr-ip-flexalgo


> Abstract:
>An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
>constraint-based paths.  As currently defined, IGP Flex-Algorithm is
>used with Segment Routing (SR) data planes - SR MPLS and SRv6.
>Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
> 
>This document extends IGP Flex-Algorithm, so that it can be used for
>regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm 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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Jeff Tantsura]

Thanks for clarification Robert, makes sense.

Cheers,
Jeff
On Nov 15, 2020, 12:03 PM -0800, Robert Raszuk , wrote:
> Jeff,
>
> 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.
>
> So if you intend to use unreachable prefixes in data plane as result you need 
> to break summary into as atomic prefixes as your unreachable advertisement 
> mask.
>
> Hence my recommendation to use IGP to flood unreachable only for the purpose 
> of control plane (namely BGP paths invalidation).
>
> Cheers,
> R.
>
> > On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura  
> > wrote:
> > > As RIFT chair - I’d like to respond to Robert’ comment -  the example is 
> > > rather  unfortunate, in RIFT disaggregation is conditional and well 
> > > contained within its context, it doesn’t  affect overall scalability.
> > >
> > > Regards,
> > > Jeff
> > >
> > > > On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
> > > >
> > > > > Hi Aijun,
> > > > >
> > > > > I would in fact only propose that the presented mechanism is narrowed 
> > > > > down to invalidate BGP (service) routes - in fact their next hops.
> > > > >
> > > > > The reason being that the moment you make the solution generic, 
> > > > > moreover the moment you want it to be used in RIB and data plane I am 
> > > > > afraid you are running into similar (even if local) deaggregation 
> > > > > mechanism like recently described in RIFT. That would kill all the 
> > > > > scalability of advertising summary routes in the first place and I 
> > > > > bet would face lots of opposition.
> > > > >
> > > > > Thx,
> > > > > R.
> > > > >
> > > > > > > > I would actually trim most use cases leaving just one - to 
> > > > > > > > signal remote service node (ex: PE) going down in the presence 
> > > > > > > > of summary route being advertised from remote area or pop.
> > > > >  [WAJ] Yes, this may be the most useful use case, but the PUA 
> > > > > mechanism can also apply to other scenarios. We want to make it one 
> > > > > general solution.
> > > > ___
> > > > 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] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Jeff,

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.

So if you intend to use unreachable prefixes in data plane as result you
need to break summary into as atomic prefixes as your unreachable
advertisement mask.

Hence my recommendation to use IGP to flood unreachable only for the
purpose of control plane (namely BGP paths invalidation).

Cheers,
R.

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura 
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>
> On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
>
> 
> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> ___
> 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] Prefix Unreachable Announcement Use Cases

[Gyan Mishra]

Robert & Acee

I have been working with Aijun to help clean up the verbiage in the draft
which after IETF 109 will plan to do an update based on feedback.

I will be presenting this draft as well as the passive interface draft
tomorrow morning.

It has been challenging trying to graphically depict Aijun’s goals and
intentions but I have tried my best to do so in the presentation tomorrow
morning.

Kind Regards

Gyan

On Sun, Nov 15, 2020 at 11:44 AM Robert Raszuk  wrote:

> Hi Aijun,
>
> I would in fact only propose that the presented mechanism is narrowed down
> to invalidate BGP (service) routes - in fact their next hops.
>
> The reason being that the moment you make the solution generic, moreover
> the moment you want it to be used in RIB and data plane I am afraid you are
> running into similar (even if local) deaggregation mechanism like recently
> described in RIFT. That would kill all the scalability of advertising
> summary routes in the first place and I bet would face lots of opposition.
>
> Thx,
> R.
>
>
>> I would actually trim most use cases leaving just one - to signal remote
>> service node (ex: PE) going down in the presence of summary route being
>> advertised from remote area or pop.
>>
>>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
> can also apply to other scenarios. We want to make it one general solution.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 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

[Jeff Tantsura]

As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather 
 unfortunate, in RIFT disaggregation is conditional and well contained within 
its context, it doesn’t  affect overall scalability.

Regards,
Jeff

> On Nov 15, 2020, at 08:44, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
> 
> I would in fact only propose that the presented mechanism is narrowed down to 
> invalidate BGP (service) routes - in fact their next hops. 
> 
> The reason being that the moment you make the solution generic, moreover the 
> moment you want it to be used in RIB and data plane I am afraid you are 
> running into similar (even if local) deaggregation mechanism like recently 
> described in RIFT. That would kill all the scalability of advertising summary 
> routes in the first place and I bet would face lots of opposition. 
> 
> Thx,
> R.
>  
>>> I would actually trim most use cases leaving just one - to signal remote 
>>> service node (ex: PE) going down in the presence of summary route being 
>>> advertised from remote area or pop. 
>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism can 
> also apply to other scenarios. We want to make it one general solution.
> ___
> 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] I-D Action: draft-ietf-lsr-isis-rfc5316bis-00.txt

[internet-drafts]

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   : ISIS Extensions in Support of Inter-Autonomous System 
(AS) MPLS and GMPLS Traffic Engineering
Authors : Mach(Guoyi) Chen
  Les Ginsberg
  Stefano Previdi
  Xiaodong Duan
Filename: draft-ietf-lsr-isis-rfc5316bis-00.txt
Pages   : 20
Date: 2020-11-15

Abstract:
   This document describes extensions to the Intermediate System to
   Intermediate System (IS-IS) protocol to support Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
   (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS
   extensions for the flooding of TE information about inter-AS links,
   which can be used to perform inter-AS TE path computation.

   No support for flooding information from within one AS to another AS
   is proposed or defined in this document.

   This document obsoletes RFC 5316.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc5316bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis-00


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

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Hi Aijun,

I would in fact only propose that the presented mechanism is narrowed down
to invalidate BGP (service) routes - in fact their next hops.

The reason being that the moment you make the solution generic, moreover
the moment you want it to be used in RIB and data plane I am afraid you are
running into similar (even if local) deaggregation mechanism like recently
described in RIFT. That would kill all the scalability of advertising
summary routes in the first place and I bet would face lots of opposition.

Thx,
R.


> I would actually trim most use cases leaving just one - to signal remote
> service node (ex: PE) going down in the presence of summary route being
> advertised from remote area or pop.
>
>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
can also apply to other scenarios. We want to make it one general solution.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 11/16/2020)

[Huzhibo]

Hi les:
I agree with you that IGP still has work to do. I think we can leave the work 
to LSR to complete it, which does not affect the current BGP work.

Thank you.
Zhibo
发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
发送时间: 2020年11月15日 1:29
收件人: Huzhibo ; Ketan Talaulikar (ketant) 
; Susan Hares ; 'Jeff Tantsura' 
; Stephane Litkowski (slitkows) ; 
i...@ietf.org; Acee Lindem (acee) 
抄送: lsr@ietf.org
主题: RE: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Zhibo –

It is good of you to “keep me honest” as regards my past comments.

In reviewing the relevant material, the best I can say as regards my comments 
from 2 years ago is that they were made with insufficient diligence. Apologies 
for any resulting confusion.

https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 clearly indicates that 
the advertised value is dependent on the results of MTU-probe testing as 
specified in https://www.rfc-editor.org/rfc/rfc6325#section-4.3.2 .

Particularly relevant is the statement:

“o  MTU: This field is set to the largest successfully tested MTU size
  for this link or zero if it has not been tested, as specified in
  Section 4.3.2 of [RFC6325].”

So, as currently defined, IS-IS is not allowed to advertise a non-zero MTU 
value unless MTU-probes/acks have been exchanged.

https://www.rfc-editor.org/rfc/rfc7177#section-5 further clarifies that:

“The purpose of MTU testing is to ensure that the links used in the
   campus topology can pass TRILL IS-IS packets, particularly LSP PDUs,
   at the TRILL campus MTU.”

So the stated purpose of the TRILL definitions is NOT to provide assurances of 
data packet MTU, but more specifically to ensure that the IS-IS protocol can 
function correctly.

Could the MTU sub-TLV be repurposed to meet the requirements being discussed in 
the context of draft-zhu-idr-bgp-ls-path-mtu? Yes – I think that is possible - 
but it requires further  work.

draft-hu-lsr-isis-path-mtu was published over two years ago to define IS-IS 
extensions to advertise MTU. As you have noted, you received feedback from both 
Acee and myself which suggested that the TRILL defined MTU sub-TLV might be a 
better choice than the node property you had proposed. It seems based on that 
feedback you abandoned draft-hu-lsr-isis-path-mtu and focused only on 
draft-zhu-idr-bgp-ls-path-mtu. But as others have also noted, there is a gap 
regarding IGP support. OSPF has no ability to support MTU advertisement 
currently and – as this thread explains – even in IS-IS there is work to be 
done.

I would like to restate that I am – like others – supportive of this work – but 
I think WG adoption at this stage (in ANY WG) is premature.

   Les


From: Huzhibo mailto:huzh...@huawei.com>>
Sent: Friday, November 13, 2020 7:20 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Ketan Talaulikar (ketant) mailto:ket...@cisco.com>>; Susan 
Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; Stephane Litkowski 
(slitkows) mailto:slitk...@cisco.com>>; 
i...@ietf.org; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Cc: lsr@ietf.org
Subject: 答复: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

Hi Les, Acee:

Actually we have already discussed about this and reached agreements about two 
years ago. You may have forgotten. Please find the archives below.

https://mailarchive.ietf.org/arch/msg/lsr/C2bhd2ff2UJf4e_Gr-7j2W0g-SU/

I have followed your advice: "there already is a per link MTU sub-TLV defined 
by RFC 7176 ... in which case the existing sub-TLV is a perfect fit ...  IS-IS 
already has what is needed and therefore does not need any additional protocol 
extension". So we let our draft on ISIS extensions for MTU expired, i.e. 
draft-hu-lsr-isis-path-mtu. To be honest, I am a bit surprised when I saw your 
comments.

In this draft we focused on the extensions of BGP_LS for MTU only, which does 
not have to be feed by IGP LSDB. This draft has been discussed and revised a 
few rounds, based on the feedbacks both on ietf meetings and mail list, this 
document has good maturity to move forward.

Thanks
Zhibo


发件人: Idr [mailto:idr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2020年11月14日 7:58
收件人: Ketan Talaulikar (ketant) 
mailto:ketant=40cisco@dmarc.ietf.org>>; 
Susan Hares mailto:sha...@ndzh.com>>; 'Jeff Tantsura' 
mailto:jefftant.i...@gmail.com>>; 'Stephane Litkowski 
(slitkows)' 
mailto:slitkows=40cisco@dmarc.ietf.org>>;
 i...@ietf.org; 'Acee Lindem (acee)' 
mailto:acee=40cisco@dmarc.ietf.org>>
抄送: lsr@ietf.org
主题: Re: [Idr] WG Adoption for draft-zhu-idr-bgp-ls-path-mtu (11/1/2020 to 
11/16/2020)

The points which Ketan has made regarding the use of MTU advertisements defined 
in RFC 7176 are very valid. Indeed, the contents of the sub-TLV defined in 
https://www.rfc-editor.org/rfc/rfc7176.html#section-2.4 depend 

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 15, 2020, at 18:49, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
> 
> As I think what you are proposing overall is useful let me in turn comment on 
> some of your statements ... 
> 
>>> [WAJ] It is common, for example, ISIS level1-2 router will announce the 
>>> default route to the level 1 area. And, also in the OSPF totally stubby 
>>> area. 
>>> 
> 
> Well let's just take OSPF and imagine:
> 
>  Area1 --- ABR1 --- Area0 ---ABR2 --- Area2 
> 
> So you are saying that unreachable should be always flooded/leaked domain 
> wide. That's news - I was always thinking of this functionality only in the 
> case when a summary route covering such more specific is present. Default 
> should not count ... at least I am not sure if this is safe or makes sense at 
> this point. 
[WAJ] The situation is the same. If there is any special situation that is not 
safe, we can analyze it together.

> 
> 
>>> [WAJ] The tunnel soultions described in section 6 is the last resort of the 
>>> path switch procedure. If we deploy the PUA mechanism, normally the routers 
>>> within another area will switch automatically to other ABR when it receives 
>>> the PUA from one ABR.  Only in the critical scenario that described in 
>>> beginning of section 6, the solution described in section 6.1 or 6.2 will 
>>> be used.
>>> 
> 
> I think this is where you are starting to confuse people. In my option this 
> solution should have nothing to do with selecting which ABR to use to cross 
> area boundary. 
[WAJ] This situation may occur when both ABR can’t send PUA messages to divert 
the traffic and it will apply when the PUA mechanism is not in effect. The last 
resort for the traffic forwarding.
> 
> The cases when one ABR has full remote reachability and the other one partial 
> one in my view are symptoms of a very poorly designed network and to stretch 
> protocol thin to cover for those mistakes with a patch is not a good thing. 
[WAJ] The situation is not exist from the design or from the beginning. It may 
appear after some links failure, although it is scarce scenario, we should 
consider it for completeness.

> 
> I would actually trim most use cases leaving just one - to signal remote 
> service node (ex: PE) going down in the presence of summary route being 
> advertised from remote area or pop. 
> 
[WAJ] Yes, this may be the most useful use case, but the PUA mechanism can also 
apply to other scenarios. We want to make it one general solution.

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

Re: [Lsr] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

Hi Gyan,

 

Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot 
of lists :-).

 

> I have noticed that after reviewing many drafts across many WGs it seems in 
> the

> industry that the lines seem to be blurred between a PCE controller, ODL or

> Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X

> provisioning.

 

Yes, blurriness our speciality.

 

You my find RFC 7491 useful in this respect, although it is a little dated. 
And, of course, RFC 8283 is a good starting point.

 

> As this is a software sitting on a server you can have a swiss army knife 
> server that

> does everything from PCE path computation to  Netconf/Yang ZTP & Day N 

> provisioning as well as any SDN Controller ODL or Openflow controller type

> functions as well.

 

Yes, and this is one of the risks of PCE as a shiny thing: that it be converted 
from a useful toolkit into some form of god-box. I pontificated on this way 
back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf

 

> How this comes into play and realization of the lines being blurred is the 
> use of

> BGP-LS in building the IGP topological graph of the network which was designed

> for PCEP and PCE & PCC active & passive off line path computation for both

> RSVP-TE or SR-TE path instantiation.  

 

In some senses, BGP-LS didn’t add anything because a PCE could have snooped on 
the IGP. But BGP-LS provides an export mechanism and importantly adds to that 
some policy filters to determine what is exported thus giving the network some 
control over what is exported.

 

FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ proposes 
using PCEP for the same function. The argument in favor is that a PCE has to 
implement PCEP anyway, so why not include the LS export as well. The argument 
against is that BGP-LS has wider applicability and that it will typically be 
exported from an ASBR which already supports BGP.

 

> However now BGP-LS can also be used for other functions now such as usage as

> I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to

> gather the elements internals within BIER using the same BGP-LS data 
> structures

> to populate with BIER specific information to graph the BIER topology.  So 
> here

> we are not doing any path computations as we are using in this use case  for

> NMS type function to gather data for ZTP & Day N provisioning.

> 

> Similarly other use cases such as with TEAS TS-Transport slice and being able

> to provision TS and capturing the TS Enhanced VPN RT & resource information

> and leveraging BGP-LS to do the same data gathering & ZTP like controller 
> style

> provisioning. 

 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic.

 

> It does seem as though BGP-LS as its a means of "data gathering" "dump truck"

> of anything with the kitchen sink included to build any type of topological 
> graph

> of literally anything under the sun.

 

Remembering Yakov Rekhter saying you could use BGP to transport Shakespeare. 

This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, 
further use gets made.

 

BGP-LS was intended to export routing information “northbound” from the network.

 

> I see that is a nice to leverage but it does in fact blur the lines of NMS 
> Netconf/Yang

> Controller based functionality and  PCE path computation functionality and SDN

> controller based ZTP functionality into a single ubiquitous server that can 
> do all of

> the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It does 
> however

> transform BGP to be an NMS tool but a "tool" and not just the original 
> function

> which it was intended NLRI network reachability.

 

Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.

I might argue that BGP distributing policies from installation on PEs is an NMS 
protocol.

 

> Am I off base and please let me know as its BGP-LS is being way over 
> leveraged. 

> There are pros & cons to everything but I thought I would bring up to the WG 
> as

> an important discussion point.

 

Who are we to argue with real implementations? Assuming that there is a push 
for implementation and deployment, then the thing to look for is “harm”. Does 
this use of BGP-LS cause harm, sow confusion, risk destabilising the network? 
Should it use a different code point to be distinguishable?

 

I think the argument that “there is already another protocol for doing this” is 
worth examining. But we have to be careful that it doesn’t get us stuck, or 
force everyone to do something they don’t want to do. After all, we could carry 
any protocol message using Netconf/YANG, but we don’t do “RSVP-TE over Netconf”.

 

Best,

Adrian

 

___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] Prefix Unreachable Announcement Use Cases

[Robert Raszuk]

Hi Aijun,

As I think what you are proposing overall is useful let me in turn comment
on some of your statements ...

[WAJ] It is common, for example, ISIS level1-2 router will announce the
>> default route to the level 1 area. And, also in the OSPF totally stubby
>> area.
>>
>
Well let's just take OSPF and imagine:

 Area1 --- ABR1 --- Area0 ---ABR2 --- Area2

So you are saying that unreachable should be always flooded/leaked domain
wide. That's news - I was always thinking of this functionality only in the
case when a summary route covering such more specific is present. Default
should not count ... at least I am not sure if this is safe or makes sense
at this point.


[WAJ] The tunnel soultions described in section 6 is the last resort of the
>> path switch procedure. If we deploy the PUA mechanism, normally the routers
>> within another area will switch automatically to other ABR when it receives
>> the PUA from one ABR.  Only in the critical scenario that described in
>> beginning of section 6, the solution described in section 6.1 or 6.2 will
>> be used.
>>
>
I think this is where you are starting to confuse people. In my option this
solution should have nothing to do with selecting which ABR to use to cross
area boundary.

The cases when one ABR has full remote reachability and the other one
partial one in my view are symptoms of a very poorly designed network and
to stretch protocol thin to cover for those mistakes with a patch is not a
good thing.

I would actually trim most use cases leaving just one - to signal remote
service node (ex: PE) going down in the presence of summary route being
advertised from remote area or pop.

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