internet-drafts | 12 Feb 17:46 2016
Picon

I-D Action: draft-ietf-mpls-residence-time-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Residence Time Measurement in MPLS network
        Authors         : Greg Mirsky
                          Stefano Ruffini
                          Eric Gray
                          John Drake
                          Stewart Bryant
                          Alexander Vainshtein
	Filename        : draft-ietf-mpls-residence-time-03.txt
	Pages           : 25
	Date            : 2016-02-12

Abstract:
   This document specifies G-ACh based Residence Time Measurement and
   how it can be used by time synchronization protocols being
   transported over MPLS domain.

   Residence time is the variable part of propagation delay of timing
   and synchronization messages and knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a PTP event
   message.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/

There's also a htmlized version available at:
(Continue reading)

RFC Errata System | 12 Feb 00:38 2016

[Errata Rejected] RFC3107 (4500)

The following errata report has been rejected for RFC3107,
"Carrying Label Information in BGP-4".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Alexander Okonnikov <alexander.okonnikov <at> gmail.com>
Date Reported: 2015-10-13
Rejected by: Deborah Brungard (IESG)

Section: 5

Original Text
-------------
   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  The value of this capability is 4.

Corrected Text
--------------
   A BGP speaker that is capable of handling multiple routes to a
   destination (as described above) should use the Capabilities Optional
   Parameter, as defined in [BGP-CAP], to inform its peers about this
   capability.  This capability is advertised using the Capability Code
(Continue reading)

RFC Errata System | 12 Feb 00:40 2016

[Errata Held for Document Update] RFC3107 (4582)

The following errata report has been held for document update 
for RFC3107, "Carrying Label Information in BGP-4". 

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

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: David Lamparter <equinox <at> opensourcerouting.org>
Date Reported: 2016-01-06
Held by: Deborah Brungard (IESG)

Section: GLOBAL

Original Text
-------------
[... section 3: ...]
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

4. Advertising Multiple Routes to a Destination
(Continue reading)

RFC Errata System | 12 Feb 00:33 2016

[Errata Rejected] RFC3107 (4499)

The following errata report has been rejected for RFC3107,
"Carrying Label Information in BGP-4".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Alexander Okonnikov <alexander.okonnikov <at> gmail.com>
Date Reported: 2015-10-13
Rejected by: Deborah Brungard (IESG)

Section: 3

Original Text
-------------
   A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000.  (Of course, terminating the
   BGP session also withdraws all the previously advertised routes.)

Corrected Text
--------------
(Continue reading)

RFC Errata System | 12 Feb 00:28 2016

[Errata Verified] RFC3107 (4498)

The following errata report has been verified for RFC3107,
"Carrying Label Information in BGP-4". 

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

--------------------------------------
Status: Verified
Type: Technical

Reported by: Alexander Okonnikov <alexander.okonnikov <at> gmail.com>
Date Reported: 2015-10-13
Verified by: Deborah Brungard (IESG)

Section: 3

Original Text
-------------
   The label(s) specified for a particular route (and associated with
   its address prefix) must be assigned by the LSR which is identified
   by the value of the Next Hop attribute of the route.

   When a BGP speaker redistributes a route, the label(s) assigned to
   that route must not be changed (except by omission), unless the
   speaker changes the value of the Next Hop attribute of the route.

Corrected Text
--------------
   The label(s) specified for a particular route (and associated with
(Continue reading)

IETF Secretariat | 11 Feb 10:15 2016
Picon

The MPLS WG has placed draft-ryoo-mpls-tp-aps-updates in state "Candidate for WG Adoption"


The MPLS WG has placed draft-ryoo-mpls-tp-aps-updates in state 
Candidate for WG Adoption (entered by Loa Andersson)

The document is available at
https://datatracker.ietf.org/doc/draft-ryoo-mpls-tp-aps-updates/

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

internet-drafts | 10 Feb 19:50 2016
Picon

I-D Action: draft-ietf-mpls-residence-time-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Residence Time Measurement in MPLS network
        Authors         : Greg Mirsky
                          Stefano Ruffini
                          Eric Gray
                          John Drake
                          Stewart Bryant
                          Alexander Vainshtein
	Filename        : draft-ietf-mpls-residence-time-02.txt
	Pages           : 24
	Date            : 2016-02-10

Abstract:
   This document specifies G-ACh based Residence Time Measurement and
   how it can be used by time synchronization protocols being
   transported over MPLS domain.

   Residence time is the variable part of propagation delay of timing
   and synchronization messages and knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a PTP event
   message.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/

There's also a htmlized version available at:
(Continue reading)

Michel Gosse | 9 Feb 14:19 2016
Picon

MPLS+SDN+NFV World 2016: One month left

After the marketing rush, what is left of SDN/NFV?

Learn from an impressive set of Service Providers:

MPLS & SDN Track: Segment Routing Progress, SDN for Core Networks, Analytics & Multicast

NFV & Open Source track: Service Insurance, Open Ecosystem, Use Cases

Software Defined WAN: Next Generation CPE, Security

 

Full agenda and more information: http://www.uppersideconferences.com/mpls-sdn-nfv/

 

 

MPLS+SDN+NFV World. Marriott Conference Center. Paris. 08/11 March 2016

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
RFC Errata System | 8 Feb 20:33 2016

[Errata Held for Document Update] RFC7697 (4586)

The following errata report has been held for document update 
for RFC7697, "MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
Identifiers Management Information Base (MIB)". 

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

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Venkatesan Mahalingam <venkat.mahalingams <at> gmail.com>
Date Reported: 2016-01-09
Held by: Deborah Brungard (IESG)

Section: 9.1

Original Text
-------------
9.1.  IANA Considerations for MPLS-OAM-ID-STD-MIB

   IANA has to assign the OID { mplsStdMIB 21 } to the
   MPLS-OAM-ID-STD-MIB module specified in this document.

Corrected Text
--------------
9.1.  IANA Considerations for MPLS-OAM-ID-STD-MIB

   IANA has assigned the OID { mplsStdMIB 21 } to the
   MPLS-OAM-ID-STD-MIB module specified in this document.

Notes
-----
Missed by RFC Editor to change from future tense "has to assign" to past tense "has assigned".

--------------------------------------
RFC7697 (draft-ietf-mpls-tp-oam-id-mib-11)
--------------------------------------
Title               : MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
Identifiers Management Information Base (MIB)
Publication Date    : January 2016
Author(s)           : P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros
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

RFC Errata System | 8 Feb 20:25 2016

[Errata Verified] RFC7439 (4595)

The following errata report has been verified for RFC7439,
"Gap Analysis for Operating IPv6-Only MPLS Networks". 

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

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Adrian Farrel <adrian <at> olddog.co.uk>
Date Reported: 2016-01-15
Verified by: Deborah Brungard (IESG)

Section: 3.5

Original Text
-------------
   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
   lack support for IPv6 in defining MplsExtendedTunnelId and
   MplsLsrIdentifier.  These textual conventions are used in the MPLS-TE
   MIB specification [RFC3812], the GMPLS-TE MIB specification [RFC4802]
   and the FRR extension [RFC6445].  "Definitions of Textual Conventions
   (TCs) for Multiprotocol Label Switching (MPLS) Management" [MPLS-TC]
   tries to resolve this gap by marking this textual convention as
   obsolete.

Corrected Text
--------------
   RFC 3811 [RFC3811] defines the textual conventions for MPLS.  These
   lack support for IPv6 in defining MplsExtendedTunnelId.  This textual
   conventions is used in the MPLS-TE MIB specification [RFC3812], the 
   GMPLS-TE MIB specification [RFC4802], and the FRR extension
   [RFC6445].  "Definitions of Textual Conventions (TCs) for 
   Multiprotocol Label Switching (MPLS) Management" [MPLS-TC] tries
   to resolve this gap by marking this textual convention as obsolete.

Notes
-----
Section 3.5 comments about MplsLsrIdentifier.
It says that RFC 3811 "lack[s] support for IPv6 in defining MplsExtendedTunnelId and
MplsLsrIdentifier." It also says that "[MPLS-TC] tries to resolve this gap by marking this textual
convention as obsolete."

Note that the second quote refers to just one TC.

Looking at 3811, 5036, and (most importantly) 7552, it seems to me that the LSR Identifier is *always* a 32
bit quantity regardless of whether the LDP system is v4-only, v4/v6, or v6-only. 

Furthermore, draft-manral-mpls-rfc3811bis (i.e., [MPLS-TC]) clearly shows no
change to MplsLsrIdentifier while marking MplsExtendedTunnelId as obsolete.

Notwithstanding that draft-manral-mpls-rfc3811bis appears to have been abandoned in state "candidate
for WG adoption", it looks to me that RFC 7439 has an error we could call a typo.

--------------------------------------
RFC7439 (draft-ietf-mpls-ipv6-only-gap-04)
--------------------------------------
Title               : Gap Analysis for Operating IPv6-Only MPLS Networks
Publication Date    : January 2015
Author(s)           : W. George, Ed., C. Pignataro, Ed.
Category            : INFORMATIONAL
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

류정동 | 6 Feb 02:28 2016
Picon
Picon

https://datatracker.ietf.org/liaison/1435/

Hummmmmmmm….. 3
-------- 원본 이메일 --------
보낸 사람: Huub van Helvoort <huubatwork <at> gmail.com>
날짜: 2016/2/6 오전 7:57 (GMT+09:00)
받은 사람: "Andrew G. Malis" <agmalis <at> gmail.com>, Scott Mansfield <scott.mansfield <at> ericsson.com>
참조: mpls <at> ietf.org, mpls-chairs <at> ietf.org
제목: Re: [mpls] https://datatracker.ietf.org/liaison/1435/

Hummmmmmmm….. 2

On 05-02-16 23:36, Andrew G. Malis wrote:
Hummmmmmmm…..

On Fri, Feb 5, 2016 at 5:29 PM, Scott Mansfield <scott.mansfield <at> ericsson.com> wrote:
I'm ok with this.  Any other words?  Please hum if you think this is ok and I will draft it up and put it into the tool.

Thanks,
-scott.

-----Original Message-----
From: Loa Andersson [mailto:loa <at> pi.nu]
Sent: Thursday, February 04, 2016 10:33 PM
To: Scott Mansfield; mpls <at> ietf.org; mpls-chairs <at> ietf.org
Subject: Re: https://datatracker.ietf.org/liaison/1435/

Scott,

So maybe just a short response.

"Thanks for your liaison on the final approval of the MPLS-TP Recommendations, this marks a step in the joint MPLS-TP project.

IETF have to date published 45 MPLS-TP RFC from 7 working groups and independent document. IETF still have 11 active Internet Drafts.

We are looking forward to your support completing the MPLS-TP project."

I think you can correct grammar and spelling and send it timely.

Working Group,

Please comment on this?

/Loa

On 2016-02-04 21:13, Scott Mansfield wrote:
> I'm willing to help, but I don’t see anything here worth commenting on, unless there is a burning desire to make comments now.  None of the documents liaised have changed dramatically since early 2014.
>
> -scott.
>
> -----Original Message-----
> From: Loa Andersson [mailto:loa <at> pi.nu]
> Sent: Thursday, February 04, 2016 5:58 AM
> To: mpls <at> ietf.org; mpls-chairs <at> ietf.org; Scott Mansfield
> Subject: https://datatracker.ietf.org/liaison/1435/
>
> Working Group,
>
> We have a liaison from SG15 that we need to decide on how to respond
> to https://datatracker.ietf.org/liaison/1435/
> I've asked Scott to help us coordinate this.
> Any comments are welcome.
>
> /Loa
> mpls wg co-chair
>
_______________________________________________
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


-- ***************************************************************** 请记住,你是独一无二的,就像其他每一个人一样
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Gmane