Subject: [mpls] I-D ACTION:draft-lu-ldp-igp-sync-bcast-00 - Comments?

From: Sriganesh Kini <[email-masked]>
Date: Wed, 25 Mar 2009 11:15:23 -0700

Hi,

This draft was presented at the MPLS WG meeting today.

There was one question at the end of the presentation that could not be 
answered due to lack of time.

The question (if I recollect correctly) seemed to be - When there are 
many nodes on the broadcast network coming up does this increase the 
network convergence time.
The answer is no. This solution does not increase the time to converge. 
There are 2 scenarios
1. If the routers detect the broadcast network as a 'cut-edge' - Fairly 
straightforward. There is no change in convergence time as nothing 
special is done.
2. If the routers detect the broadcast network as not a 'cut-edge', the 
network convergence time is no worse than RFC5443, since increasing the 
network metric produces the same effect. In fact the convergence will 
generally be better in draft-lu since traffic that need not be shifted 
away from the broadcast network is unaffected. Routers apply draft-lu 
procedures on seeing the first adjacency on that broadcast network.

Thanks

- Sri

I-D ACTION:draft-lu-ldp-igp-sync-bcast-00.txt

--------------------------------------------------------------------------------

To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-lu-ldp-igp-sync-bcast-00.txt
From: Internet-Drafts at ietf.org
Date: Wed, 11 Mar 2009 13:00:01 -0700 (PDT)
Delivered-to: i-d-announce at core3.amsl.com
List-archive:<http://www.ietf.org/mail-archive/web/i-d-announce>
List-help:<mailto:[email-masked]?subject=help>
List-id: Internet Draft Announcements only<i-d-announce.ietf.org>
List-post:<mailto:[email-masked]>
List-subscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=subscribe>
List-unsubscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]?subject=unsubscribe>
Reply-to: internet-drafts at ietf.org

--------------------------------------------------------------------------------

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

	Title		: LDP IGP Synchronization for broadcast networks
	Author(s)	: S. Kini, W. Lu
	Filename	: draft-lu-ldp-igp-sync-bcast-00.txt
	Pages		: 7
	Date		: 2009-3-4
	
    [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic
    (e.g. VPN) when IGP is operational on a link but LDP is not. If this
    mechanism is applied to broadcast links that have more than one
    LDP/IGP peer, the cost-out procedure can only be applied to the link
    as a whole but not an individual peer. When a new LDP peer comes up
    on a broadcast network, this can result in loss of traffic through
    other established peers on that network. This document describes a
    mechanism to address that use-case without dropping traffic. The
    mechanism does not introduce any protocol changes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lu-ldp-igp-sync-bcast-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lu-ldp-igp-sync-bcast-00.txt>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 27 Mar 2009 10:43:25 -0700

Dear Sri,
I was the one who raised the question. Thank you for you clarification but I
am still concerned about extended convergence. Without proposed modification
the black-holing of traffic will stop after LDP is operational between A and
B. With the proposed change the traffic will continue to flow over
PE1-A-C-D-PE2 path until LDP is operational between B and all its neighbors
on the broadcast segment.And the proposed modification helps to avoid
black-holing of traffic PE1 to PE2 though convergence to more optimal path
might be somewhat slower.
But, if I may, let's remove nodes C and D from the topology and consider the
same scenario as in the draft. With current behavior path PE1 to PE2 becomes
operational after IGP and LDP between A and B is operational. With proposed
modification of behavior in node B the path is operational only after B
makes LDP operational between C and E respectively. That might increase
convergence slightly. But my major concern is, as I've mentioned during the
meeting, with scenario of more nodes coming up sequentially on the broadcast
segment. Imagine there are nodes F, G, H, J, I, K, and etc. that are coming
one by one and form IGP adjacency with B. That will keep IGP/LDP ratio on on
node B out of desired balance (goal is to have number of IGP neighbors equal
to number of LDP peering over the broadcast interface). I believe that in
this, though unlikely, scenario the convergence will be worse with proposed
modification.
And I've got another question related to the proposed modification. In the
proposal the 'cut-edge' link advertised only after LDP is operational with
all IGP neighbors over the boradcast interface. But if an IGP neighbor
doesn't support LDP wouldn't that prevent node B from advertising its
'cut-edge' link ever?

Regards,
Greg

On Wed, Mar 25, 2009 at 11:15 AM, Sriganesh Kini <[email-masked]> wrote:

> The question (if I recollect correctly) seemed to be - When there are many
> nodes on the broadcast network coming up does this increase the network
> convergence time.
> straightforward. There is no change in convergence time as nothing special
> is done.
> generally be better in draft-lu since traffic that need not be shifted away
> from the broadcast network is unaffected. Routers apply draft-lu procedures
> on seeing the first adjacency on that broadcast network.
>
> Thanks
>
> - Sri
>
>
> List-subscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce
> >,<mailto:[email-masked]?subject=subscribe>
> List-unsubscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce
> >,<mailto:[email-masked]?subject=unsubscribe>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 27 Mar 2009 11:15:09 -0700

Hi Greg, pls see inline ..

- Sri

On 3/27/2009 10:43 AM, Greg Mirsky wrote:
> Dear Sri,
> I was the one who raised the question. Thank you for you clarification 
> but I am still concerned about extended convergence. Without proposed 
> modification the black-holing of traffic will stop after LDP is 
> operational between A and B. With the proposed change the traffic will 
> continue to flow over PE1-A-C-D-PE2 path until LDP is operational 
> between B and all its neighbors on the broadcast segment.And the 
> proposed modification helps to avoid black-holing of traffic PE1 to 
> PE2 though convergence to more optimal path might be somewhat slower.

A path can be considered for optimality only after it is operational. So 
PE1-PE2 traffic convergence is not slower.

> But, if I may, let's remove nodes C and D from the topology and 
> consider the same scenario as in the draft. With current behavior path 
> PE1 to PE2 becomes operational after IGP and LDP between A and B is 
> operational. With proposed modification of behavior in node B the path 
> is operational only after B makes LDP operational between C and E 
> respectively. That might increase convergence slightly. But my major 
> concern is, as I've mentioned during 

When C and D are removed from the topology, B deduces that that its 
interface to the broadcast network is a cut-edge. PE1-PE2 convergence is 
not increased.

> the meeting, with scenario of more nodes coming up sequentially on the 
> broadcast segment. Imagine there are nodes F, G, H, J, I, K, and etc. 
> that are coming one by one and form IGP adjacency with B. That will 
> keep IGP/LDP ratio on on node B out of desired balance (goal is to 
> have number of IGP neighbors equal to number of LDP peering over the 
> broadcast interface). I believe that in this, though unlikely, 
> scenario the convergence will be worse with proposed modification.

If nodes F, G, ... are introduced in the topology, B's interface to the 
broadcast network is still a cut-edge, as I explained above convergence 
is not increased

> And I've got another question related to the proposed modification. In 
> the proposal the 'cut-edge' link advertised only after LDP is 
> operational with all IGP neighbors over the boradcast interface. But 
> if an IGP neighbor doesn't support LDP wouldn't that prevent node B 
> from advertising its 'cut-edge' link ever?

Practically, there are simple ways of deducing that some IGP neighbors 
on a broadcast interface do not support LDP. Timeout, 
lack-of-LDP-hellos, configuration are some ways.

>
> Regards,
> Greg
>
> On Wed, Mar 25, 2009 at 11:15 AM, Sriganesh Kini <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     There was one question at the end of the presentation that could
>     not be answered due to lack of time.
>
>     The question (if I recollect correctly) seemed to be - When there
>     are many nodes on the broadcast network coming up does this
>     increase the network convergence time.
>     The answer is no. This solution does not increase the time to
>     converge. There are 2 scenarios
>     1. If the routers detect the broadcast network as a 'cut-edge' -
>     Fairly straightforward. There is no change in convergence time as
>     nothing special is done.
>     2. If the routers detect the broadcast network as not a
>     'cut-edge', the network convergence time is no worse than RFC5443,
>     since increasing the network metric produces the same effect. In
>     fact the convergence will generally be better in draft-lu since
>     traffic that need not be shifted away from the broadcast network
>     is unaffected. Routers apply draft-lu procedures on seeing the
>     first adjacency on that broadcast network.
>
>     Thanks
>
>     - Sri
>
>
>     To: i-d-announce at ietf.org <http://ietf.org>
>     From: Internet-Drafts at ietf.org <http://ietf.org>
>     Delivered-to: i-d-announce at core3.amsl.com <http://core3.amsl.com>
>     List-help:<mailto:[email-masked]
>     <mailto:[email-masked]>?subject=help>
>     List-id: Internet Draft Announcements only<i-d-announce.ietf.org
>     <http://i-d-announce.ietf.org>>
>     List-post:<mailto:[email-masked]
>     <mailto:[email-masked]>>
>     List-subscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]
>     <mailto:[email-masked]>?subject=subscribe>
>     List-unsubscribe:<https://www.ietf.org/mailman/listinfo/i-d-announce>,<mailto:[email-masked]
>     <mailto:[email-masked]>?subject=unsubscribe>
>     Reply-to: internet-drafts at ietf.org <http://ietf.org>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 27 Mar 2009 11:36:36 -0700

Hi Sri,
please see my notes in-line tagged by [GIM].
Regards,
Greg
[snip]

>
>
>  But, if I may, let's remove nodes C and D from the topology and consider
>> the same scenario as in the draft. With current behavior path PE1 to PE2
>> becomes operational after IGP and LDP between A and B is operational. With
>> proposed modification of behavior in node B the path is operational only
>> after B makes LDP operational between C and E respectively. That might
>> increase convergence slightly. But my major concern is, as I've mentioned
>> during
>>
>
> interface to the broadcast network is a cut-edge. PE1-PE2 convergence is not
> increased.
>
>> broadcast segment. Imagine there are nodes F, G, H, J, I, K, and etc. that
>> are coming one by one and form IGP adjacency with B. That will keep IGP/LDP
>> ratio on on node B out of desired balance (goal is to have number of IGP
>> neighbors equal to number of LDP peering over the broadcast interface). I
>> believe that in this, though unlikely, scenario the convergence will be
>> worse with proposed modification.
>>
>
> broadcast network is still a cut-edge, as I explained above convergence is
> not increased
>

[GIM]  I'm sorry but I couldn't find any technical explanation above.

> doesn't support LDP wouldn't that prevent node B from advertising its

 Practically, there are simple ways of deducing that some IGP neighbors on a
> broadcast interface do not support LDP. Timeout, lack-of-LDP-hellos,
> configuration are some ways.
>

[GIM] I agree but that changes condition set forward in the draft:

"... the updating of the LSA with that link to the pseudo-node is
   postponed till LDP is operational with all the neighbors on that
   broadcast interface ..."

And the way or ways of such determination should be described in the document.

>
>> Regards,
>> Greg
>>
>> On Wed, Mar 25, 2009 at 11:15 AM, Sriganesh Kini <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>    Hi,
>>
>> >,<mailto:[email-masked]
>> >,<mailto:[email-masked]
>>    <ftp://ftp.ietf.org/internet-drafts/draft-lu-ldp-igp-sync-bcast-00.txt
>> >
>>
>>
>>

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 27 Mar 2009 13:19:57 -0700

Greg, pls see inline

- Sri

On 3/27/2009 11:36 AM, Greg Mirsky wrote:
>         But, if I may, let's remove nodes C and D from the topology
>         and consider the same scenario as in the draft. With current
>         behavior path PE1 to PE2 becomes operational after IGP and LDP
>         between A and B is operational. With proposed modification of
>         behavior in node B the path is operational only after B makes
>         LDP operational between C and E respectively. That might
>         increase convergence slightly. But my major concern is, as
>         I've mentioned during
>
>
>     When C and D are removed from the topology, B deduces that that
>     its interface to the broadcast network is a cut-edge. PE1-PE2
>     convergence is not increased.
>

The draft specifies that when the edge is a cut-edge, no special 
handling is done i.e. the link from the router to the pseudo-node is 
advertised when the IGP adjacency is established. Hence IGP adjacencies 
and paths come up in the usual way and convergence is not affected.

>
>         the meeting, with scenario of more nodes coming up
>         sequentially on the broadcast segment. Imagine there are nodes
>         F, G, H, J, I, K, and etc. that are coming one by one and form
>         IGP adjacency with B. That will keep IGP/LDP ratio on on node
>         B out of desired balance (goal is to have number of IGP
>         neighbors equal to number of LDP peering over the broadcast
>         interface). I believe that in this, though unlikely, scenario
>         the convergence will be worse with proposed modification.
>
>
>     If nodes F, G, ... are introduced in the topology, B's interface
>     to the broadcast network is still a cut-edge, as I explained above
>     convergence is not increased
>
>

Pls see explanation above. If I have misunderstood, pls clarify what is 
not clear.

>
>     And I've got another question related to the proposed
>     modification. In the proposal the 'cut-edge' link advertised only
>     after LDP is operational with all IGP neighbors over the boradcast
>     interface. But if an IGP neighbor doesn't support LDP wouldn't
>     that prevent node B from advertising its 'cut-edge' link ever?
>
>
>     Practically, there are simple ways of deducing that some IGP
>     neighbors on a broadcast interface do not support LDP. Timeout,
> "...the updating of the LSA with that link to the pseudo-node is

Note that we have specified in the section 4 - scope, that issues such 
as certain neighbors not being configured for LDP are outside the scope 
of draft-lu. Also, note that such conditions are not in scope of RFC 
5443 either.  But we can add a clarifying statement in the next version 
of draft-lu if it helps.

>    
>
>
>
>         Regards,
>         Greg
>
>
>         On Wed, Mar 25, 2009 at 11:15 AM, Sriganesh Kini
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>            Hi,
>
>         <http://ietf.org>
>         <http://ietf.org>
>         <http://core3.amsl.com> <http://core3.amsl.com>
>
>          
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>?subject=help>
>            List-id: Internet Draft Announcements
>         only<i-d-announce.ietf.org <http://i-d-announce.ietf.org>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>          
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>?subject=subscribe>
>          
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>?subject=unsubscribe>
>         <http://ietf.org>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>