Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

Hi Hannes,

On #1 ==> Sure.
                  Delay could be from Update generation not on transmission.
                  Though it's one hop from RR to Controller it's hop-by-hop till that point to  the IGP on RR!
                  In general, TE Metric extensions on LS could very sensitive to this delay (link delay/bandwidth). 
                  Some generic comment on this would be useful for future readers.
         #2 ==> So it's on IGP folk who are proposing extensions - may be a note would be good here too on what kind of changes you are seeking/interested.
Thx.      
--
Uma C.

-----Original Message-----
From: Hannes Gredler [mailto:hannes@juniper.net] 
Sent: Monday, September 01, 2014 11:05 AM
To: Uma Chunduri
Cc: Susan Hares; idr@ietf.org; 'John G. Scudder'
Subject: Re: [Idr] WG LC for draft-ietf-idr-ls-distribution and draft-ietf-idr-ls-distribut-impl

hi uma,

see comments/responses inline:

On Wed, Aug 27, 2014 at 11:07:01AM +0000, Uma Chunduri wrote:
|    Support.
| 
|    I see, hierarchy is WELL  defined when multiple instances of IGP with
|    multiple AFs are running. Good work.
| 
| 
| 
|    Have following Qs:
| 
|    1.       Any discussion of the delay introduced by BGP (packing, update
|    generation, processing etc..) to transport the LS information
| 
|    especially, when LSDB is changing faster perhaps with large number of
|    nodes/links inside an AS and with multiple ASes) to the controller will be
|    useful.

this is highly implementation dependent; - some vendors do the packaging of BGP updates entirely event-driven and others pack things up and have a worst case delay between the trigger event and the BGP update. the protocol itself does not prohibit/limit the propagation speed.
(in fact it can be shown that sometimes updates travel faster on the (dataplane forwarded) iBGP mesh, rather than propgate using the hop-by-hop control-plane flooding
protocol)

|                 A note on the sensitivity of this delay to the consumer
|    (applications) at the controller  can be helpful. I saw very little
|    discussion in Section 6 (6.1.5)

difficiult - its hard to have some sort of general comment as things are highly implementation dependent.

|    2.       This document encompasses pretty much both OSPF and ISIS
|    extensions done till date. How it will keep up with future extensions in
|    OSPF/ISIS.

we have set up an IANA registries for the carriers of information.
it is expected by authors of "topological relevant" IGP extensions to supply also BGP-LS extensions.

|    A mechanism in place would be helpful. My suggestion would be-  the
|    respective IGP documents should assess the impact and define
| 
|    corresponding new TLVs for BGP LS? But how this can be enforced?

i have no idea - today its entirely voluntary.

|    3.       Section 4, gives glimpse what's possible and the node aggregating
|    the links obviously need to tinker the LSDB to represent the same
|    correctly.
| 
|    Some more details would be helpful to represent the changes on
|    aggregation/de-aggregation subsequently.

this may quickly get you into the "abstracted topology models"
discussion that keeps emerging  periodically. - we did not want to stop progress on the protocol by arguing "whats the right abstraction model" and have agreed on the minimalistic nature of the section as-is.

|    4.       Section 6.2 has empty sub-sections and TBDs.

right ... so suggest to remove section 6.2 altogether.

|    5.       It's good to see Implementation report shed light on performance
|    seen with multiple ASes.
| 
|    6.       It's good to see if any application of policy on LSDB is done
|    (one of the primary drivers of the specification).

thanks,

/hannes

| 
|    From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
|    Sent: Tuesday, August 26, 2014 11:37 AM
|    To: idr@ietf.org
|    Cc: 'John G. Scudder'; shares@ndzh.com
|    Subject: [Idr] WG LC for draft-ietf-idr-ls-distribution and
|    draft-ietf-idr-ls-distribut-impl
| 
| 
| 
|    This is a WG LC for
| 
| 
| 
|      
| [1]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
| 
|      
| [2]http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl
| /
| 
| 
| 
|    Please respond with comments and "support or no support."  This WG LC also
|    includes a request for the authors to provide IPR on the subject.
| 
| 
| 
|    Please note: due to the European vacations in August, we are bundling
|    these three reviews into the next two weeks (these two drafts and
|    draft-ietf-as-migration).   The chairs would like feedback (list or
|    private email) whether the three WG LC s impact anyone's ability to review
|    these drafts carefully.
| 
| 
| 
|    Thank you,
| 
| 
| 
|    Sue Hares and John Scudder
| 
| References
| 
|    Visible links
|    1. http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/
|    2. 
| http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/

| _______________________________________________
| Idr mailing list
| Idr@ietf.org
| https://www.ietf.org/mailman/listinfo/idr