Multiprotocol Label Switching (mpls)

Will Liu (Shucheng | 22 May 2013 05:02

FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt

Folks, 

We updated the draft by modifying the introduction, typos in section 5, and adding a section highlighting
the changes on rfc3811.

Your review and comments are highly appreciated. 

Regards,
Will

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Wednesday, May 22, 2013 3:30 AM
To: Tina TSOU; Will Liu (Shucheng); Vishwas Manral; Will Liu (Shucheng)
Subject: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt

A new version of I-D, draft-manral-mpls-rfc3811bis-02.txt
has been successfully submitted by Vishwas Manral and posted to the
IETF repository.

Filename:	 draft-manral-mpls-rfc3811bis
Revision:	 02
Title:		 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management
Creation date:	 2013-05-20
Group:		 Individual Submission
Number of pages: 22
URL:             http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-02.txt
Status:          http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis
Htmlized:        http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-02

(Continue reading)

headers

Gregory Mirsky | 22 May 2013 00:56

Re: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv

Dear Authors, et al.,

firstly, I'll address format of MPLS-RT review as set by WG chairs:

The document is coherent, clearly useful and technically sound
The document is ready to be adopted by MPLS WG

Now several comments and possible typo corrections:

Perhaps re-word "No Associated Channel Type yet defined uses a TLV" into "So far none of defined Associated Channel Types uses a TLV as specified by RFC 5586". That seems to be more accurate as MPLS-TP BFD Proactive CV message format uses Source MEP-ID TLV, though not according to RFC 5586, that might be viewed as example of ACH TLV.
Introduction, first para, first sentense s/is/if/
Introduction, fourth para, in "However, of the 18 ACH Channel Types currently defined none allows the use of ACH TLVs [IANA-ACH]" I'd consider s/allows/requires/ to stress that up to now we managed to develop protocol suite without use of a single ACH TLV
Introduction, last para "This document determines that ACH TLVs are not useful …" might be re-worded to "This document states that ACH TLVs, as specified in RFC 5586, are not useful …"
Section 2, note that references to ACH TLVs exist in RFC 5586 outside of Section 3, e.g. Section 4.2.1.1, p.10, as well as in several figures, e.g. figure 6.
Section 3, if motivation of this document is to negate MUST in Section 3 of RFC 5586 that ACH TLV Header preceeds G-ACh message, then would following sufficiently express it: "A G-ACh message MAY NOT be preceeded by an ACH TLV Header."
Section 6, I think that we might only remove too restrictive requirement of RFC 5586 while allowing use of ACH TLV following G-ACh message.

Regards,

Greg

-----Original Message-----

From: Loa Andersson [mailto:loa <at> pi.nu]

Sent: Wednesday, May 08, 2013 1:01 AM

To: Lizhong Jin; Jia He; Gregory Mirsky; Eric Osborne (eosborne); Martin Vigoureux

Cc: draft-farbryantrel-mpls-retire-ach-tlv <at> tools.ietf.org; mpls-chairs <at> tools.ietf.org

Subject: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv

Jia, Lizhong, Greg and Eric,

You have been selected as an MPLS Review team reviewers for draft-farbryantrel-mpls-retire-ach-tlv-00.

Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

Are you able to review this draft by Mat 24, 2013?

Thanks, Loa

(as MPLS WG chair)

Loa Andersson email: loa <at> mail01.huawei.com

Senior MPLS Expert loa <at> pi.nu

Huawei Technologies (consultant) phone: +46 739 81 21 64

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

headers

George Swallow (swallow | 21 May 2013 18:22

Meaning of sub-TLVs for TLV 21 in Return Path Specified

Mach, et al. -

In section 4.1. Sending an Echo Request, it is stated:

The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the semantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single LSP. Why do you want the NIL FEC which only makes sense as part of a FEC stack? Under what circumstances would you ever use one of the multicast FECs (sub-TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 prefix? Note that if the prefix is multi-homed it may not even return to the originating PE! What is the meaning of a return path to an L2 VPN endpoint? George

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

headers

RFC Errata System | 21 May 2013 16:13

[Technical Errata Reported] RFC6428 (3629)

The following errata report has been submitted for RFC6428,
"Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS
Transport Profile".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6428&eid=3629

--------------------------------------
Type: Technical
Reported by: Alan Davey <alan.davey <at> metaswitch.com>

Section: 3.5.3

Original Text
-------------
The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID
(AC_ID) are as per [9].

Corrected Text
--------------
The length is the length of the data following the length field. The Global_ID, Node Identifier, and
Attachment Circuit ID (AC_ID) are as per [9].

Notes
-----

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06)
--------------------------------------
Title : Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the
MPLS Transport Profile
Publication Date : November 2011
Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed.
Category : PROPOSED STANDARD
Source : Multiprotocol Label Switching
Area : Routing
Stream : IETF
Verifying Party : IESG
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Daniele Ceccarelli | 21 May 2013 09:37

Re: poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document

Yes/support

BR
Daniele

---------- Forwarded message ----------
From: Loa Andersson <loa <at> pi.nu>
Date: Thu, May 16, 2013 at 10:49 AM
Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document
To: "mpls <at> ietf.org" <mpls <at> ietf.org>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp <at> tools.ietf.org" <draft-jjb-mpls-rsvp-te-hsmp-lsp <at> tools.ietf.org>, "mpls-chairs <at> tools.ietf.org" <mpls-chairs <at> tools.ietf.org>

Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls <at> ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--

Loa Andersson email: loa <at> mail01.huawei.com
Senior MPLS Expert loa <at> pi.nu
Huawei Technologies (consultant) phone: +46 739 81 21 64
_______________________________________________
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

The IESG | 21 May 2013 03:40

Document Action: 'Applicability of MPLS-TP Linear Protection for Ring Topologies' to Informational RFC (draft-ietf-mpls-tp-ring-protection-06.txt)

The IESG has approved the following document:
- 'Applicability of MPLS-TP Linear Protection for Ring Topologies'
  (draft-ietf-mpls-tp-ring-protection-06.txt) as Informational RFC

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/

Technical Summary

   This document presents an applicability of existing MPLS protection
   mechanisms, both local and end-to-end, to Multi-Protocol Label
   Switching Transport Profile (MPLS-TP) in ring topologies.  This
   document does not propose any new mechanisms or protocols.
   Protection on rings offers a number of opportunities for optimization
   as the protection choices are starkly limited (all traffic traveling
   one way around a ring can only be switched to travel the other way on
   the ring), but also suffers from some complications caused by the
   limitations of the topology.

   Requirements for MPLS-TP protection especially for protection in ring
   topologies are discussed in "Requirements of an MPLS Transport
   Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)
   Survivability Framework" (RFC 6372).  This document shows how MPLS-TP
   linear protection as defined in RFC 6378 can be applied to single
   ring topologies, discusses how most of the requirements are met, and
   describes scenarios in which the function provided by applying linear
   protection in a ring topology falls short of some of the
   requirements.

Working Group Summary

   This document was the subject of considerable debate in the MPLS
   working group. There was some concern about whether this work
   prohibited or devalued the development of specialised protection
   techniques for deployment in ring topologies.

   The document was re-worked to make it clear that it is basically
   an applicability statement showing how linear protection defined 
   in RFC 6378 can be applied to ring topologies, what function can
   be achieved, and what issues remain. It was made clear to the
   working group that specialist ring protection techniques were still
   in scope for the working group provided that they demonstrate 
   improvements over the application of linear protection, and provided
   they can interwork with general protection in the wider MPLS-TP
   network.

   A second WG last call was held and the document gained consensus.

   Please see RFC editor note for a commentary on the number of 
   front-page authors.

Document Quality 

   This an informational document, it describes how the technologies 
   defined in earlier RFCs can be applied to ring topologies. 

   The document has been reviewed needed, the working 
   group last call was brought to the attention of SG15 in 
   ITU-T. 

Personnel 

   Loa Andersson (loa <at> pi.nu) is the document shepherd 
   Adrian Farrel (Adrian <at> olddog.co.uk) is the Responsible AD

RFC Editor Note

   Please allow an exception to the normal front-page limit so 
   that all eight named authors can be present.  The WG chair/
   shepherd explains it as follows:

   > Early 2010 we had 5 or 6 different drafts addressing "mpls-tp-
   > ring-protection" from one aspect or another. Most of these
   > drafts had 2 or maybe 3 different authors.
   > 
   > The WG chairs took an initiative to discuss the possibilities to
   > merge all drafts into one. The discussion was partially
   > successful, and all draft but one, were merged into a single
   > document. Texts from all drafts were merged into draft-
   > weingarten-mpls-tp-ring-protection (later to be adopted as
   > the working group draft draft-ietf-mpls-tp-ring-protection.
   > 
   > The number of authors on the first page reflect text
   > contributions made to the drafts that were merged.

---

You may rename and reposition Section 1.4 according to your style guide.

---

If (and only if) you consider it necessary,  you may consider some of the text as Tables and apply captions as follows...

In Section 3.1 on page 19 "Table x : Backup LSPs for Node Protection"
In Section 3.1.1 on page 20 "Table x : Nodes Traversed by Protection: LSPs"
In Section 3.1.1 on page 21 "Table x : Bandwidth Utilization on Links During Protection"
In Section 3.2.2 on page 25 "Table x : Context Specific Labels for Connected LSPs"
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Adrian Farrel | 20 May 2013 18:34

Re: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv

Thanks Eric,

[Adding the MPLS list]

I just posted a revised I-D.

Adrian

> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:eosborne <at> cisco.com]
> Sent: 20 May 2013 17:11
> To: Loa Andersson; Lizhong Jin; Jia He; Gregory Mirsky; Martin Vigoureux
> Cc: draft-farbryantrel-mpls-retire-ach-tlv <at> tools.ietf.org; mpls-
> chairs <at> tools.ietf.org
> Subject: RE: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv
> 
> I have completed my review of this draft.  I have no issues with it, only a
few nits
> that I only pick in order to demonstrate that I have in fact actually read the
> document.
> 
> - The first sentence in section 1 is kind of bumpy.  I suggest something along
the
> lines of
> 
> ---
> RFC4385 says that if the first nibble of a PW packet carried over an MPLS
network
> has a value of 1 then the packet starts with a specific header format called
the
> Pseudowire Associated Channel Header, known as the PWACH or more generally
> as the ACH.
> ---
> 
> At a minimum, "defines that is the first" and "header format call the" are
typos.
> 
> 
> - Section 1 goes on to say "There are no currently live Internet-Drafts that
utilize
> ACH TLVs".  Is this a sentence that should live in perpetuity when this draft
> becomes an RFC?
> 
> - The security section suggests that removing the ACH TLV has a 'marginal
positive
> effect', but this ignores the idea that one could have an authentication TLV
or
> some sort of encrypted message; removing this capability has as much of a
> theoretical marginally negative effect as removing a vector for buffer bloat
or
> bogus TLV values.
> 
> 
> 
> 
> 
> eric
> 
> 
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa <at> pi.nu]
> > Sent: Wednesday, May 08, 2013 4:01 AM
> > To: Lizhong Jin; Jia He; Gregory Mirsky; Eric Osborne (eosborne); Martin
> > Vigoureux
> > Cc: draft-farbryantrel-mpls-retire-ach-tlv <at> tools.ietf.org; mpls-
> > chairs <at> tools.ietf.org
> > Subject: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv
> >
> > Jia, Lizhong, Greg and Eric,
> >
> > You have been selected as an MPLS Review team reviewers for draft-
> > farbryantrel-mpls-retire-ach-tlv-00.
> >
> > Note to authors: You have been CC'd on this email so that you can know
> > that this review is going on. However, please do not review your own
> > document.
> >
> > Reviews should comment on whether the document is coherent, is it useful
> > (ie, is it likely to be actually useful in operational networks), and is
> > the document technically sound?  We are interested in knowing whether
> > the document is ready to be considered for WG adoption (ie, it doesn't
> > have to be perfect at this point, but should be a good start).
> >
> > Reviews should be sent to the document authors, WG co-chairs and WG
> > secretary, and CC'd to the MPLS WG email list. If necessary, comments
> > may be sent privately to only the WG chairs.
> >
> > Are you able to review this draft by Mat 24, 2013?
> >
> > Thanks, Loa
> > (as MPLS WG chair)
> > --
> >
> >
> > Loa Andersson                        email: loa <at> mail01.huawei.com
> > Senior MPLS Expert                          loa <at> pi.nu
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64

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

headers

Muly Ilan | 20 May 2013 14:59

Comment on draft-ietf-mpls-tp-te-mib-06.txt

Hi,

Please fix a small typo.

Section 9.1.2. and section 9.3.2.

mplsTunnelExtOppositeDirTnlPtr à mplsTunnelExtOppositeDirPtr

Regards,

Muly

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

headers

Loa Andersson | 16 May 2013 19:49

poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document

Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls <at> ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--

-- 

Loa Andersson                        email: loa <at> mail01.huawei.com
Senior MPLS Expert                          loa <at> pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

headers

Adrian Farrel | 15 May 2013 12:59

Your draft charter

The current proposed text is at
https://datatracker.ietf.org/doc/charter-ietf-mpls/

Keep commenting and discussing with your chairs.

Adrian

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

headers

IETF Secretariat | 15 May 2013 12:56

State changed: charter-ietf-mpls-05-00

State changed to Informal IESG review.

URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

139	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