headers
Julia Erdenebold | 1 May 2012 02:01
Favicon

FW: The MPLS 2012 International Conference Call For Papers

 

Due to numerous requests, we are extending the deadline for the submission of Call for Presentation abstract to Friday May 11. Please make sure to submit your abstracts to mpls2012-cfp <at> isocore.com.

 

For further information, please refer to http://www.isocore.com/mpls2012/call_for_papers/cfp.htm.

 

Regards,

Julia

 

 

The MPLS 2012 International Conference, the 15th Annual International

Conference on MPLS and Related Technologies, will be held October 28 -

31, 2012, in Washington, DC. The Technical Program Committee is

soliciting abstracts summarizing a proposed presentation representing

original/unpublished work covering cutting-edge topics.

 

Presentations covering new technologies and operational experience are

solicited from network equipment vendors, service/transport providers,

government agencies, the research community, and enterprise users.

The deadline for submission of presentation proposals is April 30, 2012.

If you want further information on MPLS 2012 or want to submit a

presentation abstract, please see the following URL:

 

 

Many of these topics have been of interest to members of <this community>

in the past, and many people active on this list have been

presenters at past events.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Loa Andersson | 1 May 2012 18:32
Picon

The MPLS WG Review Team

Working Group,

The working group chairs have discussed the comparatively high
number of drafts on queue to become working groups drafts, and decided
that we need help in evaluating drafts before we poll them to become
working documents.

We have asked some of the more active and experienced working group
members to be part of a Review Team. Each member will review some
documents before the Vancouver meeting. The review team will be
set up as an experiment through the Vancouver meeting and after
evaluation, the chairs will decide whether the experiment will be
made permanent.

The reviewers will be asked comment on whether the document is coherent,
if is it useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?

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

Thanks, George, Loa, and Ross
WG co-chairs

--

-- 

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
Permalink | Reply | 2 comments |
headers
Kireeti Kompella | 1 May 2012 20:19
Favicon

Re: entropy label draft: reserved label for ELI

Hi All,

Thanks very much for your responses!

While I'll leave the final determination to the WG chairs, my reading of the responses to both of these
questions was overwhelmingly positive, i.e., allocate a reserved label for ELI, and associate ELs with tunnels.

Based on that, I'll update the draft to reflect these changes.  ETA: May 8.

Meanwhile, I hope the WG chairs chime in with their assessment of the responses.

Thanks again,
Kireeti.

On Apr 12, 2012, at 12:47 , Kireeti Kompella wrote:

> Hi All,
> 
> Following up on the presentation at IETF 83, I promised to "take this to the list".
> 
> The two questions are:
> 1) should we make the ELI a "well-known" reserved label?
> 2) should we associate the EL with tunnel labels or with application labels?
> 
> This email is to poll the list about (1).
> 
> Making the ELI a reserved label has the following benefits:
> a) Transit LSRs can hash on labels up to the ELI and one more (the EL), rather than processing all labels in
the label stack.
> 
> b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means of bailing out early from grabbing
"deeper" fields (e.g., IP headers within Ethernet within ...) for hashing.
> 
> c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid adding another entropy-label
for the RSVP tunnel *if* the transit LSR finds a reserved ELI already in the stack.  Call this a 'short
circuit' rule.
> 
> d) The short circuit rule can also be used for Carrier of Carrier VPNs and other situations with label hierarchy.
> 
> e) A reserved ELI obviates the need for upstream ELI allocation for mLDP and P2MP RSVP-TE.
> 
> (Thanks to Shane for providing some of the above.)
> 
> The main drawback is the scarcity of reserved labels, which hopefully is addressed by the pixie label draft.
> 
> So, the question is: should we make the ELI a reserved label?  (If no, a short reason would be helpful.)
> 
> Kireeti.
> 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 4 comments |
headers
Muly Ilan | 1 May 2012 23:01
Favicon

Question regarding draft-ietf-mpls-tp-mip-mep-map-01

Dear Authors,

 

For the per-interface MIP model how do you suggest to perform a route tracing over a static MPLS-TP LSP?

 

According to RFC6371 section 6.4 “Route tracing should always discover the full list of MIPs and of peer MEPs”.

RFC6424 section 4 specifies a method for route tracing using LSP-Ping. It explains to use MPLS TTL expiry to reach a specific node.

 

Your solution to address a specific in-MIP or out-MIP is to include the MIP identifier in the sent OAM packet. RFC6424 defines extensions to LSP-Ping, in the form of new TLVs and sub-TLVs, that allow to identify the target MIP within the node.

However, for a static MPLS-TP LSP the MIP identifiers along the path are not known at the head-end prior to performing the route tracing and receiving the LSP-Pings echo responses.

Seems like a chicken and egg issue.

 

I hope that there’s a more elegant way than having the management plane configure all the relevant path identifiers at the head-end before attempting a route trace.

 

Regards,

 

Muly Ilan

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 1 comment |
headers
Loa Andersson | 2 May 2012 09:37
Picon

wg chair read on using a reserved label as ELI

Working Group,

The MPLS wg chairs read on the discussion on allocating on of the
reserved labels as ELI is that there are good support in the working
group do to so. The new version of the document should therefore
reflect this.

Loa, George, Ross
wg co-chairs

--

-- 

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
Permalink | Reply | 0 comments |
headers
liu.guoman | 2 May 2012 10:45
Picon

Re: New Version Notification for draft-liu-mpls-tp-interconnected-ring-protection-02.txt


hi.all
this is new version of this draft according to all comments and questions . the protection mainly consider the special protection scenario where
interconnection link or interconnect node has the failure. if only single-ring protection solution is used, it can't recovery the failure.
so it is necessary to consider the protection scenarios in my mind.

here welcome to your comments and suggestions for this draft.
thank you!

B.R.
Liu



----- 转发人 刘国满180323/user/zte_ltd 时间 2012-05-02 16:39 -----
internet-drafts <at> ietf.org

2012-04-27 14:45

收件人
 liu.guoman <at> zte.com.cn
抄送
 wyaacov <at> gmail.com
主题
 New Version Notification for        draft-liu-mpls-tp-interconnected-ring-protection-02.txt





A new version of I-D, draft-liu-mpls-tp-interconnected-ring-protection-02.txt has been successfully submitted by Liu Guoman and posted to the IETF repository.

Filename:                  draft-liu-mpls-tp-interconnected-ring-protection
Revision:                  02
Title:                                   MPLS-TP protection for interconnected rings
Creation date:                  2012-04-27
WG ID:                                   Individual Submission
Number of pages: 11

Abstract:
  According to the ring protection Requirements in RFC 5654,
  Requirement 93 : When a network is constructed from interconnected
  rings, MPLS-TP MUST support recovery mechanisms that protect user
  data that traverses more than one ring.  This includes the
  possibility of failure of the ring-interconnect nodes and links,so
  this document will describle all kinds of interconnected ring
  Scenarios and several protection solutions for recovery the failure
  of the ring-interconnect nodes and Links. .


  This document is a product of a joint Internet Task Force(IETF) /
  International Telecommunications Union Telecommunications
  Standardization Sector (ITU-T) effort to include an MPLS Transport
  Profile within the IETF MPLS and PWE3 architectures to support the
  capabilities and functionalities of a packet transport network as
  defined by the ITU-T.

                                                                                 


The IETF Secretariat


-------------------------------------------------------- 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
Permalink | Reply | 0 comments |
headers
Adrian Farrel | 2 May 2012 12:19
Picon

Re: entropy label draft: reserved label for ELI

> Based on that, I'll update the draft to reflect these changes.  ETA: May 8.

2012 ?

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Aissaoui, Mustapha (Mustapha | 2 May 2012 17:35
Favicon

Error in RFC 6425 - "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"

Dear authors of RFC 6425,
I believe the length of the "RSVP P2MP IPv6 Session Sub-TLV" in Section 3.1.1 should be 44 bytes and not 56
bytes to match the format shown in Section 3.1.1.2. 

It may be the 56 byte figure was copied over from RFC 4379 which uses a 16-byte "IPv6 tunnel end point address"
as the top field in the sub-TLV in the case of an IPv6 P2P RSVP session. With an IPv6 P2MP RSVP session that
field is replaced with the P2MP-ID which is a 4-byte field only.

Mustapha.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 1 comment |
headers
Adrian Farrel | 3 May 2012 12:45
Picon

Re: Error in RFC 6425 - "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping"

Hi Mustapha,

You're right. The I-D (up until quite late) had the IPv6 P2MP ID as 128 bit.
That got fixed but the byte count was missed.

Would you care to raise the Erratum?

A

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: 02 May 2012 16:36
> To: mpls <at> ietf.org
> Subject: [mpls] Error in RFC 6425 - "Detecting Data-Plane Failures in
Point-to-
> Multipoint MPLS - Extensions to LSP Ping"
> 
> Dear authors of RFC 6425,
> I believe the length of the "RSVP P2MP IPv6 Session Sub-TLV" in Section 3.1.1
> should be 44 bytes and not 56 bytes to match the format shown in Section
> 3.1.1.2.
> 
> It may be the 56 byte figure was copied over from RFC 4379 which uses a
16-byte
> "IPv6 tunnel end point address" as the top field in the sub-TLV in the case of
an
> IPv6 P2P RSVP session. With an IPv6 P2MP RSVP session that field is replaced
with
> the P2MP-ID which is a 4-byte field only.
> 
> Mustapha.
> _______________________________________________
> 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
Permalink | Reply | 0 comments |
headers
Loa Andersson | 4 May 2012 09:19
Picon

IPR's on draft-ietf-mpls-tp-te-mib

Working Group,

The wg chairs prepares

- draft-ietf-mpls-tp-te-mib

for WG last call.

Before the wg last, we would like to check whether
there is IPR on the documents that needs to be disclosed.

Are you aware of any IPR that applies to the two drafts?
If so, has this IPR been disclosed in compliance with IETF IPR
rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to 
this email regardless of whether or not you are aware of any relevant 
IPR. The documents will not advance to the next stage until a response 
has been received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author or 
contributor, then please explicitly respond only if you are aware of any 
IPR that has not yet been disclosed in conformance with IETF rules.
If you are aware of IPR's please respond to this mail before May 18th.

Thanks, Loa

(as MPLS WG co-chair)
--

-- 

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
Permalink | Reply | 4 comments |

Gmane