internet-drafts | 7 Jul 01:55 2015
Picon

I-D Action: draft-cui-mpls-tp-mfp-use-case-and-requirements-05.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 Working Group of the IETF.

        Title           : Use Cases and Requirements for MPLS-TP multi-failure protection
        Authors         : Zhenlong Cui
                          Rolf Winter
                          Himanshu Shah
                          Sam Aldrin
                          Masahiro Daikoku
	Filename        : draft-cui-mpls-tp-mfp-use-case-and-requirements-05.txt
	Pages           : 8
	Date            : 2015-07-06

Abstract:
   For the Multiprotocol Label Switching Transport Profile (MPLS-TP)
   linear protection capable of 1+1 and 1:1 protection has already been
   defined.  That linear protection mechanism has not been designed for
   handling multiple, simultaneously occuring failures, i.e. multiple
   failures that affect the working and the protection entity during the
   same time period.  In these situations currently defined protection
   mechanisms would fail.

   This document introduces use cases and requirements for mechanisms
   that are capable of protecting against such failures.  It does not
   specify a multi-failure protection mechanism itself.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-cui-mpls-tp-mfp-use-case-and-requirements/

(Continue reading)

internet-drafts | 6 Jul 17:13 2015
Picon

I-D Action: draft-ietf-mpls-lsp-ping-relay-reply-10.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 Working Group of the IETF.

        Title           : Relayed Echo Reply mechanism for LSP Ping
        Authors         : Jian Luo
                          Lizhong Jin
                          Thomas Nadeau
                          George Swallow
	Filename        : draft-ietf-mpls-lsp-ping-relay-reply-10.txt
	Pages           : 17
	Date            : 2015-07-06

Abstract:
   In some inter autonomous system (AS) and inter-area deployment
   scenarios for RFC 4379 "Label Switched Path (LSP) Ping and
   Traceroute", a replying Label Switching Router (LSR) may not have the
   available route to an initiator, and the Echo Reply message sent to
   the initiator would be discarded resulting in false negatives or
   complete failure of operation of LSP Ping and Traceroute.  This
   document describes extensions to LSP Ping mechanism to enable the
   replying LSR to have the capability to relay the Echo Response by a
   set of routable intermediate nodes to the initiator.  This document
   updates RFC 4379.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-relay-reply/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-relay-reply-10
(Continue reading)

Tarek Saad (tsaad | 6 Jul 15:52 2015
Picon

FW: MPLS WG IETF93 agenda requests and status reports

Hi WG,

There seems to be an email delivery problem reaching group I-D recipients.. I’m forwarding the below message to WG alias to make sure it reaches the I-D (co)authors below.

>>
Dear (co)authors of WG/I-D drafts,

In preparation for the MPLS WG agenda for IETF93 in Prague, we are asking you confirm whether you will require a time slot off the agenda to present the update for the Individual/WG drafts you are driving (ignore if already asked for a slot).
WG Draft authors are expected to present if there are open issues to discuss, or to send a status report a week prior to the WG meeting that includes: any changes that have recently been made, any open discussions or issues,  planned next steps, and a schedule.

Please send your agenda requests by responding to this email as soon as possible. Include draft name, and who will be presenting. A tentative agenda will be uploaded on July 6th.
Slides will be due on Sunday July 19, 2015. (Send slides to the addresses cc'ed above.)

Regards,
Tarek

WG docs:

I-Ds:

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 4 Jul 17:37 2015
Picon

I-D Action: draft-ietf-mpls-ldp-mrt-01.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 Working Group of the IETF.

        Title           : LDP Extensions to Support Maximally Redundant Trees
        Authors         : Alia Atlas
                          Kishore Tiruveedhula
                          Chris Bowers
                          Jeff Tantsura
                          IJsbrand Wijnands
	Filename        : draft-ietf-mpls-ldp-mrt-01.txt
	Pages           : 16
	Date            : 2015-07-04

Abstract:
   This document specifies extensions to the Label Distribution
   Protocol(LDP) to support the creation of label-switched paths for
   Maximally Redundant Trees (MRT).  A prime use of MRTs is for unicast
   and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.

   The sole protocol extension to LDP is simply the ability to advertise
   an MRT Capability.  This document describes that extension and the
   associated behavior expected for LSRs and LERs advertising the MRT
   Capability.

   MRT-FRR uses LDP multi-topology extensions and requires three
   different multi-topology IDs to be allocated from the LDP MT-ID
   space.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-ldp-mrt-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-ldp-mrt-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Nobo Akiya | 4 Jul 10:16 2015
Picon

Review of draft-mirsky-mpls-bfd-directed-03

Hello,

I’ve been selected as a reviewer for draft-mirsky-mpls-bfd-directed-03. Please find my review below.

I believe this is a useful, coherent, and technically sound document. However, it does have issues that require attention and consideration.


Section 2

o if reverse direction is in Down state, the head-end node would not
   receive indication of forward direction failure from its egress
   peer.

[NOBO] I found above to be slightly unclear in 2 aspects.

Since this section is describing the limitations of using BFD on an unidirectional explicitly routed path, what does "if reverse direction is in Down state" mean?

Additionally, "would not receive indication of forward direction failure from its egress peer" is a bit cryptic. If the egress peer detected that forward direction failed (e.g., BFD session timed out), then the egress peer will send few BFD control packets with DOWN state, IP routed. Thus the ingress peer will notice the problem of the forward direction.

Readers can likely benefit from having this bullet point better clarified.


Section 3.1.1

   If the egress LSR fails to establish the BFD session because path
   specified in the Reverse Path TLV is not known, the egress MAY
   establish the BFD session over IP network [RFC5884] and MAY send Echo
   Reply with the Reverse Path TLV received and the return code set to
   "Failed to establish the BFD session". The specified reverse path
   was not found" (TBD4) Section 3.4.

[NOBO] There are two instances of "MAY" in above.

If the egress establishes the BFD session over IP network and does not send Echo Reply with "error", then it would be difficult for the ingress to know what path egress is using for the BFD session (IP routed or ingress specified path). To avoid this, should the second MAY be MUST, such that if the egress chose to use IP network, then the egress has to send the Echo Reply with "error"?

Related to this, if the egress chose to use the BFD session over IP network, but the ingress specified path became available some time later, then what is the expected behavior? Should this this described in the document?

Also there are 3 instances of '"' (quotation) characters in above, but the second instance should be removed (nit).


Section 3.1.2

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Label Stack Element                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Label Stack Element                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[NOBO] It would be good to clarify what "Label Stack Element" is. Is it the 4 octet index defining the offset in the SID/Index space? Potentially, we can benefit from referencing a document that describes its details (e.g., draft-ietf-isis-segment-routing-extensions).


Section 3.3 & Section 4

   Section 3.3

   When LSP ping is used to bootstrap BFD session this document updates
   this and defines that LSP Ping MUST include the FEC corresponding to
   the destination segment and SHOULD NOT include FECs corresponding to
   some or all of segment imposed by the initiator. Operationally such
   restriction would not cause any problem or uncertainty as LSP ping
   with FECs corresponding to some or all segments or traceroute may
   preceed the LSP ping that bootstraps the BFD session.

   Section 4

   In network presented in Figure 4 node A monitors two tunnels to node
   H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap BFD session to monitor
   the first tunnel, node A MUST include BFD Discriminator TLV with
   Discriminator value N and MAY include BFD Reverse Path TLV that
   references H-G-D-C-B-A tunnel. To bootstrap BFD session to monitor
   the second tunnel, node A MUST include BFD Discriminator TLV with
   Discriminator value M and MAY include BFD Reverse Path TLV that
   references H-G-F-E-B-A tunnel.

[NOBO] Since FEC in the MPLS Echo Request will only carry the last SID, there is no way for the egress to distinguish the incoming BFD session bootstrapping request for A-B-C-D-G-H and A-B-E-F-G-H, if we go by RFC5884. By RFC5884, it would be one BFD session that overrides the old (i.e., FEC in both bootstrap requests are the same). If you want the procedures to work, you'll need to reference draft-ietf-bfd-rfc5884-clarifications where BFD discriminator becomes a demux key on the egress.


Section 4

   If an operator needs node H to monitor path to node A, e.g.
   H-G-D-C-B-A tunnel, then by looking up list of known Reverse Paths it
   MAY find and use existing BFD sessions.

[NOBO] There is a small window where both sides will end up initiating the BFD session bootstrapping. Do we want this document to clarify that scenario or leave it be?


Section 3.2 & Section 5.2

   Section 3.2

   IPv6 can be data plane of choice for Segment Routed tunnels
   [I-D.previdi-6man-segment-routing-header]. In such networks the BFD
   Reverse Path TLV described in Section 3.1.1 can be used as well. IP
   networks, unlike IP/MPLS, do not require use of LSP ping with BFD
   Discriminator TLV[RFC4379] to bootstrap BFD session. But to specify
   reverse path of a BFD session in IPv6 environment the BFD
   Discriminator TLV MUST be used along with the BFD Reverse Path TLV.
   The BFD Reverse Path TLV in IPv6 network MUST include sub-TLV.

   Section 5.2

   The IANA is requested to assign two new sub-TLV types from
   "Multiprotocol Label Switching Architecture (MPLS) Label Switched
   Paths (LSPs) Ping Parameters - TLVs" registry, "Sub-TLVs for TLV
   Types 1, 16, and 21" sub-registry.

    +----------+-------------------------------------+---------------+
     | Value    | Description                         | Reference     |
    +----------+-------------------------------------+---------------+
     | X (TBD2) | Segment Routing MPLS Tunnel sub-TLV | This document |
     | X (TBD3) | Segment Routing IPv6 Tunnel sub-TLV | This document |
    +----------+-------------------------------------+---------------+

[NOBO] We are allocating "Segment Routing IPv6 Tunnel sub-TLV" in the LSP ping registry, but section 3.2 seems to indicate that we are not using LSP ping to bootstrap the BFD session. So ... I'm a bit confused. If we are using something else, besides LSP ping, to bootstrap BFD sessions for IPv6 Segment Routing, then are we allocating this Sub-TLV in the wrong registry space?


General

[NOBO] For the IP/MPLS case, if we want the egress to use BFD session over specified segment stack, then it would be best for the IP header to carry 127/8. Otherwise, incorrectly popped segment stack can still result in the BFD packets to be received back by the ingress node. 

Thanks!

-Nobo

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 3 Jul 08:37 2015
Picon

I-D Action: draft-mirsky-mpls-residence-time-07.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 Working Group 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-mirsky-mpls-residence-time-07.txt
	Pages           : 23
	Date            : 2015-07-02

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-mirsky-mpls-residence-time/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-mirsky-mpls-residence-time-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-residence-time-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

BRUNGARD, DEBORAH A | 1 Jul 16:34 2015
Picon

draft-ietf-mpls-seamless-mpls

MPLS WG,
 
This draft has been sitting for quite some time. Your former AD was not happy with it and tried to work (unsuccessfully) with the authors. Myself, I sent email several weeks ago, and had no response. I’m sending it back to the WG, if there’s interest to continue with it, let your chairs know.
 
Here’s a brief summary of my main concerns:
 
  • I think my main concern is the readability and status as an architecture document. It provides lengthy descriptions of network design and numeric performance numbers which are estimates (as the document says, based on “assumed”, “assuming”, “expect”) – not appropriate for an architecture document e.g. the claim to meet the elusive sub-50ms network availability.
  • The deployment scenarios (plural in the document, but I only see #1) is a solution (including use of 2119 for protocol operation) – not appropriate for an architecture document.
  • The document says it reflects SP deployments and defines implementation choices – not typical for an architecture document.
 
My recommendation is if this is an architecture document, need to cut after section 4. And reword a bit.
 
Thanks,
Deborah
 
 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Loa Andersson | 28 Jun 11:59 2015
Picon

IPR Poll on draft-ietf-mpls-self-ping

Working Group,

We have started a working group adoption poll on draft-ietf-mpls-self-ping

We will do an IPR poll in parallel to the adoption poll.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-self-ping?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There were one IPR disclosure filed against thsi document when it still
were an individual document, it has not been re-filed against the
working group document.

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 response needs to be sent to the MPLS wg mailing list.* The
document 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.

/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

Loa Andersson | 28 Jun 11:59 2015
Picon

MPLS working group last call on draft-ietf-mpls-self-ping

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-self-ping.

Please send your comments to the mpls wg mailing list (mpls <at> ietf.org).

An IPR poll has been started in parallel to the wglc.

This working group last call ends July 13, 2015.

/Loa
for the MPLS wg chairs

--

-- 

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

Carlos Pignataro (cpignata | 28 Jun 00:26 2015
Picon

MPLS-RT review of draft-vainshtein-mpls-gal-tc-ttl-handling-01

Hi,

I’ve been selected as MPLS-RT reviewer for draft-vainshtein-mpls-gal-tc-ttl-handling-01. Please find my review below.

I believe this is a useful, coherent, and technically sound document. However, it does have issues that require attention and consideration.

Technical Issues:

3.1.  New Procedures for Handling the TC Field in an LSE That Contains
      the GAL

   Setting the value of the TC field in an LSE that contains the GAL is
   done by the LER that originates the G-ACh packet and is a matter of
   local policy for that LER.  It is RECOMMENDED that implementations
   set the TC field of an LSE that contains the GAL to all zero (0b000).

CMP: If it is a local policy, why the RECOMMENDED language? Why not state a default policy, such that lacking any other it is set to 0, but RECOMMENDED sounds too strong. In fact, it has no interop considerations, does it?

CMP: A nit, is 0b000 the same as 000b? Not sure the notation.

   The LER that inspects an LSE that contains the GAL MUST ignore the
   value of the TC field.

CMP: Similarly, this document concerns itself with maximizing interoperability. Why this strongest “MUST”? Setting ourselves up for updating this when there is a use?

3.2.  New Procedures for Handling the TTL Field in an LSE Containing GAL


Nits:

 Handling the TC and TTL fields in a Label Stack Entry when the Generic
                  Associated Channel Label is Present

CMP: When I read this, I was not sure if the GAL was present in any LSE. This is likely just me, but it would be best to disambiguate potential misreads (like mine) with "Label Stack Entry (LSE) containing the GAL” (i.e., otherwise present where?)

I hope these are useful — thanks!

— Carlos.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Andrew G. Malis | 25 Jun 13:54 2015
Picon

PALS and MPLS have swapped Thursday slots at IETF 93

PALS and MPLS WGs:

Note that on the IETF 93 agenda https://datatracker.ietf.org/meeting/93/agenda.html , MPLS will now meet at 15:20 and PALS at 17:40 on Thursday. This removes a conflict between MPLS and I2RS, and gives more meeting time to the MPLS WG. PALS now conflicts with I2RS, but this is a less serious conflict than MPLS and I2RS.

Cheers,
Andy

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

Gmane