Multiprotocol Label Switching (mpls)

Mach Chen | 1 Mar 2010 03:38

Re: [mpls-tp] Comments for draft-chen-mpls-return-path-specified-lsp-ping-01

Hi Ben,

Thanks for your reply!

--------------------------------------------------
From: <benjamin.niven-jenkins <at> bt.com>
Sent: Monday, March 01, 2010 3:01 AM
To: <mach <at> huawei.com>; <gregimirsky <at> gmail.com>; <nitinb <at> juniper.net>
Cc: <mpls <at> ietf.org>; <mpls-tp <at> ietf.org>
Subject: Re: [mpls-tp] [mpls] Comments for 
draft-chen-mpls-return-path-specified-lsp-ping-01

> Mach,
>
> On 24/02/2010 09:18, "Mach Chen" <mach <at> huawei.com> wrote:
>>> IMO the opposite direction of the associated bidirectional LSP should be
>>> used by default.
>>>
>>> I can't think of an application for overwriting it off the top of my 
>>> head,
>>> but that's not to say one doesn't exist.
>>
>> How about when the default return path is suspected broken, overwriting 
>> may
>> help in judging whether the return path is borken or not.
>
> If the default return path is broken and the default return path is the
> opposite direction of an associated bidirectional LSP then the entire
> associated bidirectional LSP is essentially broken.

(Continue reading)

headers

lizhong.jin | 1 Mar 2010 09:51

mLDP based P2MP/MP2MP LSP leaf discovery

Hi, all MPLS experts
We submit a new draft to deal with the problem of mLDP based P2MP/MP2MP LSP sharing among various applications, e.g, P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast] and etc.

Any comments are welcome, thank you.

Abstract
This document describes a mechanism for an mLDP based P2MP/MP2MP LSP root node to discover the leaf nodes information. This allows the root node gets the full information of the leaf node for one specified P2MP/MP2MP LSP. Such kind of function provides a general method for mLDP based P2MP/MP2MP LSP leaf node discovery, which will be used for multiplexing/aggregation by various mLDP applications, e.g, P2MP PW [I-D.draft-martini-pwe3-p2mp-pw], VPLS multicast [I-D.draft-ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.draft-ietf-l3vpn-2547bis-mcast] and etc.

Draft link: http://tools.ietf.org/html/draft-jin-mpls-mldp-leaf-discovery-00

Best Regards
Lizhong Jin
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Shivakumar Channalli | 1 Mar 2010 18:40

Re: [mpls-tp] poll to make draft-nitinb-mpls-tp-lsp-ping-extensionsan mpls working document

Yes-support.

regards,
shiv

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Greg Mirsky | 1 Mar 2010 19:53

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Dear Authors,
I've following questions to the document:

was it reviewed/discussed by OSPF and ISIS WGs;
how not advertising connection to a broadcast network is better then advertising it with maximum cost
if the answer to the previous question "Because former considers LDP state", then why not amend second interpretation of the [LDP-IGP-SYNC] with that improvement
I find "will not" in the following sentence at the end of Section 1 to assertive: "After IGP has converged but the LDP peering A-B is not yet operational, A will have B as the nexthop for PE2 and will not have a LDP LSP path to PE2." May I suggest to change it to "may not".

Regards,
Greg

PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated problem exists only if a better path is coming up on the broadcast segment.

On Sat, Feb 27, 2010 at 4:10 AM, Loa Andersson <loa <at> pi.nu> wrote:

All,

this is to start a mpls working group last call on
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Please sen your comments to the mpls working group mailing
list (mpls <at> ietf.org).

The working group last call end eob March 12.

/Loa
--

Loa Andersson email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager loa <at> pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

benjamin.niven-jenkins | 1 Mar 2010 20:59

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Greg,

On 01/03/2010 18:53, "Greg Mirsky" <gregimirsky <at> gmail.com> wrote:
> PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it
> is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated
> problem exists only if a better path is coming up on the broadcast segment.

I still don't understand...

The draft states:
   In Figure 1 when
   B's link to the broadcast network comes up, it advertises a high cost
   to the broadcast network. After IGP has converged but the LDP peering
   A-B is not yet operational, A will have B as the nexthop for PE2 and
   will not have a LDP LSP path to PE2. VPN traffic from PE1 to PE2 will
   be dropped at A.

Let's say "high cost" = 10 and "normal cost" = 1.

B will bring up its broadcast link and advertise it with a high cost of 10.
PE1-A-B-PE2 will have a cost of 11. PE1-A-C-D-PE2 will have a cost of 3.
After IGP convergence PE1-A-B-PE2 will still have a cost of 11, will it not?

Ben

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Sriganesh Kini | 1 Mar 2010 21:14

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Greg, see inline <at> [Sri]

- Sri

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 10:53 AM
To: mpls <at> ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Dear Authors,
I've following questions to the document:

was it reviewed/discussed by OSPF and ISIS WGs;
[Sri ] It was presented at OSPF WG in IETF-75

how not advertising connection to a broadcast network is better then advertising it with maximum cost
[Sri ] See section 1 of the draft that explains issues that arise due to advertising it with maximum cost. Not advertising connection to the broadcast network solves those issues.

if the answer to the previous question "Because former considers LDP state", then why not amend second interpretation of the [LDP-IGP-SYNC] with that improvement
[Sri ] The problem with the second interpretation of the draft is described in the last para of section 1. Amending it with LDP state does not help. A's next-hop (towards PE2) would point to B immediately when IGP converges. Consider the timeline when B has not yet advertised a label to A for the prefix PE2. Then A does not have a LSP path to PE2 and would blackhole packets.

I find "will not" in the following sentence at the end of Section 1 to assertive: "After IGP has converged but the LDP peering A-B is not yet operational, A will have B as the nexthop for PE2 and will not have a LDP LSP path to PE2." May I suggest to change it to "may not".
[Sri ] This hinges on a clear definition of operational. The definition we are using is that it is operational (for PE2) when B has advertised a label (for PE2) to A. In this case "will not" is applicable. We can add a clarifying statement in the draft.

Regards,
Greg

PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated problem exists only if a better path is coming up on the broadcast segment.

On Sat, Feb 27, 2010 at 4:10 AM, Loa Andersson <loa <at> pi.nu> wrote:
All,

this is to start a mpls working group last call on
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Please sen your comments to the mpls working group mailing
list (mpls <at> ietf.org).

The working group last call end eob March 12.

/Loa
--

Loa Andersson email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager loa <at> pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Greg Mirsky | 1 Mar 2010 21:27

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Ben,
I'm not familiar with the particular implementation of trigger to change cost in LSA thus everything further is my speculation a'la "how I'd do that".
Firstly, B advertises high cost (perhaps maxCost/2). When all IGP adjacencies been formed (perhaps forming adjacencies with DR and BDR on the Broadcast segment is sufficient condition), B advertises the real cost in its LSA. That is when IGP really converges since A switches the best route to PE2 from C to B. Will LDP lag behind? Obviously. But the same laging behind exists in the proposed schema. I personally don't see strong enough benefits. Existing, listed in the document, interpretations permit implementations that are not worse then described new method. Considering risk of changing SPF to determine "cut-edge" status ...

Regards,
Greg

On Mon, Mar 1, 2010 at 11:59 AM, <benjamin.niven-jenkins <at> bt.com> wrote:

Greg,

On 01/03/2010 18:53, "Greg Mirsky" <gregimirsky <at> gmail.com> wrote:
> PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it
> is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated
> problem exists only if a better path is coming up on the broadcast segment.

I still don't understand...

The draft states:
In Figure 1 when
B's link to the broadcast network comes up, it advertises a high cost
to the broadcast network. After IGP has converged but the LDP peering
A-B is not yet operational, A will have B as the nexthop for PE2 and

will not have a LDP LSP path to PE2. VPN traffic from PE1 to PE2 will
be dropped at A.

Let's say "high cost" = 10 and "normal cost" = 1.

B will bring up its broadcast link and advertise it with a high cost of 10.
PE1-A-B-PE2 will have a cost of 11. PE1-A-C-D-PE2 will have a cost of 3.
After IGP convergence PE1-A-B-PE2 will still have a cost of 11, will it not?

Ben

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Vishwas Manral | 1 Mar 2010 21:34

Re: Comments draft-nitinb-mpls-tp-lsp-ping-extensions

Hi Nitin,

I found the draft in the staging area

http://www.ietf.org/staging/draft-manral-mpls-lsp-ping-fecext-00.txt

This need not necessarily relate to your draft alone but also for basic MPLS itself.

Thanks,

Vishwas

On Mon, Mar 1, 2010 at 12:31 PM, Vishwas Manral <vishwas.ietf <at> gmail.com> wrote:

Hi Nitin,

Can you detail how Section 2.4 tells The Target FEC?

Also for the first isn't MPLS-TP generally supposed to be EMS/ NSM configured. Also how does the draft define the Target FEC field in the static case?

Thanks,

Vishwas

On Mon, Mar 1, 2010 at 12:22 PM, Nitin Bahadur <nitinb <at> juniper.net> wrote:

Hi Vishwas,

Not necessarily. The most common use of this might be with dynamic LSPs.

In case of static LSPs, the target FEC stack is described in Section 2.4.

HTH
Nitin

________________________________

From: Vishwas Manral [mailto:vishwas.ietf <at> gmail.com]
Sent: Monday, March 01, 2010 11:40 AM
To: Nitin Bahadur
Cc: mpls-tp <at> ietf.org
Subject: Comments draft-nitinb-mpls-tp-lsp-ping-extensions

Hi Nitin,

If I get it correct the most common use of this in MPLS-TP may be with Static LSP's and carrying MPLS traffic itself.

What is the Target FEC stack to use in such a case for LSP Ping? Do you think this requires a solution?

I have a draft that may help in such a case. It however still has not been posted yet.

Thanks,
Vishwas

On Sat, Feb 27, 2010 at 4:02 AM, Loa Andersson <loa <at> pi.nu> wrote:

All,

this is to start a poll on accepting
draft-nitinb-mpls-tp-lsp-ping-extensions-01
as an mpls working group document.

Please respond to the mpls-tp mailing list *only*!
Indicating "yes/support" or "no/do not support".

Technical comments, which are very welcome, should be
sent to the same list, but with a differnt subject line.

The poll ends eob March 12th 2010.

/Loa

--

Loa Andersson email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager loa <at> pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls-tp mailing list
mpls-tp <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Greg Mirsky | 1 Mar 2010 21:52

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Sri,
in my view, the problem you're addressing in this document is implementation specific. You're proposing alternative implementation, which requires SPF modification.

Regards,
Greg

On Mon, Mar 1, 2010 at 12:14 PM, Sriganesh Kini <sriganesh.kini <at> ericsson.com> wrote:

Greg, see inline <at> [Sri]

- Sri

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 10:53 AM
To: mpls <at> ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Dear Authors,
I've following questions to the document:

was it reviewed/discussed by OSPF and ISIS WGs;

[Sri ] It was presented at OSPF WG in IETF-75

how not advertising connection to a broadcast network is better then advertising it with maximum cost

[Sri ] See section 1 of the draft that explains issues that arise due to advertising it with maximum cost. Not advertising connection to the broadcast network solves those issues.

if the answer to the previous question "Because former considers LDP state", then why not amend second interpretation of the [LDP-IGP-SYNC] with that improvement

[Sri ] The problem with the second interpretation of the draft is described in the last para of section 1. Amending it with LDP state does not help. A's next-hop (towards PE2) would point to B immediately when IGP converges. Consider the timeline when B has not yet advertised a label to A for the prefix PE2. Then A does not have a LSP path to PE2 and would blackhole packets.

I find "will not" in the following sentence at the end of Section 1 to assertive: "After IGP has converged but the LDP peering A-B is not yet operational, A will have B as the nexthop for PE2 and will not have a LDP LSP path to PE2." May I suggest to change it to "may not".

[Sri ] This hinges on a clear definition of operational. The definition we are using is that it is operational (for PE2) when B has advertised a label (for PE2) to A. In this case "will not" is applicable. We can add a clarifying statement in the draft.

Regards,
Greg

PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated problem exists only if a better path is coming up on the broadcast segment.

On Sat, Feb 27, 2010 at 4:10 AM, Loa Andersson <loa <at> pi.nu> wrote:
All,

this is to start a mpls working group last call on
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Please sen your comments to the mpls working group mailing
list (mpls <at> ietf.org).

The working group last call end eob March 12.

/Loa
--

Loa Andersson email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager loa <at> pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Wenhu Lu | 1 Mar 2010 22:21

Re: working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Greg,

The point is that the original (RFC5443) method cannot be used to handle the broadcast network cases.

Do you agree with that?

Thanks,

-wenhu

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 12:52 PM
To: Sriganesh Kini
Cc: mpls <at> ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Hi Sri,
in my view, the problem you're addressing in this document is implementation specific. You're proposing alternative implementation, which requires SPF modification.

Regards,
Greg

On Mon, Mar 1, 2010 at 12:14 PM, Sriganesh Kini <sriganesh.kini <at> ericsson.com> wrote:

Greg, see inline <at> [Sri]

- Sri

From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, March 01, 2010 10:53 AM
To: mpls <at> ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Dear Authors,
I've following questions to the document:

was it reviewed/discussed by OSPF and ISIS WGs;

[Sri ] It was presented at OSPF WG in IETF-75

how not advertising connection to a broadcast network is better then advertising it with maximum cost

[Sri ] See section 1 of the draft that explains issues that arise due to advertising it with maximum cost. Not advertising connection to the broadcast network solves those issues.

if the answer to the previous question "Because former considers LDP state", then why not amend second interpretation of the [LDP-IGP-SYNC] with that improvement

[Sri ] The problem with the second interpretation of the draft is described in the last para of section 1. Amending it with LDP state does not help. A's next-hop (towards PE2) would point to B immediately when IGP converges. Consider the timeline when B has not yet advertised a label to A for the prefix PE2. Then A does not have a LSP path to PE2 and would blackhole packets.

I find "will not" in the following sentence at the end of Section 1 to assertive: "After IGP has converged but the LDP peering A-B is not yet operational, A will have B as the nexthop for PE2 and will not have a LDP LSP path to PE2." May I suggest to change it to "may not".

[Sri ] This hinges on a clear definition of operational. The definition we are using is that it is operational (for PE2) when B has advertised a label (for PE2) to A. In this case "will not" is applicable. We can add a clarifying statement in the draft.

Regards,
Greg

PS. RE: Question #2 from Ben. Cost to PE2 through B is 2, while through C-D it is 3. Thus B will be selected as NHR from A to PE2. Note, that the stated problem exists only if a better path is coming up on the broadcast segment.

On Sat, Feb 27, 2010 at 4:10 AM, Loa Andersson <loa <at> pi.nu> wrote:
All,

this is to start a mpls working group last call on
draft-ietf-mpls-ldp-igp-sync-bcast-00.txt

Please sen your comments to the mpls working group mailing
list (mpls <at> ietf.org).

The working group last call end eob March 12.

/Loa
--

Loa Andersson email: loa.andersson <at> ericsson.com
Sr Strategy and Standards Manager loa <at> pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

150	May 2013
90	April 2013
148	March 2013
142	February 2013
184	January 2013
173	December 2012
167	November 2012
193	October 2012
72	September 2012
176	August 2012
226	July 2012
105	June 2012
83	May 2012
95	April 2012
216	March 2012
86	February 2012
100	January 2012
83	December 2011
149	November 2011
141	October 2011
120	September 2011
147	August 2011
303	July 2011
184	June 2011
247	May 2011
182	April 2011
229	March 2011
107	February 2011
148	January 2011
183	December 2010
145	November 2010
170	October 2010
56	September 2010
121	August 2010
217	July 2010
118	June 2010
114	May 2010
168	April 2010
319	March 2010
112	February 2010
92	January 2010
40	December 2009
77	November 2009
66	October 2009
40	September 2009
25	August 2009
56	July 2009
26	June 2009
22	May 2009
16	April 2009
90	March 2009
33	February 2009
18	January 2009
32	December 2008
85	November 2008
115	October 2008
91	September 2008
88	August 2008
63	July 2008
41	June 2008
69	May 2008
74	April 2008
49	March 2008
76	February 2008
29	January 2008
24	December 2007
46	November 2007
32	October 2007
47	September 2007
12	August 2007
44	July 2007
39	June 2007
42	May 2007
33	April 2007
64	March 2007
30	February 2007
49	January 2007
37	December 2006
70	November 2006
49	October 2006
69	September 2006
18	August 2006
36	July 2006
79	June 2006
48	May 2006
103	April 2006
26	March 2006
79	February 2006
29	January 2006
50	December 2005
31	November 2005
38	October 2005
32	September 2005
54	August 2005
37	July 2005
32	June 2005
42	May 2005
32	April 2005
58	March 2005
84	February 2005
26	January 2005
52	December 2004
63	November 2004
111	October 2004
46	September 2004
44	August 2004
34	July 2004
93	June 2004
121	May 2004
83	April 2004
133	March 2004
88	February 2004
82	January 2004
26	December 2003
227	November 2003
121	October 2003
82	September 2003
89	August 2003
118	July 2003
167	June 2003
86	May 2003
161	April 2003
396	March 2003
195	February 2003
164	January 2003
374	December 2002
221	November 2002
157	October 2002
102	September 2002
147	August 2002
435	July 2002
192	June 2002
277	May 2002
245	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31