gmane.ietf.mpls

Call for proposals

Michel Gosse — 2013-05-22T12:51:17

The next editions of the MPLS & Ethernet World Congress and the co-located
SDN Summit will be organized in Paris next March 18-21, 2014.

Both events attracted 1350+ participants in 2013. 

The call for proposals are available online:
<http://www.uppersideconferences.com/> http://www.uppersideconferences.com/

 

 

 

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

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

Mach Chen — 2013-05-22T05:38:16

Hi George,

I guess your question is that why TLV 21 have to apply all the sub-TLVs of TLV 1.

For TLV 21, there are at least two usages, one is for specifying the return path of the echo reply, and if just for specifying the return path of echo reply, yes, it may not necessary to use all sub-TLVs of TLV 1. The other is for testing and validating the specified return path by carrying TLV 21( just as the FEC Stack TLV for forward path). For usage 2, the TLV 21 should have the same semantics as TLV 1, thus applying all sub-TLVs of TLV 1 is reasonable.

Many thanks,
Mach

From: mpls-bounces< at >ietf.org [mailto:mpls-bounces< at >ietf.org] On Behalf Of George Swallow (swallow)
Sent: Wednesday, May 22, 2013 12:23 AM
To: draft-ietf-mpls-return-path-specified-lsp-ping.all< at >tools.ietf.org
Cc: mpls< at >ietf.org
Subject: [mpls] 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

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

Manav Bhatia — 2013-05-22T03:23:53

Support.

Cheers, Manav


On Tue, May 21, 2013 at 10:41 PM, Autumn Liu <autumn.liu< at >ericsson.com>wrote:

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

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

Will Liu (Shucheng — 2013-05-22T03:02:41

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-rfc

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

Adrian Farrel — 2013-05-21T23:55:26

Oh,

I forgot to check the I-D!


Section 3 *is* that explicit statement. So you are only asking about s/MUST
NOT/MAY NOT/.

I don't believe that makes sense.

Cheers,
Adrian

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

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

Adrian Farrel — 2013-05-21T23:52:11

Hi Greg,

Thanks for the review.


Thanks for that.
 

Interesting point. Yes, the text should say "ACH TLV" since individual message
definitions are free to use TLVs. This usage finds itself in the main text, so
it is just the Abstract that needs attention.


Yup


I think I disagree. While 'requires' is seemingly stronger, the permissive
nature of 'allows' makes a stronger point here. I.e., not only is the TLV not
required, but it is even not allowed.


OK.
Makes note to stop using English when writing I-Ds :-)


Yeah. Point also made by Lizhong, so I'm updating Section 2 to read...

   Section 3 of RFC 5586 is deleted.

   References to ACH TLVs in Section 4 of RFC 5586 should also be
   disregarded.  Note that the text in Section 4 currently uses phrases
   like "ACH TLV(s), if present" so, with the removal of Section 3 that
   used to define ACH TLVs, they will not be present.


1. "MAY NOT" is the stuff of RFC 6919, not RFC 2119. So you mean "MUST
   NOT".
2. Doesn't deleting the whole section achieve

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

Gregory Mirsky — 2013-05-21T22:56:21

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

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

Autumn Liu — 2013-05-21T17:11:22

yes/support

-Autumn
---------- Forwarded message ----------
From: Loa Andersson <loa< at >pi.nu<mailto: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<mailto:mpls< at >ietf.org>" <mpls< at >ietf.org<mailto:mpls< at >ietf.org>>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp< at >tools.ietf.org<mailto:draft-jjb-mpls-rsvp-te-hsmp-lsp< at >tools.ietf.org>" <draft-jjb-mpls-rsvp-te-hsmp-lsp< at >tools.ietf.org<mailto:draft-jjb-mpls-rsvp-te-hsmp-lsp< at >tools.ietf.org>>, "mpls-chairs< at >tools.ietf.org<mailto:mpls-chairs< at >tools.ietf.org>" <mpls-chairs< at >tools.ietf.org<mailto: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<mailto:mpls< at >ietf.org>). Please give a technical
motivation for your support/not support, especially if you t

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

George Swallow (swallow — 2013-05-21T16:22:52

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

Re: [Technical Errata Reported] RFC6428 (3629)

Adrian Farrel — 2013-05-21T16:16:50

Greg,

You make a perfectly valid point, but I don't want to go through the whole draft
capitalising the names of all of the fields.

A

Global_ID,
the
Identifier, and
Global_ID,
All"
reached,
report, if
and Remote

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

Re: [MPLS] A doubt about RFC 6428

Gregory Mirsky — 2013-05-21T16:11:52

Dear Alan, et al.,

may I suggest minor modification by capitalizing Length to the proposed 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].

    Regards,

        Greg

________________________________
From: mpls-bounces< at >ietf.org [mailto:mpls-bounces< at >ietf.org] On Behalf Of Alan Davey
Sent: Tuesday, May 21, 2013 1:24 AM
To: David Allan I
Cc: mpls< at >ietf.org
Subject: Re: [mpls] [MPLS] A doubt about RFC 6428

Hi Dave

Thank you for your response.  I think that it is worth raising an erratum for section 3.5.3 because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

I propose the following.

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, No

Re: [Technical Errata Reported] RFC6428 (3629)

Gregory Mirsky — 2013-05-21T16:10:12

Dear Alan, et al.,
may I suggest minor modification by capitalizing Length to the proposed 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].

Regards,
greg


-----Original Message-----
From: mpls-bounces< at >ietf.org [mailto:mpls-bounces< at >ietf.org] On Behalf Of RFC Errata System
Sent: Tuesday, May 21, 2013 7:14 AM
To: David Allan I; swallow< at >cisco.com; jdrake< at >juniper.net; stbryant< at >cisco.com; adrian< at >olddog.co.uk; loa< at >pi.nu; swallow< at >cisco.com; rcallon< at >juniper.net
Cc: mpls< at >ietf.org; alan.davey< at >metaswitch.com; rfc-editor< at >rfc-editor.org
Subject: [mpls] [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&ei

Re: Retiring ACH TLVs

Eric Gray — 2013-05-21T15:40:55

Adrian/Stewart,

                I believe that past precedence exists in abundance to indicate that - if we produce an RFC
that updates RFC 5586, we do not also need to produce an RFC that replaces it for the same purpose.

                For instance, RFC 5586 was updated by RFC 6423.

                There are a number of RFCs that change the name space(s) defined in an earlier RFC for
IANA's management.  I believe that - as long as IANA has an unambiguous understanding of the
current applicable state for registries IANA manages - an updating RFC is sufficient.

                If we were - for some reason - required to replace RFC 5586 at a later date (this might be
needed to "advance" the standard, for instance), I assume we would "roll-up" all updates (and errata)
that are still applicable.

                Once an update that removes ACH TLVs has been published (or is near to being published),
it should no longer be necessary for folks submitting related drafts to explain why ACH TLVs are not
support

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

Eric Gray — 2013-05-21T15:14:40

Support.

-----Original Message-----
From: mpls-bounces< at >ietf.org [mailto:mpls-bounces< at >ietf.org] On Behalf Of Loa Andersson
Sent: Thursday, May 16, 2013 1:49 PM
To: mpls< at >ietf.org
Cc: draft-jjb-mpls-rsvp-te-hsmp-lsp< at >tools.ietf.org; mpls-chairs< at >tools.ietf.org
Subject: [mpls] 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 wo

Re: Retiring ACH TLVs

Lizhong Jin — 2013-05-21T14:57:10

Hi Adrian,

[Lizhong] Thanks for the reply. I do not have strong preferrence for bising
RFC5586. A note in section 2 maybe be enough, e.g, since ACH TLV has been
removed, the ACH TLV description in section 4 will also be removed.

Thanks
Lizhong


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

Re: Retiring ACH TLVs

Stewart Bryant — 2013-05-21T14:34:02

"If the WG prefers, we could bis 5586 to remove all discussion of the 
ACH TLV."

Noting that this will inevitably take longer, and is not mutually
exclusive with this approach. However the longer we take the
longer we will have to answer the question about why
we say we preclude them in each ACK draft.

... but is up to the WG, we can follow either path.

Stewart


On 20/05/2013 17:42, Adrian Farrel wrote:

Re: [Technical Errata Reported] RFC6428 (3629)

David Allan I — 2013-05-21T14:17:17

I agree with the proposed change...

Dave 

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor< at >rfc-editor.org] 
Sent: Tuesday, May 21, 2013 7:14 AM
To: David Allan I; swallow< at >cisco.com; jdrake< at >juniper.net; stbryant< at >cisco.com; adrian< at >olddog.co.uk; loa< at >pi.nu; swallow< at >cisco.com; rcallon< at >juniper.net
Cc: alan.davey< at >metaswitch.com; mpls< at >ietf.org; rfc-editor< at >rfc-editor.org
Subject: [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

[Technical Errata Reported] RFC6428 (3629)

RFC Errata System — 2013-05-21T14:13:50

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)
ca

Re: [MPLS] A doubt about RFC 6428

David Allan I — 2013-05-21T13:50:53

I agree with your proposed change.

cheers
Dave

________________________________
From: Alan Davey [mailto:Alan.Davey< at >metaswitch.com]
Sent: Tuesday, May 21, 2013 1:24 AM
To: David Allan I
Cc: mpls< at >ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

Thank you for your response.  I think that it is worth raising an erratum for section 3.5.3 because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

I propose the following.

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].

Thanks
Alan

From: David Allan I [mailto:david.i.allan< at >ericsson.com]
Sent: 13 May 2013 20:58
To: Alan Davey
Cc: mpls< at >ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

It is all in how you interpret "The

FW: I-D Action: draft-mahesh-karp-rsvp-te-analysis-01.txt

Adrian Farrel — 2013-05-21T12:14:23

Heads up.

Discussion on the Karp list, please.

Adrian

directories.
Guide

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

Re: [MPLS] A doubt about RFC 6428

Alan Davey — 2013-05-21T08:23:35

Hi Dave

Thank you for your response.  I think that it is worth raising an erratum for section 3.5.3 because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

I propose the following.

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].

Thanks
Alan

From: David Allan I [mailto:david.i.allan< at >ericsson.com]
Sent: 13 May 2013 20:58
To: Alan Davey
Cc: mpls< at >ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

It is all in how you interpret "The length is the length of the following data."  Which is referring to the diagram above (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields.

If it said "The length is the length of the data follo