RE: [mpls] poll on draft-decraene-mpls-ldp-interarea-04.txt as wgdocument

["Prashant Desai" <Prashant.Desai at ecitele.com>]

I very much agree with Ina...
1) Let the operator/provider decide on his/her "state vs convergence"
trade-offs. Tom's point sounds analogus to the IETF dictating "one
cannot have more then 'n' routers in an IGP area as it affects
convergence". 
2) Pl. provide concrete examples on routing issues.
3) LDP/FIB interaction is strictly a vendor/implementation issue. I can
at least say that we (ECI/Laurel) have this draft implemented on our
routers without any complications.

Thanks
Prashant




-----Original Message-----
From: Ina Minei [mailto:ina at juniper.net] 
Sent: Thursday, May 24, 2007 12:22 PM
To: Thomas D. Nadeau
Cc: mpls at ietf.org
Subject: Re: [mpls] poll on draft-decraene-mpls-ldp-interarea-04.txt as
wgdocument 


 	Tom,

 	Please see inline below, ###.
>
> 	I agree with George here. I have a few other concerns about this

> approach. First, I am concerned that it might actually increase 
> convergence times.

### The concern you are raising is that we now rely on the propagation
of label withdrawals, rather than on reaction to IGP changes. This is
the price one has to pay to maintain the small IGP state and the
cleanliness of the network design. It is up to the provider to decide if
this tradeoff is acceptable. The behavior described in the draft is
enabled via configuration. On a side note, the diameter of each area is
typically only a few hops, so the propagation of withdrawl messages
should not be a concern. Besides, IGP messages don't propagate by magic
either, they also need to travel in the network :-)

>
> 	Second, there is a note in the document that acknowledges that
the 
> use of LDP to bind labels to routes not installed by the IGP is 
> explicitly prohibited by RFC3036. I believe this architectural 
> decision was made for a good reason.

### According to the authors of 3036, the reason was that it was the
easiest to ensure no loops.

Changing this
> not only leaves the potential for routing to be messed up,

### So far nobody has come up with a good scenario on how this can
happen.

> but it also will require some significant changes to the way in which 
> implementations realize LDP and its interaction with the FIB.

### Implementation details are vendor-specific.

 			Ina

In my opinion, the benefits of such a significant change are
> probably outweighed by the negative aspects given the marginal 
> improvement this results in.



>
> 	--Tom
>
>
>
>
>
>> [Chair hat off]
>> 
>> I still believe that this won't drastically reduce state or
processing.
>> One of the points in support of this was reduction of compute time 
>> for dijkstas.  Much of this could be gotten by noting what prefixes 
>> are advertised by the set of ABRs and caching the result of just one.

>> (If implementations aren't already doing this).
>> 
>> I remain unenthusiastic.
>> 
>> ...George
>> 
>>
========================================================================
>> George Swallow             Cisco Systems                  (978)
936-1398
>>                            1414 Massachusetts Avenue
>>                            Boxborough, MA 01719
>> 
>> _______________________________________________
>> mpls mailing list
>> mpls at lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
>

_______________________________________________
mpls mailing list
mpls at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls


_______________________________________________
mpls mailing list
mpls at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls