Alexander Vainshtein | 28 Jul 18:36 2015

Re: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

Hi,

My name is Sasha Vainshtein, and  I have been asked to perform the QA review of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop/.

 

Due to health problems I have been very late (but, hopefully, not too late) with this review, and here it is.

 

Does the draft solves a real problem? From my POV, definitely yes.

          1.         The problem stems from the following combination of facts fact that:

a.       LDP distributes labels for FECs represented by IP prefixes (among other things).

b.      LDP-based MPLS network are very widely deployed

c.       SR operating over the MPLS DP allocates labels for SIDs that can represent IP prefixes (again, among other things)

d.      As a consequence, LDP and SR may effectively map the same IP prefix to different labels.

          2.         As SR using the MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:

a.       Coexistence  between LDP-based and SR-based control planes in the same network

b.      Partial deployment of SR in some sub-domains of a network combined with the operators’ need to use the benefits of SR where it is already deployed

c.       Gradual transition of services  (especially L2 and L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)

 

Is the draft a good enough start for a WG document? From my POV, yes.

1         The draft covers multiple (if not all) realistic use cases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scenarios.

2         At the same I would think that additional work is required to complete the work.

 

Specific issues with the current draft:

1         Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion at the first use, and there is no “Abbreviation” section in the draft.

2         Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recommended RFC Editor maximum of 5 authors.

          3.         Technical: The draft does not analyse the use case  of coexistence between SR and LDP with enabled extension for multi-area LSPs as per RFC 5283. I think that this use case deserves special consideration in the draft because:

a.       It mentions the use case of seamless MPLS and refers to the (expired) Seamless MPLS Architecture draft

b.       The seamless MPLS Architecture draft, in its turn, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default route is configured in the RIB of the access node in the seamless MPLS architecture

c.       It is possible that this use case would not add anything to the draft – but I would prefer to see it in the document with the appropriate explanation

          4.         Technical: Section 8 “Manageability Considerations” is currently left empty. When this section is written, I would expect at least the following:

a.       Some level of detail regarding local  policies defining whether LDP-created or SR-created LSPs should be used etc.

b.      Discussion of using LSP Ping for LSPs that are produced by stitching an LDP segment with an SR one.

c.       Alternatively, it is possible to move this section to a separate dedicated draft

          5.         Technical: I think more information should be provided in Section 5 to explain operational aspects of SR-assisted LDP FR:

a.       In Section 5.1 I would expect the draft to explain that:

                                                               i.      Node D is selected as the RLFA using the same logic  that is defined for selecting RLFA in RFC 7490

                                                             ii.      The “bypass LSP” is set up by the SR CP automatically without any need for management intervention

                                                            iii.      I would like to understand why dynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BGP-based auto-discovery for L2VPN is used, and, according to the analysis in RFC 7490, the scalability problems associated with these sessions look as negligible.

b.      In Section 5.2 I would expect the draft to explain that:

                                                               i.      The resulting solution is similar to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP session to such an RLFA would be still needed)

                                                             ii.      Set up of the  “traffic-engineered bypass LSP” by the SR CP is triggered by an appropriate management operation

                                                            iii.      What information should be provided by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? Should it be similar to configuration parameters used with RSVP-TE?

                                                           iv.      Which kind of logic should be responsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it be similar to the CSPF used with RSVP-TE?

                                                             v.      How the traffic-engineered bypass LSP hat is set up by the SR CP would react to additional changes in the network topology (the behaviour of the bypass LSP that is set by RSVP-TE in these situations is well known).

 

Neither of the issues listed above should be considered as preventing adoption of the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.

 

Hopefully these notes will be useful.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein <at> ecitele.com

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick <at> metaswitch.com]
Sent: Wednesday, May 20, 2015 12:46 PM
To: Alexander Vainshtein
Cc: bruno.decraene <at> orange.com; jgs <at> juniper.net; Alvaro Retana (aretana); Jon Hudson
Subject: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

 

Hi Sasha

 

Please would you be the routing directorate QA reviewer for draft-filsfils-spring-segment-routing-ldp-interop?

https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop/

 

This initial review has been prompted by the spring WG chairs in parallel with a call for WG adoption.  As such, this document qualifies for “initial QA review”.  Please could you provide your initial comments in the next 3 weeks?  As per the QA process, we would also like you to stay with the document and review it again when it goes to WG last call.

 

The following web page contains a briefing on the QA process, and guidance for the QA reviewer.

https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 

Please copy your comments to the spring and rtgdir mailing lists.

 

Please let me know whether you can do it, or not.

 

Many thanks

Jon

 

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
류정동 | 27 Jul 09:33 2015
Picon
Picon

A new draft for the (re-)initialization of PSC in APS mode

Hi All,

 

A new version of ID, draft-ryoo-mpls-tp-aps-updates-00.txt is available at

https://www.ietf.org/internet-drafts/draft-ryoo-mpls-tp-aps-updates-00.txt.

 

This draft is to update RFC 7271 (MPLS-TP linear protection in APS mode), and the updates are related to the (re-)initialization of the PSC Control Logic, in which the state machine resides. when operating in APS mode.

 

Since the publication of RFC 7271 in June 2014, there have been some questions on what the correct and desirable behavior is when the node or the linear protection switching process should be rebooted or re-initialized due to the power outage or the operator’s act of re-booting, etc. Although it is a common perception that the state machine starts at the Normal state (but, not explicitly specified in any of MPLS-TP linear protection solution documents, RFC 7271 and RFC 6378), various questions have been raised concerning the detailed actions that the PSC Control Logic should take.

 

The authors of this new draft has been analyzing various initialization scenarios, such as warm and cold reboots while the related OAM functions are in operation or not, and came up with a set of the initialization rules that can cover all the possible cases related to (re-)initialization while traffic disruptions are minimized.

 

Your questions, comments and feedbacks are welcome.

 

Best regards,

 

Jeong-dong and Authors

 
 
 



_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Loa Andersson | 25 Jul 10:05 2015
Picon

question to the authors of draft-fang-mpls-label-forwarding-no-swap

Authors,

In the discussion on the mailing list it has been alleged that the
no-swap operation proposed in the draft will not decrement the TTL
and not look at the TC field, is that the intent of the authors?

/Loa
--

-- 

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

Gregory Mirsky | 24 Jul 10:32 2015
Picon

Request for WG adoption call of draft-mirsky-mpls-residence-time

Dear WG Chairs,

this draft proposes solution that improves accuracy of PTP clock synchronization across MPLS network. The document been reviewed by MPLS-RT and key comments been addressed in the latest published version.

Authors would like to ask you to consider initiate WG Adoption Call of the draft-mirsky-mpls-residence-time.

 

                Regards,

                                Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Gregory Mirsky | 24 Jul 10:24 2015
Picon

Requesting WG LC for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

Dear WG Chairs,

the draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf defines data model of MPLS-TP OAM configuration expressed through LSP Ping sub-TLVs. The document has been updated to include comments received in course of publication process of the draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext (RFC 7487).

Authors would like to ask WG Chairs to consider initiating WG LC for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf.

 

                Regards,

                                Greg

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 24 Jul 09:28 2015
Picon

I-D Action: draft-ietf-mpls-lsp-ping-lag-multipath-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           : Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces
        Authors         : Nobo Akiya
                          George Swallow
                          Stephane Litkowski
                          Bruno Decraene
                          John E. Drake
	Filename        : draft-ietf-mpls-lsp-ping-lag-multipath-01.txt
	Pages           : 28
	Date            : 2015-07-23

Abstract:
   This document defines an extension to the MPLS Label Switched Path
   (LSP) Ping and Traceroute as specified in RFC 4379.  The extension
   allows the MPLS LSP Ping and Traceroute to discover and exercise
   specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link
   Aggregation Group (LAG) interfaces.

   This document updates RFC4379 and RFC6424.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-lag-multipath-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-lag-multipath-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

internet-drafts | 24 Jul 07:55 2015
Picon

I-D Action: draft-ietf-mpls-opportunistic-encrypt-00.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           : Opportunistic Security in MPLS Networks
        Authors         : Adrian Farrel
                          Stephen Farrell
	Filename        : draft-ietf-mpls-opportunistic-encrypt-00.txt
	Pages           : 34
	Date            : 2015-07-23

Abstract:
   This document describes a way to apply opportunistic security
   between adjacent nodes on an MPLS Label Switched Path (LSP) or
   between end points of an LSP.  It explains how keys may be agreed
   to enable encryption, and how key identifiers are exchanged in
   encrypted MPLS packets.  Finally, this document describes the
   applicability of this approach to opportunistic security in MPLS
   networks with an indication of the level of improved security as
   well as the continued vulnerabilities.

   This document does not describe security for MPLS control plane
   protocols.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-opportunistic-encrypt-00

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

John G. Scudder | 23 Jul 16:21 2015
Picon

disposition of draft-decraene-idr-next-hop-capability

TL;DR: BGP infrastructure should be standardized in IDR, not in MPLS.

Long form:

Since Loa asked for this on the list...

I generally agree that, assuming draft-decraene-idr-next-hop-capability is progressed [*] it should
be done in IDR. As someone else said at the mic in the MPLS meeting just now, the reason is that the draft
defines a generic container, one application of which is Entropy Label, but whose future uses are by no
means limited to MPLS applications. The options would seem to be:

1. Progress in IDR, with input from and joint last call with MPLS owing to the EL part,
2. Progress in MPLS, with input from and joint last call with IDR owing to the generic container part,
3. Split into a base document defining the container, to be progressed in IDR, and an application document
that specs EL using the container, to be progressed in MPLS.

Of these, I prefer 1 or 3. I prefer 1 over 2 because (as the speaker at the mic said) the IDR questions and
applicability seem broader than the MPLS ones, in this case. 3 is probably a more formally proper
decomposition, but requires something like 2x the administrative overhead. I am OK with that if either or
both WGs prefer it that way, and if the authors are willing to split it into two documents and progress both. 

HTH,

--John

[*] (which speaking with no WG chair hats on I think it should be) 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls

Loa Andersson | 23 Jul 13:51 2015
Picon

Coordination of YANG models


Authors of MPLS wg YANG models,

At the MPLS wg meeting yesterday we had a discussion on overlap between
different YANG models. It was alleged that there is a huge overlap
between the YANG models and that there is a substantial need for
coordination.

There were opinions in the meeting spanning from "This will sort it out
itself in the end!" to "Some person with the authority need to do the
coordination!" I guess that the majority were somewhere in the middle
ground.

Here is (at least a temporary) direction for the MPLS wg:

    "The authors of the YANG models progressed in the MPLS working
     group will have to coordinate with other YANG model author
     groups (within and outside the MPLS wg) to find and address
     overlap."

MPLS wg chairs will help when necessary, but initiative should come
from the author groups.

I think there might be a companion question; "Are there YANG models
that we need to do, but that we have not yet identified?"

/Loa

PS
There is a problem with using the document alias, so I tried to
extract the mail-addresses for everyone list as an author for
one of the documents. If I missed someone please forward this
message.

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

internet-drafts | 22 Jul 15:43 2015
Picon

I-D Action: draft-ietf-mpls-tp-temporal-hitless-psm-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           : Enhanced path segment monitoring
        Authors         : Alessandro D'Alessandro
                          Loa Andersson
                          Manuel Paul
                          Satoshi Ueno
                          Kaoru Arai
                          Yoshinori Koike
	Filename        : draft-ietf-mpls-tp-temporal-hitless-psm-07.txt
	Pages           : 16
	Date            : 2015-07-22

Abstract:
   The MPLS transport profile (MPLS-TP) has been standardized to enable
   carrier-grade packet transport and complement converged packet
   network deployments.  Among the most attractive features of MPLS-TP
   there are OAM functions, which enable network operators or service
   providers to provide various maintenance characteristics, such as
   fault location, survivability, performance monitoring and in-service/
   out of service measurements.

   One of the most important mechanisms which is common for transport
   network operation is fault location.  A segment monitoring function
   of a transport path is effective in terms of extension of the
   maintenance work and indispensable particularly when the OAM function
   is effective only between end points.  However, the current approach
   defined for MPLS-TP for the segment monitoring (SPME) has some
   drawbacks.  This document elaborates on the problem statement for the
   Sub-path Maintenance Elements (SPMEs) which provides monitoring of a
   portion of a set of transport paths (LSPs or MS-PWs).  Based on the
   problems, this document specifies new requirements to consider a new
   improved mechanism of hitless transport path segment monitoring named
   Enhanced Path Segment Monitoring (EPSM).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-temporal-hitless-psm/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-tp-temporal-hitless-psm-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-temporal-hitless-psm-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

John G.Scudder | 22 Jul 15:17 2015
Picon

working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop

Dear WG,

As we discussed at our meeting yesterday, working group adoption has been requested for
draft-filsfils-spring-segment-routing-ldp-interop. Please reply to the list with your comments,
including although not limited to whether or not you support adoption. Non-authors are especially
encouraged to comment.

In consideration of the fact that a number of WG calls are going on concurrently, we will end the call on
August 31, 2015. 

Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed.
Also, the length of the author list for this document greatly exceeds the maximum recommended. Assuming
the document is adopted, the authors should be prepared to correct this when submitting as a WG document,
ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section
for the full list.

Thanks,

--Bruno and John

P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls


Gmane