Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

From: "Rex Fernando (rex)" <[email-masked]>
Date: Thu, 2 Aug 2012 15:16:39 +0000

Support.

- Rex

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf Of
| John G. Scudder
| Sent: Monday, July 30, 2012 1:59 PM
| To: [email-masked] List
| Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG
| document
| 
| Folks,
| 
| We have received a request from the authors to adopt draft-gredler-idr-
| ls-distribution as an IDR WG document. Please send your comments to the
| list.  The deadline for comments is August 14, 2012 at noon EDT.
| 
| Thanks,
| 
| --John
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: "Field, Brian" <[email-masked]>
Date: Thu, 2 Aug 2012 16:31:08 +0000

Support.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Monday, July 30, 2012 4:59 PM
To: [email-masked] List
Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

Folks,

We have received a request from the authors to adopt draft-gredler-idr-ls-distribution as an IDR WG document. Please send your comments to the list.  The deadline for comments is August 14, 2012 at noon EDT.

Thanks,

--John
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Marco Rodrigues <[email-masked]>
Date: Mon, 6 Aug 2012 03:03:55 -0400

Support.

Marco.

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 30, 2012 4:58 PM
To: "[email-masked]<mailto:[email-masked]> List" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

Folks,

Thanks,

--John

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Aug 2012 21:43:33 +0100

Thanks John,

As a co-author, it may be no surprise that I support the adoption of this
document.

Adrian

> Sent: 30 July 2012 21:59
> We have received a request from the authors to adopt draft-gredler-idr-ls-
> distribution as an IDR WG document. Please send your comments to the list.
The
> deadline for comments is August 14, 2012 at noon EDT.
> 
> Thanks,
> 
> --John

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 7 Aug 2012 01:51:01 +0000

Hannes,

	Not that familiar with the applications.. I would like to understand if the TE/Link state being distributed is meant to have the same semantics as TE/Link state is distributed today..  In general I believe that section 6 needs more...

"6.1.1. Operations

   Existing BGP operation procedures apply.  No new operation procedures
   are defined in this document.  It shall be noted that the NLRI
   information present in this document purely carries application level
   data that have no immediate corresponding forwarding state impact.
   As such, any churn in reachability information has different impact
   than regular BGP update which needs to chaange forwarding state for
   an entire router.  Furthermore it is anticipated that distribution of
   this NLRI will be handled by dedicated route-reflectors providing a
   level of isolation and fault-containment between different NLRI
   types."

Although this section clearly states there is no impact to forwarding by distributing state via BGP it does not detail how this state should be treated. Specifically it is by its nature ephemeral or persistent? My expectation would be that the semantic of the actual state would not change based upon how it is disseminated into the to network.. Is this the case?

"6.1.5. Impact on Network Operation

   Frequency of Link-State NLRI updates could interfere with regular BGP
   prefix distribution.  A network operator MAY use a dedicated Route-
   Reflector infrastructure to distribute Link-State NLRIs.

   Distribution of Link-State NLRIs SHOULD be limited to a single admin
   domain, which can consist of multiple areas within an AS or multiple
"

Quite uncomfortable with this... Using a separate RR infrastructure may preclude issue with the RR topology but how can we ensure that a speaker is not overwhelmed by these updates thus starving other BGP information required for delivery of services..is it the SPs responsibility to gate updates? If so, what would be the appropriate frequency etc...

".2.6. Security Management

   An operator SHOULD define ACLs to limit inbound updates as follows:

   o  Drop all updates from Consumer peers
"
Again a bit uncomfortable with this approach.. We are dependent upon people or automation built by people.. If there was a mis-config what would the networks exposure be? Can you characterize the exposure... 

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marco Rodrigues
Sent: Monday, August 06, 2012 3:04 AM
To: John Scudder; [email-masked] List
Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

Support.

Marco.

Folks,

Thanks,

--John

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 7 Aug 2012 04:46:52 +0200

On Tue, Aug 07, 2012 at 01:51:01AM +0000, UTTARO, JAMES wrote:
| Hannes,
| 
| 	Not that familiar with the applications..
| I would like to understand if the TE/Link state being distributed is meant to have
| the same semantics as TE/Link state is distributed today..

HG> yes thats the case except, the bearer protocol is a different one;

| In general I believe that section 6 needs more...
| 
| "6.1.1. Operations
| 
| 
|    Existing BGP operation procedures apply.  No new operation procedures
|    are defined in this document.  It shall be noted that the NLRI
|    information present in this document purely carries application level
|    data that have no immediate corresponding forwarding state impact.
|    As such, any churn in reachability information has different impact
|    than regular BGP update which needs to chaange forwarding state for
|    an entire router.  Furthermore it is anticipated that distribution of
|    this NLRI will be handled by dedicated route-reflectors providing a
|    level of isolation and fault-containment between different NLRI
|    types."
| 
| Although this section clearly states there is no impact to forwarding by distributing state via BGP it does not detail how this state should be treated. Specifically it is by its nature ephemeral or persistent? My expectation would be that the semantic of the actual state would not change based upon how it is disseminated into the to network.. Is this the case?

HG> yes thats the case;

| "6.1.5. Impact on Network Operation
| 
| 
|    Frequency of Link-State NLRI updates could interfere with regular BGP
|    prefix distribution.  A network operator MAY use a dedicated Route-
|    Reflector infrastructure to distribute Link-State NLRIs.
| 
|    Distribution of Link-State NLRIs SHOULD be limited to a single admin
|    domain, which can consist of multiple areas within an AS or multiple
| "
| 
| Quite uncomfortable with this... Using a separate RR infrastructure may preclude issue with the RR topology but how can we ensure that a speaker is not overwhelmed by these updates thus starving other BGP information required for delivery of services..is it the SPs responsibility to gate updates? If so, what would be the appropriate frequency etc...

HG> two points: the transactional cost of a BGP-LS update is rather low as there is
    no (systemwide) forwarding state change equired; not sure if we want to give
    recommendations for upper bound throttles etc. - e.g. in our first prototype
    implementation several thousands updates per second are feasible.
    second a MP-BGP implementation ideally has got seperation (fault-containmenat) of
    AF specific code; 

| ".2.6. Security Management
| 
| 
|    An operator SHOULD define ACLs to limit inbound updates as follows:
| 
|    o  Drop all updates from Consumer peers
| "
| Again a bit uncomfortable with this approach.. We are dependent upon people or automation built by people.. If there was a mis-config what would the networks exposure be? Can you characterize the exposure... 

HG> this is a bit like the moral equivalent of opening your IGP to your external parties;
    (you just do not want to do that) - however if you have the gates open (by accident) then
    a misbehaving BGP-LS application might be able to inject topology data into
    your BGP-LS cloud. since the main-purpose of this is for applications
    to learn about topology (and not the other way around) we are sugesting
    to filter out everything that comes from a BGP-LS consumer;

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On Behalf Of Marco Rodrigues
| Sent: Monday, August 06, 2012 3:04 AM
| To: John Scudder; [email-masked] List
| Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document
| 
| Support.
| 
| Marco.
| 
| From: John Scudder <[email-masked]<mailto:[email-masked]>>
| Date: Monday, July 30, 2012 4:58 PM
| To: "[email-masked]<mailto:[email-masked]> List" <[email-masked]<mailto:[email-masked]>>
| Subject: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document
| 
| Folks,
| 
| We have received a request from the authors to adopt draft-gredler-idr-ls-distribution as an IDR WG document. Please send your comments to the list.  The deadline for comments is August 14, 2012 at noon EDT.
| 
| Thanks,
| 
| --John
| _______________________________________________
| Idr mailing list
| [email-masked]<mailto:[email-masked]>
| https://www.ietf.org/mailman/listinfo/idr
| 
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Aug 2012 07:59:53 +0200

Hi Hannes,

Is there any compelling reason not to make this gate unidirectional by 
design ?

ie .. SAFI X is to filter everything on inbound unless explicitly 
allowed to be accepted ? That way you configure your inbound policy once 
or twice (on bgp-ls receivers) rather then N times on the per area 
senders ;-)

--

Btw if I am running OSPF and build bgp-ls from each ABR would I get area 
0 multiple times ? Is there any provision in the spec to avoid this or 
are you hoping that implementations at some point of iteration will 
allow the fine control on what is being send ?

Best,
R.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 7 Aug 2012 17:12:49 +0200

On Tue, Aug 07, 2012 at 07:59:53AM +0200, Robert Raszuk wrote:
| Hi Hannes,
| 
| Is there any compelling reason not to make this gate unidirectional
| by design ?

HG> how would you mesh then non-consumer speakers (i.e. RRs) with each other ?
    following the "element of least surprise" i'd like to stick with the
    default behaviour i.e. leave the flood gates open unless prohibited by
    policy.
 
| ie .. SAFI X is to filter everything on inbound unless explicitly
| allowed to be accepted ? That way you configure your inbound policy
| once or twice (on bgp-ls receivers) rather then N times on the per
| area senders ;-)

HG> my deployment recommendation would be to have a group of consumers
    on the RR which rejects all inbound BGP-LS updates coming from a consumer
    peer.
  
| Btw if I am running OSPF and build bgp-ls from each ABR would I get
| area 0 multiple times ? Is there any provision in the spec to avoid
| this or are you hoping that implementations at some point of
| iteration will allow the fine control on what is being send ?

HG> yes you would - and it is its called best-path selection ;-) - i.e.
    among the BGP speakers that export the OSPF-link regular BGPs
    best-path selection criteria do apply.

| >|    An operator SHOULD define ACLs to limit inbound updates as follows:
| >|
| >|    o  Drop all updates from Consumer peers
| >| "
| >| Again a bit uncomfortable with this approach.. We are dependent upon people or automation built by people.. If there was a mis-config what would the networks exposure be? Can you characterize the exposure...
| >
| >HG> this is a bit like the moral equivalent of opening your IGP to your external parties;
| >     (you just do not want to do that) - however if you have the gates open (by accident) then
| >     a misbehaving BGP-LS application might be able to inject topology data into
| >     your BGP-LS cloud. since the main-purpose of this is for applications
| >     to learn about topology (and not the other way around) we are sugesting
| >     to filter out everything that comes from a BGP-LS consumer;
|

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 07 Aug 2012 18:13:04 +0200

> HG> yes you would - and it is its called best-path selection;-)  - i.e.

So now it is BGP best path to decide which side of topology of area 0 am 
I going to see in the northbound application ? I do not think this is a 
good idea at all.

Btw ... I was asking for something completely different.

If you are configuring bgp-ls on number of OSPF ABRs it seems pretty 
easy to explicitly specify which areas should be advertised and which not.

r.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 7 Aug 2012 19:31:31 +0200

On Tue, Aug 07, 2012 at 06:13:04PM +0200, Robert Raszuk wrote:
| 
| >| Btw if I am running OSPF and build bgp-ls from each ABR would I get
| >| area 0 multiple times ? Is there any provision in the spec to avoid
| >| this or are you hoping that implementations at some point of
| >| iteration will allow the fine control on what is being send ?
| >
| >HG> yes you would - and it is its called best-path selection;-)  - i.e.
| >     among the BGP speakers that export the OSPF-link regular BGPs
| >     best-path selection criteria do apply.
| 
| So now it is BGP best path to decide which side of topology of area
| 0 am I going to see in the northbound application ? I do not think
| this is a good idea at all.

point is that you see all area 0 link-state content as advertised by
two ABRs ... BGP just decides then for one (router-id !) BGP speaker
which BGP flooding path is "better".
 
| Btw ... I was asking for something completely different.
| 
| If you are configuring bgp-ls on number of OSPF ABRs it seems pretty
| easy to explicitly specify which areas should be advertised and
| which not.

yes you have nice control what you advertise here ....

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 8 Aug 2012 12:30:40 -0400

Support.

Thanks,
Nabil

On 7/30/12 4:58 PM, "John G. Scudder" <[email-masked]> wrote:

>Folks,
>
>We have received a request from the authors to adopt
>draft-gredler-idr-ls-distribution as an IDR WG document. Please send your
>comments to the list.  The deadline for comments is August 14, 2012 at
>noon EDT.
>
>Thanks,
>
>--John

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 8 Aug 2012 12:38:06 -0400

+1

---

From: Rob Shakir <[email-masked]>
Date: Thu, 9 Aug 2012 11:08:58 +0100

Hi Authors, IDR, Chairs,

Reviewing the slides that were sent to the list earlier, and based on comments that I have made numerous times during idr meetings I would like to raise a concern regarding this draft (and would therefore currently not support its adoption). Whilst I am supportive of the general concept that is presented, and see its utility, I think that there are general robustness and scaling concerns.

The current consideration of these issues in the draft seems relatively limited to "Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution." with a following comment on RR infrastructure - however, the deployment cases would seem to indicate that the device originating this information is not necessarily dedicated to the purpose (in networks with numerous areas, it is unlikely that deploying a dedicated device per area is commercially viable). It would seem to me that this means that the impact to the PE device must also be considered.

Whilst it is fine to say that the IGP damps some events when there are repeated flaps and this may limit the number of LS UPDATEs required, this seems to consider the 'happy' state of the network - if I have significant IGP instability that I cannot damp (look at link stability in some regions of the world for reference - there may not be a repeated single event, but rather a number of links displaying instability), or large network failures (e.g., a number of devices reloading) I would assert that the information that is being distributed by this mechanism is secondary to other tasks that the BGP process is doing. In these events, if it is not single "entries" that are being updated, then I do not think that an RFD-alike approach helps suppress the activity. 

This lack of control has a number of areas of concern for me:
	- We had a debate around the OPERATIONAL message as to whether this is "as important" as routing information. There was therefore some consideration as to how some of these mechanisms interact (or at least ensuring that there was the flexibility/guidance for implementations to protect itself). I think that this has the same discussion to be had - is an LS UPDATE as important as a IPv4/IPv6/VPNv4/VPNv6 UPDATE? (i.e., should this mechanism adversely affect convergence time for routing information, given that it is competing for the same network and computational resources - I would assert that it should not.)
	- If LS is a separate <AFI,SAFI> this is fine - but again, is it right to have fate-sharing between this information and routing information in terms of session liveliness? Whilst clearly the fact LS is carried in a separate <AFI,SAFI> would enable multi-session to segregate this information - but this is not noted as a prerequisite in the draft (and no standardised multi-session mechanism exists...).

Clearly, these are wider 'architectural' issues with carrying non-routing information within BGP - but since there is no framework for this form of information in BGP, then they need to be addressed on a case-by-case basis when considering individual drafts - hence my objection.

Fundamentally, I don't think that the problem space highlighted does not exist, or that the solution is not the right one - just that it currently presents a stability concern to existing network deployments which may result in instability or failures, and I do not find this acceptable.

Kind regards,
r.

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 9 Aug 2012 17:34:18 +0200

rob,

what you are describing below are all valid concerns, however those are
all in the realm of segregation, fault-isolation and inter-AF fairness -
IOW more 'implementation' and not necessary 'protocol' related.
i am not at all sugesting to keep the implementation discussion with vendors,
and talk in IETF only about protocols, since there is some intersection
on actual 'protocol operation'.

since you are specifically worried about the IGP/BGP export interface,
please feel free to send text around throttling behavior & parameters,
and we'll try to incorporate it.

thanks !

/hannes

On Thu, Aug 09, 2012 at 11:08:58AM +0100, Rob Shakir wrote:
| Hi Authors, IDR, Chairs,
| 
| Reviewing the slides that were sent to the list earlier, and based on comments that I have made numerous times during idr meetings I would like to raise a concern regarding this draft (and would therefore currently not support its adoption). Whilst I am supportive of the general concept that is presented, and see its utility, I think that there are general robustness and scaling concerns.
| 
| The current consideration of these issues in the draft seems relatively limited to "Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution." with a following comment on RR infrastructure - however, the deployment cases would seem to indicate that the device originating this information is not necessarily dedicated to the purpose (in networks with numerous areas, it is unlikely that deploying a dedicated device per area is commercially viable). It would seem to me that this means that the impact to the PE device must also be considered.
| 
| Whilst it is fine to say that the IGP damps some events when there are repeated flaps and this may limit the number of LS UPDATEs required, this seems to consider the 'happy' state of the network - if I have significant IGP instability that I cannot damp (look at link stability in some regions of the world for reference - there may not be a repeated single event, but rather a number of links displaying instability), or large network failures (e.g., a number of devices reloading) I would assert that the information that is being distributed by this mechanism is secondary to other tasks that the BGP process is doing. In these events, if it is not single "entries" that are being updated, then I do not think that an RFD-alike approach helps suppress the activity. 
| 
| This lack of control has a number of areas of concern for me:
| 	- We had a debate around the OPERATIONAL message as to whether this is "as important" as routing information. There was therefore some consideration as to how some of these mechanisms interact (or at least ensuring that there was the flexibility/guidance for implementations to protect itself). I think that this has the same discussion to be had - is an LS UPDATE as important as a IPv4/IPv6/VPNv4/VPNv6 UPDATE? (i.e., should this mechanism adversely affect convergence time for routing information, given that it is competing for the same network and computational resources - I would assert that it should not.)
| 	- If LS is a separate <AFI,SAFI> this is fine - but again, is it right to have fate-sharing between this information and routing information in terms of session liveliness? Whilst clearly the fact LS is carried in a separate <AFI,SAFI> would enable multi-session to segregate this information - but this is not noted as a prerequisite in the draft (and no standardised multi-session mechanism exists...).
| 
| Clearly, these are wider 'architectural' issues with carrying non-routing information within BGP - but since there is no framework for this form of information in BGP, then they need to be addressed on a case-by-case basis when considering individual drafts - hence my objection.
| 
| Fundamentally, I don't think that the problem space highlighted does not exist, or that the solution is not the right one - just that it currently presents a stability concern to existing network deployments which may result in instability or failures, and I do not find this acceptable.
| 
| Kind regards,
| r.
| 
| On 30 Jul 2012, at 21:58, "John G. Scudder" <[email-masked]> wrote:
| 
| > Folks,
| > 
| > We have received a request from the authors to adopt draft-gredler-idr-ls-distribution as an IDR WG document. Please send your comments to the list.  The deadline for comments is August 14, 2012 at noon EDT.
| > 
| > Thanks,
| > 
| > --John
| > _______________________________________________
| > Idr mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/idr
| _______________________________________________
| Idr mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/idr

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 10 Aug 2012 10:45:29 +0000

All,

	I am all for using BGP as a general purpose protocol. It is unfortunate that we have to have the same types of discussions every time a draft is introduced that uses BGP in a non-traditional manner. We need a top down view or better said a framework of the how BGP as a protocol should behave when being used for different applications ( I am tired of listening to myself say that!!! ). This draft addresses a valid problem space and IMO the IETF has allowed for many non-traditional applications to become WG drafts without the required specifications some of which Rob clearly lays out below.  Not sure how to proceed ? Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Shakir
Sent: Thursday, August 09, 2012 6:09 AM
To: John Scudder
Cc: [email-masked] List
Subject: Re: [Idr] Adoption of draft-gredler-idr-ls-distribution as IDR WG document

Hi Authors, IDR, Chairs,

The current consideration of these issues in the draft seems relatively limited to "Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution." with a following comment on RR infrastructure - however, the deployment cases would seem to indicate that the device originating this information is not necessarily dedicated to the purpose (in networks with numerous areas, it is unlikely that deploying a dedicated device per area is commercially viable). It would seem to me that this means that the impact to the PE device must also be considered

[Jim U>] I had thought that the ABR would provide the needed information of each non-zero area. That being said, if we had to use our PEs that would not be a sunny day scenario, are there addl consideration in re PEs being in different AS domains aligned with different non-zero areas?

Whilst it is fine to say that the IGP damps some events when there are repeated flaps and this may limit the number of LS UPDATEs required, this seems to consider the 'happy' state of the network - if I have significant IGP instability that I cannot damp (look at link stability in some regions of the world for reference - there may not be a repeated single event, but rather a number of links displaying instability), or large network failures (e.g., a number of devices reloading) I would assert that the information that is being distributed by this mechanism is secondary to other tasks that the BGP process is doing. In these events, if it is not single "entries" that are being updated, then I do not think that an RFD-alike approach helps suppress the activity. 
[Jim U>] Agreed.. We would want to bring up critical services first.

[Jim U>] I would like to see protection for the BGP signaled services I.e L3VPN, L2VPN etc... as mentioned above this is the same concern for many other apps that are using BGP i.e RT Constrain, flowspec etc... 

Clearly, these are wider 'architectural' issues with carrying non-routing information within BGP - but since there is no framework for this form of information in BGP, then they need to be addressed on a case-by-case basis when considering individual drafts - hence my objection.
[Jim U>] This is the crux of the matter.. We need a framework for using BGP for these non-traditional applications.. How do we move the dial on this..I have tried but so far no luck.. 

Kind regards,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Aug 2012 12:54:51 +0200

> [Jim U>] This is the crux of the matter.. We need a framework for
> using BGP for these non-traditional applications.. How do we move the
> dial on this..I have tried but so far no luck..

I have tried in the past too, by proposing a very clear way for each 
operator to decide what is critical to him and what is less critical 
from the range of applications BGP can be used for.

As you recall in order to accomplish this Keyur and I proposed the draft:

Transport Instance BGP

Ref:
http://tools.ietf.org/html/draft-raszuk-ti-bgp-00
http://tools.ietf.org/agenda/75/slides/idr-0.pdf

However as expected some folks stated that BGP process separation is an 
implementation detail. While they are clearly correct lack of this 
implementation detail results in very difficult space of mixing various 
services in single BGP process what naturally may not be comfortable by 
some.

Best,
R.

---

From: Rob Shakir <[email-masked]>
Date: Mon, 20 Aug 2012 16:06:26 +0100

Hi Hannes,

Apologies in the delay in getting back to you on this.

> on actual 'protocol operation'.

Talk in the IETF should equally consider what the practicality of actually deploying the protocols that are developed are - since any mechanism generally does not solve a problem unless it is actually deployable. Part of deployability is determining the impact to existing services (and therefore existing protocols). IMHO, we cannot design each element in a vacuum and then expect "implementation choice" to protect any overlap - we rather need to consider the overall way that protocols (or indeed, in this case, different features of a single protocol) are *intended* to interact in order to maintain network and systems stability. This is not implementation specific, it is rather something that is a feature of the overall architecture of a protocol.

> and we'll try to incorporate it.

I am not clear on what the recommended solutions/envisaged compromises between stability and delay in updates are in this mechanism. In the use cases that you are attempting to solve, how important is 100% correctness - for instance, one could compare this easily to accuracy for remaining reservable bandwidth on a link within current IGP extensions in the MPLS-TE PCE case (i.e., some delay is acceptable, it will just result in some delay in/a failed attempt at path set up in some circumstances). I think that there is a consideration required of relative priorities, required levels of accuracy, and importance before there is wording that can patch the issues I highlighted.

Kind regards,
r.

---

From: Paul WALL <[email-masked]>
Date: Thu, 30 Aug 2012 04:47:52 -0700

I support this draft.

Paul Wall

Drive Slow