Loa Andersson | 17 Apr 10:04 2014
Picon

IPR poll on draft-ietf-mpls-lsp-ping-relay-reply

Working Group,

The authors of  draft-ietf-mpls-lsp-ping-relay-reply has informed us
that the draft is ready for working groups last call.

Before starting the working group last call we want to run an IPR poll.

This mail starts that IPR poll.

Are you aware of any IPR that applies to 
draft-ietf-mpls-lsp-ping-relay-reply?

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

Currently there are two IPR disclosures that relates to this 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.

Thanks, Loa
(as MPLS WG co-chair)
--

-- 
(Continue reading)

Santosh Esale | 16 Apr 03:07 2014
Picon

FW: New Version Notification for draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt

We have submitted a new draft - http://www.ietf.org/id/draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt
that describes application aware targeted ldp session. We would appreciate your feedback and any
comments on it.

Thanks,
Santosh

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Wednesday, April 02, 2014 1:57 PM
To: Raveendra Torvi; Santosh Esale; Chris Bowers; Santosh Esale; Chris Bowers; Raveendra Torvi
Subject: New Version Notification for draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt

A new version of I-D, draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt
has been successfully submitted by Santosh Esale and posted to the
IETF repository.

Name:		draft-esale-mpls-appl-aware-ldp-targeted-session
Revision:	00
Title:		Applications aware LDP Targeted Session
Document date:	2014-04-02
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-esale-mpls-appl-aware-ldp-targeted-session-00.txt
Status:         https://datatracker.ietf.org/doc/draft-esale-mpls-appl-aware-ldp-targeted-session/
Htmlized:       http://tools.ietf.org/html/draft-esale-mpls-appl-aware-ldp-targeted-session-00

Abstract:
   Recent Targeted LDP applications such as Remote LFA and BGP auto
   discovery FEC 129 pseudowire may automatically establish a targeted
(Continue reading)

RFC Errata System | 15 Apr 11:31 2014

[Errata Held for Document Update] RFC6371 (3963)

The following errata report has been held for document update 
for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport
Networks". 

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

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

Reported by: Liu Lin <bestman0729 <at> gmail.com>
Date Reported: 2014-04-15
Held by: Adrian Farrel (IESG)

Section: 7.1.2

Original Text
-------------
The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LK
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.

Corrected Text
--------------
The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LKI
   removal reply OAM packet indicating whether or not it has accepted
(Continue reading)

RFC Errata System | 15 Apr 10:54 2014

[Editorial Errata Reported] RFC6371 (3963)

The following errata report has been submitted for RFC6371,
"Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks".

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

--------------------------------------
Type: Editorial
Reported by: Liu Lin <bestman0729 <at> gmail.com>

Section: 7.1.2

Original Text
-------------
The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LK
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.

Corrected Text
--------------
The peer MEP, upon receiving an LKI removal request, can either
   accept or reject the removal instruction and replies with an LKI
   removal reply OAM packet indicating whether or not it has accepted
   the instruction.

Notes
-----
LK  ---> LKI
(Continue reading)

George Swallow (swallow | 14 Apr 23:23 2014
Picon

RFC6790 and LDP independent mode

Authors -

We have uncovered what we believe to be a hole in the 6790 procedures when it comes to ELC TLV redistribution in independent mode.  Here's the text from the RFC with the most problematic part in bold.

5.1.1.  Processing the ELC TLV

 

   An LSR that receives a Label Mapping with the ELC TLV but does not

   understand it MUST propagate it intact to its neighbors and MUST NOT

   send a notification to the sender (following the meaning of the U-

   and F-bits).

 

   An LSR X may receive multiple Label Mappings for a given FEC F from

   its neighbors.  In its turn, X may advertise a Label Mapping for F to

   its neighbors.  If X understands the ELC TLV, and if any of the

   advertisements it received for FEC F does not include the ELC TLV, X

   MUST NOT include the ELC TLV in its own advertisements of F.  If all

   the advertised Mappings for F include the ELC TLV, then X MUST

   advertise its Mapping for F with the ELC TLV.  If any of X's

   neighbors resends its Mapping, sends a new Mapping or sends a Label

   Withdraw for a previously advertised Mapping for F, X MUST re-

   evaluate the status of ELC for FEC F, and, if there is a change, X

   MUST re-advertise its Mapping for F with the updated status of ELC.

 

Consider a core LSR-A that is just re-booting.  When LDP comes up it will begin advertising label mapping for all of it's IGP learned & installed  prefixes.  For any prefix the LSR-A has yet to receive a mapping with a TLV, LSR-A will not send a TLV with the initial mapping.  Suppose LSR-B is a neighbor of LSR-A.  Following the text in bold LSR-B MUST re-advertise the FEC without the TLV.  It does not matter whether LSR-B is in independent or ordered mode.  This likely will ripple through the entire network all the way to the PE advertising the FEC.  I don't see any procedure that would get the network out of this condition.  Even if that PE withdrew it's advertisement, LSR-A would still advertise the FEC.  I suppose the PE could remove the prefix from the IGP and then re-advertise it.  But you would still face a race condition where LSR-A is more than likely going to re-advertise the mapping before it gets the TLV.


We haven't come up with a clean solution, but the following change to the RFC would greatly mitigate the situation.


1. include TLV if received from ALL next-hop neighbors
2. drop TLV if not advertised by ANY next-hop neighbor

This amounts to imposing a kind of ordered mode on the ELC TLV irrespective of the LDP advertisement mode.

The fly in the ointment here is that you still have the possibility of causing your upstream neighbors to drop the TLV if LSR-A becomes a next-hop towards the FEC before LSR-A has 1) discovered the need to advertise the TLV and 2) sent the label mapping.  Depending on how the operator has the IGP-sync timer configured, this may or may not be a big problem.

George & Dave


_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
rfc-editor | 14 Apr 20:05 2014

RFC 7167 on A Framework for Point-to-Multipoint MPLS in Transport Networks

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7167

        Title:      A Framework for Point-to-Multipoint MPLS 
                    in Transport Networks 
        Author:     D. Frost, S. Bryant,
                    M. Bocci, L. Berger
        Status:     Informational
        Stream:     IETF
        Date:       April 2014
        Mailbox:    frost <at> mm.st, 
                    stbryant <at> cisco.com, 
                    matthew.bocci <at> alcatel-lucent.com,
                    lberger <at> labn.net
        Pages:      12
        Characters: 23842
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-mpls-tp-p2mp-framework-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7167.txt

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the
common set of MPLS protocol functions defined to enable the
construction and operation of packet transport networks.  The MPLS-TP
supports both point-to-point and point-to-multipoint transport paths.
This document defines the elements and functions of the MPLS-TP
architecture that are applicable specifically to supporting
point-to-multipoint transport paths.

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

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

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

Adrian Farrel | 13 Apr 20:10 2014
Picon

AD review of draft-ietf-mpls-ldp-hello-crypto-auth

Hi authors,

Thanks for progressing with this document. It is good to see security being
taken seriously by the WG.

I have done my usual AD review after receiving the publication request. This has
led me to a small number of issues and questions, below.

It would be nice to see these addressed, but I am open to discussion including
the authors and WG saying that I am wrong or that the additions are out of
scope.

Thanks for your work,
Adrian

===

I think that the threat analysis is a bit thin. As with all interior routing
protocols, there seem to be two possibilities. The first is that a bad LDP
message is admitted (directly or through a tunnel) into the network. The second
is that there is a bad actor in the network. It would help if the document was a
little clearer about which attacks it is defending against and why normal
protection at the edge of the network is not considered enough for the former,
and why a bad actor within the network would waste its time attacking LDP when
there is so much else it can do!

---

IANA stuff...

Section 2.1 should use "TBD1" and Section 2..3 and 8 should be similarly
updated to identify the new Cryptographic Authentication TLV.

The back reference in section 8 should presumably say "2.3" not "3.2".

---

Section 2.1 has

   The Cryptographic Authentication TLV Encoding is described in section
   2.2.

I think this should read 2.3.

---

Section 2.2.

   o  Security Association Identifier (SA ID)

      This is a 32-bit unsigned integer used to uniquely identify an LDP
      SA, as manually configured by the network operator.

"Unique" in what scope? Presumably "globally unique" is not needed.

I am also concerned by the requirement for manual configuration because
that is open to error and attack. Each LDP speaker will have an SA with
each of its peers and each peer must have the same SA ID for
communication to work. If you are going to go to this extent, it seems
like you don't actually need Hellos to do discovery and you will only
use them for "keepalive" in which case, it might be better to replace
that second aspect of the Hello with something like a KeepAlive message!

It is perhaps ironic that part of the reasoning you apply against access
lists is the resources they take up on each LSR, yet you are requesting
that each peer that is allowed to communicate has an SA configured which
seems to me to be more resources than a simple access list.

Is there no way to generate the AD ID value from other known information
or the LDP session?

Perhaps this concern is best addressed by writing a Management
Considerations section to describe:
- what needs to be configurable in an implementation
- what needs to be configured per SA
- what needs to be made available for inspection
- what logging takes place

---

There is a small alignment error in the figure in Section 2.3

---

Section 4 is a little odd. The implication of the wording is that this
document sets requirements on all implementations of all other protocols
that use cryptographic authentication.

I would suggest deleting the whole section and updating Section 5 as
follows...

OLD
   Ks is a Protocol Specific Authentication Key obtained by appending
   Authentication Key (K) with the two-octet LDP Cryptographic Protocol
   ID appended.
NEW
   Ks is a Protocol Specific Authentication Key obtained by appending
   Authentication Key (K) with the two-octet LDP Cryptographic Protocol
   ID TBD2 (to be defined by IANA) from the "Authentication
   Cryptographic Protocol ID" registry.  Ks is used to mitigate cross-
   protocol attacks when multiple protocols share a common key.
END

---

Section 6.2

   if the locally computed Hash is not equal to the received value of
   the Authentication Data field, the received packet MUST be discarded,
   and an error event SHOULD be logged.

It is customary to give some warning about rate limiting logging because
logging usually takes more resources than receiving packets, so if you
are subject to a storm of bad Hellos you could die trying to log them.

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

RFC Errata System | 12 Apr 16:02 2014

[Errata Held for Document Update] RFC6371 (3961)

The following errata report has been held for document update 
for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport
Networks". 

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

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

Reported by: Liu Lin <bestman0729 <at> gmail.com>
Date Reported: 2014-04-11
Held by: Adrian Farrel (IESG)

Section: 3.7

Original Text
-------------
      This packet
      will be delivered by the forwarding plane to all intermediate
      nodes at the same TTL distance of the target MIP and to any leaf
      that is located at a shorter distance.

Corrected Text
--------------
      This packet
      will be delivered by the forwarding plane to all
      nodes at the same TTL distance as the target MIP and to any leaf
      that is located at a shorter distance.

Notes
-----
The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP.

--------------------------------------
RFC6371 (draft-ietf-mpls-tp-oam-framework-11)
--------------------------------------
Title               : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Publication Date    : September 2011
Author(s)           : I. Busi, Ed., D. Allan, 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

RFC Errata System | 12 Apr 04:37 2014

[Technical Errata Reported] RFC6371 (3961)

The following errata report has been submitted for RFC6371,
"Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks".

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

--------------------------------------
Type: Technical
Reported by: Liu Lin <bestman0729 <at> gmail.com>

Section: 3.7

Original Text
-------------
This packet
      will be delivered by the forwarding plane to all intermediate
      nodes at the same TTL distance of the target MIP and to any leaf
      that is located at a shorter distance.

Corrected Text
--------------
This packet
      will be delivered by the forwarding plane to all intermediate
      nodes at the same TTL distance of the target MIP and to any leaf
      that is located at the same TTL distance of the target MIP 
      or a shorter distance.

Notes
-----
The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP.

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. 

--------------------------------------
RFC6371 (draft-ietf-mpls-tp-oam-framework-11)
--------------------------------------
Title               : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Publication Date    : September 2011
Author(s)           : I. Busi, Ed., D. Allan, 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

RFC Errata System | 11 Apr 18:07 2014

[Errata Verified] RFC6371 (3956)

The following errata report has been verified for RFC6371,
"Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks". 

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

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

Reported by: Liu Lin <bestman0729 <at> gmail.com>
Date Reported: 2014-04-10
Verified by: Adrian Farrel (IESG)

Section: 3.2

Original Text
-------------
      When an SPME is instantiated after the transport path has been
      instantiated, the TTL distance to the MIPs may change for the
      short-pipe model of TTL copying, and may change for the uniform
      model if the SPME is not co-routed with the original path.

Corrected Text
--------------
       When an SPME is instantiated after the transport path has been
       instantiated, the TTL distance to the MIPs may change for the
       short-pipe model, and may change for the uniform model if the
       SPME is not co-routed with the original path.

Notes
-----
The original report notes that there is no TTL copying in short-pipe model and states confusion arising
from the text. The suggestion was to change it to:

      When an SPME is instantiated after the transport path has been
      instantiated, the TTL distance to the MIPs may change for the
      short-pipe model of no TTL copying, and may change for the uniform
      model if the SPME is not co-routed with the original path.

The authors point out that the TTL copying mode in short-pipe is "no copying". This is true, but leaves some
potential confusion in the text.

The corrected text removes all mention of TTL copying (which is not relevant in this case).

--------------------------------------
RFC6371 (draft-ietf-mpls-tp-oam-framework-11)
--------------------------------------
Title               : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Publication Date    : September 2011
Author(s)           : I. Busi, Ed., D. Allan, 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

RFC Errata System | 11 Apr 18:03 2014

[Errata Held for Document Update] RFC6371 (3958)

The following errata report has been held for document update 
for RFC6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport
Networks". 

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

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

Reported by: Liu Lin <bestman0729 <at> gmail.com>
Date Reported: 2014-04-11
Held by: Adrian Farrel (IESG)

Section: 3.3

Original Text
-------------
Figure 3 describes four examples of per-interface Up MEPs: an Up
   Source MEP in a source node (case 1), an Up Sink MEP in a destination
   node (case 2), a Down Source MEP in a source node (case 3), and a
   Down Sink MEP in a destination node (case 4).

Corrected Text
--------------
Figure 3 describes four examples of per-interface MEPs: an Up
   Source MEP in a source node (case 1), an Up Sink MEP in a destination
   node (case 2), a Down Source MEP in a source node (case 3), and a
   Down Sink MEP in a destination node (case 4).

Notes
-----
per-interface Up MEPs ----> per-interface MEPs

The four instances listed include Up and Down MEPs, so the text should be more general.

--------------------------------------
RFC6371 (draft-ietf-mpls-tp-oam-framework-11)
--------------------------------------
Title               : Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
Publication Date    : September 2011
Author(s)           : I. Busi, Ed., D. Allan, 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


Gmane