RFC Errata System | 6 May 02:43 2016

[Technical Errata Reported] RFC5443 (4686)

The following errata report has been submitted for RFC5443,
"LDP IGP Synchronization".

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

--------------------------------------
Type: Technical
Reported by: Alexander Okonnikov <alexander.okonnikov <at> gmail.com>

Section: 3

Original Text
-------------

Corrected Text
--------------
(At the end of the section)

In case of OSPF while router advertises maximum cost, virtual link(s)
that cross link under question, could be broken. This is because
virtual link, which underlying path has cost greater than 0xFFFF,
considered as inoperational. As a result, virtually connected area(s)
could be isolated from backbone.

Notes
-----
In case there are two or more links on path taken by virtual link, and one of them has max link cost, path metric
will exceed value 0xffff. As a result virtual link will become inoperational.
(Continue reading)

bruno.decraene | 4 May 15:45 2016

Re: working group last call on draft-ietf-mpls-spring-entropy-label

Hi Stéphane,

 

Thanks for the quote. I had read that sentence, and I think it could be made more precise.

e.g.

OLD: This limitation expressed in terms of the number of label stack entries that the LSR  can read is henceforth referred to as the Readable Label Depth (RLD)  capability of that LSR.

NEW: This limitation expressed in terms of the number of label stack entries that the LSR  can read. This document defines the Readable Label Depth (RLD) as the number of labels that a transit LSR can read for load-balancing purpose.  When EL is used, both ELI and EL MUST be within the RLD, in order for the EL to be used during load-balancing.

 

Additionally, you did not answer my second related question:

> is RLD only applicable when EL is used or is it also applicable when load-balancing is performed based on the hashing of a stack of labels (a stack of RLD labels)?

 

A related point is whether a transit LSR not supporting EL, MAY/SHOULD/MUST NOT advertise the RLD.  (because transit LSR don’t need to support EL to benefit from the improved load-balancing  provided by EL)

 

The question could further be refined when MPLS carry an IP packet and the LSR perform load-balancing based on some hashing of this inner IP packet.

 

Thanks,

--Bruno

 

From: LITKOWSKI Stephane OBS/OINIS
Sent: Wednesday, May 04, 2016 3:20 PM
To: DECRAENE Bruno IMT/OLN; draft-ietf-mpls-spring-entropy-label <at> tools.ietf.org; mpls <at> ietf.org
Cc: mpls-chairs <at> ietf.org; Loa Andersson
Subject: RE: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

 

Hi,

 

I think RLD is clearly expressed in :

"An LSR may have a limitation in its ability to read and process the

   label stack in order to do multipath load balancing.  This limitation

   expressed in terms of the number of label stack entries that the LSR

   can read is henceforth referred to as the Readable Label Depth (RLD)

   capability of that LSR.  If an EL does not occur within the RLD of an

   LSR in the label stack of the MPLS packet that it receives, then it

   would lead to poor load balancing at that LSR."

 

It refers to the number of label that the LSR can read. So as a consequence, if you want to be able to read the EL, ELI+EL must be within the RLD. Otherwise the also described behavior will apply (poor loadbalancing).

 

Is it fine ?

 

Thanks

 

 

-----Original Message-----
From: bruno.decraene <at> orange.com [mailto:bruno.decraene <at> orange.com]
Sent: Wednesday, May 04, 2016 14:45
To: draft-ietf-mpls-spring-entropy-label <at> tools.ietf.org; mpls <at> ietf.org
Cc: mpls-chairs <at> ietf.org; Loa Andersson
Subject: RE: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

 

Hi authors,

 

As an additional comment, I'd like a see a more normative definition of "RLD" as this is an important point for the interop.

In particular, the grey zone is whether RLD is before the ELI, or include the EL, or include both the EL and ELI. Also, is RLD only applicable when EL is used or is it also applicable when load-balancing is performed based on the hashing of a stack of labels (a stack of RLD labels)?

 

>From the description of the text, I think I read that both EL and ELI needs to be within the RLD. But on the other hand, there has been a discussion on the mailing list about RLD=1, which would not even allow reading the ELI label.

 

Thanks,

Regards,

Bruno

 

> From: DECRAENE Bruno IMT/OLN > Sent: Monday, May 02, 2016 2:59 PM

>

> Hi authors,

>

> Please find below some comments on the document (§4).

>

> - I would expect that network operator may need some flexibility to

> influence the placement of the EL(s) based on the set of constraints.

> - The need for load-balancing seems significantly dependent on the 1)

> relative size of the flow (which is typically egress dependent) and 2)

> the presence of ECMP paths (IOW, I may not care if node N does not see

> the EL, if node N has a single link/path toward the egress). This may

> lead to additional requirements (e.g. advertising L2 ECMP which may

> not be currently visible to the L3 ingress. For spring, eventually

> draft-ietf-isis- l2bundles may already do the job)

>

> Both points are not touched in the draft, and I think these additions

> would improve the benefit of the draft.

>

> Thanks,

> Regards,

> -- Bruno

>

> > Working Group,

> >

> > This is to initiate a two week working group last call on

> > draft-ietf-mpls-

> spring-

> > entropy-label.

> >

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

> >

> > There are no IPR disclosures against this document.

> >

> > All the authors and contributors (with one exception) have stated on

> > the working group mailing list that they are not aware of any other

> > IPRs that relates to this draft.

> >

> > This working group last call ends May 12, 2016.

> >

> >

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

 

_________________________________________________________________________________________________________________________

 

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

 

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

 

_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Rob Shakir | 4 May 02:11 2016

Re: working group last call on draft-ietf-mpls-spring-entropy-label

[readding mpls <at> ]

> On May 3, 2016, at 14:22, Carlos Pignataro (cpignata) <cpignata <at> cisco.com> wrote:
> 
> There’s another unanswered piece for me, which is: All those routers are advertising ELC and RLDs. As
long as R5 and R10 are ELC, then you can add EL/ELIs there.
> BUT, what is the RLD of the *loose* path R1..R5 and of the *loose* path R6..R10? 

RLD is unfortunately something that we have to deal with. There is nothing really in the MPLS specs that
tells us that an assumption that one can optimise hardware to have a shallow RLD is OK AIUI, but still we have
many systems that have a depth to which they can read.

To this end, the way that we have implemented things is to assume that RLD = min(network). This actually has
implications for service implementations, since your customer L2VPN MTU will be impacted by the number
of <ELI, EL> pairs you need to allow room for within the core. Since a customer service must work over all
paths that reroute might happen over; most transport LSPs will have at least a loose backup path option;
and the fact that old hardware is long-lived - then min(network) seems to be the manageable and most robust
option to take. 

So, your question, to me - please correct me if you don't feel it is accurate - comes down to whether the entity
processing some label can find some entropy within its readable depth. At the point that we have
considered min(network) for the RLD then it does not matter whether the next label is a adjacency or node
segment we know that within our RLD then there is a <ELI, EL> pair. 

Note that the problem case I see here occurs when the RLD for the network becomes sufficiently low. If it is
set to 1 then we need to be able to push more labels at the head end. In the worst case, the iLER can push fewer
labels than the least capable LSR can read. At this point, we are stuck - there is nothing that can be done to
satisfy all requirements. The approach that the coauthors of this draft discussed tries to do the best it
can to make entropy available to all systems,  since we know that not having entropy really hurts for
load-sharing - but it also does not mandate that a system does not send a packet that one system in the
network cannot hash properly. 

This comes back to the problem you presented around whether all systems must be upgraded or not, the answer
is no, rather like the existing EL behaviours. We essentially need to make an assumption about RLDs of the
nodes that do not advertise RLD. The first option is assume that RLD = 1, however, this means potentially
over-inserting ELs (the worst case would be that we do not know whether they, as midpoints, even know about
the EL - and insert them even though they cannot hash on them). The alternative is to assume they know how to
hash themselves (or simply are expected not to hash) when EL is not present, since this has been true for
systems historically. This results in some cases where we do not have entropy but would desire it.
Operators need to make choices themselves as to what to do here - which may include limiting the label stack
depth imposed by their policies on a head end, or doing LSP stitching or segment-expansion somewhere else
in the network. 

There are many procedures here which come down to combining the various standardised and
non-standardised procedures that may be available to an operator to balance their requirements for
entropy against their requirements for path strictness, and the number of approaches deployed in their
network. 

Please let me know if there are things here that not clear, I am happy to expand on them. 

r. 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Robert Wilton | 3 May 16:34 2016
Picon

Re: [netmod] Use of schema mounts for common model

Hi Tarek,

I'm also wondering whether using schema mount in this way might be a bit like using a sledgehammer to crack a nut.

With interfaces, there is a per device global list of interfaces where each list entry can have a different type and different properties.  Currently these are using the iana:iftype to differentiate their different schema modes, but there is an idea to use more abstract identities.

I'm not really familiar with the tunnel YANG models, but I was wondering whether the same approach has been considered for the TE tunnel YANG models at all?

I.e. rather than having a separate protocol instantiation for each different data plane technology, instead have a per device global list of tunnels that hold the configuration and operational state, making use of when statements and identities (if required) to manage dataplane specific leaves.  Each protocol specific data plane module could also maintain a protocol specific list containing leaf-refs back to the appropriate tunnels in the master list.

Thanks,
Rob


On 29/04/2016 17:17, Tarek Saad (tsaad) wrote:
Thanks Martin, please see inline..


On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj <at> tail-f.com> wrote:

"Tarek Saad (tsaad)" <tsaad <at> cisco.com> wrote:
Hi authors/WG,
In draft-ietf-teas-yang-te, we are driving the definition for a
generic TE YANG model that can/may be used (and extended when
necessary) for different data plane technologies (e.g. MPLS, OTN, WDM,
etc.).
Reviewing the schema mount idea presented in
draft-ietf-netmod-schema-mount, we are thinking this proposal is
useful and can facilitate the reuse of the our model in multiple
places in the YANG tree (once per each technology), e.g.:
…/mpls/mount-points/mount-point/module=ietf-te.yang
…/otn/mount-points/mount-point/module=ietf-te.yang

Schema mount is probably not the right solution to your problem.  I
think a better solution in your case is to define groupings.
Groupings are designed to be re-used at different places in the
hierarchy.

We thought of this earlier, and found groupings pose their own set of challenges too.. Specifically:
- a groupings with leafrefs could not reference data nodes that reside in another grouping
- a grouping with leafrefs of relative path were challenge when the relative path references data nodes outside the grouping
- the augmentation of the grouping by other modules is not as straightforward

That said, the grouping proposal seems to 

one could also think that with groupings one could address reuse of the a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In fact, in your draft (section 2) you explicitly discourage this approach as not scalable solution


   With the "uses" approach, ietf-interfaces would have to define a
   grouping with all its nodes, and the new model for logical devices
   would have to use this grouping.  This is a not a scalable solution,
   since every time there is a new model defined, we would have to
   update our model for logical devices to use a grouping from the new
   model.  Another problem is that this approach cannot handle vendor-



We have a comment/concern/suggestion and we value your feedback.
The generic TE model currently references data nodes in the global
tree (e.g. from the ietf-interfaces model to define additional TE
properties associated with a specific device interface). Our
understanding after reading section 3.1 of your draft is the mounted
model can *not* reference any data nodes outside the scope of the
mount-point (e.g. global data nodes in the yang tree). This poses a
limitation for us, do you have a suggestion for this problem?
One possible solution we thought of was to replace the leaf-refs
pointing to the global data nodes (e.g. Ietf-interfaces) with context
names (e.g. the interface name).. This decouples the data-nodes
defined in the TE generic model from those in the global tree
(e.g. the actual interface ietf-interfaces model). Any feedback on
this or better suggestions?

If you use groupings instead, you can still use proper leafrefs.

Not in all cases — as described above.

Regards,
Tarek



/martin



Regards,
Tarek
Excerpt from draft-ietf-netmod-schema-mount
Augment and Validation in Mounted Data
    All paths (in leafrefs, instance-identifiers, XPath expressions, and
    target nodes of augments) in the data models mounted at a mount point
    are interpreted with the mount point as the root node, and the
    mounted data nodes as its children.  This means that data within a
    mounted subtree can never refer to data outside of this subtree.



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

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
internet-drafts | 30 Apr 16:55 2016
Picon

I-D Action: draft-ietf-mpls-rfc4379bis-04.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           : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
        Authors         : Kireeti Kompella
                          Carlos Pignataro
                          Nagendra Kumar
                          Sam Aldrin
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-mpls-rfc4379bis-04.txt
	Pages           : 55
	Date            : 2016-04-30

Abstract:
   This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in Multi-Protocol Label Switching
   (MPLS) Label Switched Paths (LSPs).  There are two parts to this
   document: information carried in an MPLS "echo request" and "echo
   reply" for the purposes of fault detection and isolation, and
   mechanisms for reliably sending the echo reply.

   This document obsoletes RFCs 4379 and 6829.

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

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

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

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

Shahram Davari | 29 Apr 19:34 2016

Re: IPR poll on draft-ietf-mpls-residence-time

Unfortunately the Patent Number doesn't seem to be valid. Can you provide
the correct Us patent number or a link to it?

Thx
Shahram

-----Original Message-----
From: mpls [mailto:mpls-bounces <at> ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, April 28, 2016 10:28 PM
To: Loa Andersson; mpls-chairs <at> ietf.org; mpls <at> ietf.org;
draft-ietf-mpls-residence-time <at> tools.ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time

Hi Loa, et. al,
I know of the IPR disclosure https://datatracker.ietf.org/ipr/2626/ that
is related to the draft-mirsky-mpls-residence-time  and was submitted on
July 10, 2015.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:loa <at> pi.nu]
Sent: Thursday, April 28, 2016 7:23 PM
To: mpls-chairs <at> ietf.org; mpls <at> ietf.org;
draft-ietf-mpls-residence-time <at> tools.ietf.org
Subject: IPR poll on draft-ietf-mpls-residence-time

Working Group,

The authors of draft-ietf-mpls-residence-time has told us that the
document is ready to be considered for working group last call.

We will do an IPR poll prior to the start of the wg last call.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?

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

There is one IPR disclosure filed against the document that was replaced
by the current draft.

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

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

Joel M. Halpern | 29 Apr 19:04 2016

Re: [netmod] Use of schema mounts for common model

With regard to leafrefs trying to point into groupings, would 
instance-identifiers work for your use case?

Yours,
Joel

On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:
> Thanks Martin, please see inline..
>
>
> On 2016-04-29, 6:29 AM, "Martin Bjorklund" <mbj <at> tail-f.com
> <mailto:mbj <at> tail-f.com>> wrote:
>
>     "Tarek Saad (tsaad)" <tsaad <at> cisco.com <mailto:tsaad <at> cisco.com>> wrote:
>
>         Hi authors/WG,
>         In draft-ietf-teas-yang-te, we are driving the definition for a
>         generic TE YANG model that can/may be used (and extended when
>         necessary) for different data plane technologies (e.g. MPLS,
>         OTN, WDM,
>         etc.).
>         Reviewing the schema mount idea presented in
>         draft-ietf-netmod-schema-mount, we are thinking this proposal is
>         useful and can facilitate the reuse of the our model in multiple
>         places in the YANG tree (once per each technology), e.g.:
>         …/mpls/mount-points/mount-point/module=ietf-te.yang
>         …/otn/mount-points/mount-point/module=ietf-te.yang
>
>
>     Schema mount is probably not the right solution to your problem.  I
>     think a better solution in your case is to define groupings.
>     Groupings are designed to be re-used at different places in the
>     hierarchy.
>
>
> We thought of this earlier, and found groupings pose their own set of
> challenges too.. Specifically:
> - a groupings with leafrefs could not reference data nodes that reside
> in another grouping
> - a grouping with leafrefs of relative path were challenge when the
> relative path references data nodes outside the grouping
> - the augmentation of the grouping by other modules is not as
> straightforward
>
> That said, the grouping proposal seems to
>
> one could also think that with groupings one could address reuse of the
> a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In
> fact, in your draft (section 2) you explicitly discourage this approach
> as not scalable solution
>
>
>    With the "uses" approach, ietf-interfaces would have to define a
>    grouping with all its nodes, and the new model for logical devices
>    would have to use this grouping.  This is a not a scalable solution,
>    since every time there is a new model defined, we would have to
>    update our model for logical devices to use a grouping from the new
>    model.  Another problem is that this approach cannot handle vendor-
>
>
>
>         We have a comment/concern/suggestion and we value your feedback.
>         The generic TE model currently references data nodes in the global
>         tree (e.g. from the ietf-interfaces model to define additional TE
>         properties associated with a specific device interface). Our
>         understanding after reading section 3.1 of your draft is the mounted
>         model can *not* reference any data nodes outside the scope of the
>         mount-point (e.g. global data nodes in the yang tree). This poses a
>         limitation for us, do you have a suggestion for this problem?
>         One possible solution we thought of was to replace the leaf-refs
>         pointing to the global data nodes (e.g. Ietf-interfaces) with
>         context
>         names (e.g. the interface name).. This decouples the data-nodes
>         defined in the TE generic model from those in the global tree
>         (e.g. the actual interface ietf-interfaces model). Any feedback on
>         this or better suggestions?
>
>
>     If you use groupings instead, you can still use proper leafrefs.
>
>
> Not in all cases — as described above.
>
> Regards,
> Tarek
>
>
>
>     /martin
>
>
>
>         Regards,
>         Tarek
>         Excerpt from draft-ietf-netmod-schema-mount
>         3.1<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-01#section-3.1>.
>         Augment and Validation in Mounted Data
>             All paths (in leafrefs, instance-identifiers, XPath
>         expressions, and
>             target nodes of augments) in the data models mounted at a
>         mount point
>             are interpreted with the mount point as the root node, and the
>             mounted data nodes as its children.  This means that data
>         within a
>             mounted subtree can never refer to data outside of this subtree.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod <at> ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

Loa Andersson | 27 Apr 15:19 2016
Picon

Proposed response to ITU-T SG15 on "LS on work on MPLS-TP protection"

Working groups,

We had a liaison from ITU-T SG15 on "LS on work on MPLS-TP protection",
please find the proposed response below. Please send comments to the
mpls wg mailing list (mpls <at> ietf.org) on May 3rd the latest.

--------------------  proposed response ---------------------------

The MPLS and PALS Working Groups are pleased to hear about the continued 
progress on the MPLS Transport Profile and continued alignment with IETF 
RFCs.

We confirm that "MPLS-TP Shared-Ring protection (MSRP) mechanism for 
ring topology” 
(https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection) 
is progressing in the MPLS WG, and invite comments on this draft to the 
MPLS WG mailing list (mpls <at> ietf.org). In addition, we are also 
progressing a draft on "Resilient MPLS Rings" 
(https://datatracker.ietf.org/doc/draft-ietf-mpls-rmr).

The PALS WG currently has two drafts in progress that are relevant to 
MPLS-TP pseudowire linear protection:

https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-coordination
https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-protection

These drafts provide a fast protection mechanism for MPLS-TP PWs to 
protect dual-homed CEs against failures of their attachment circuits or 
PE routers. The drafts are ongoing work and were very recently updated. 
We hope to complete work on these drafts by the upcoming IETF meeting in 
Berlin on July 17-22, 2016, and would very much appreciate SG15’s review 
and comments to the pals <at> ietf.org email list.

We are also pleased to hear about the second amendment to Recommendation 
ITU-T G.8131/Y.1382, "Linear protection switching for MPLS transport 
profile."

In addition to maintaining communication with liaisons, please engage on 
the MPLS WG mailing list (mpls <at> ietf.org) and PALS WG mailing list 
(pals <at> ietf.org) which provide a more timely view of the state of the work.

MPLS and PALS wg co-chairs

------------------------- end of proposed response ------------------

/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 | 23 Apr 09:53 2016
Picon

working group last call on draft-ietf-mpls-spring-entropy-label

Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

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

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.

/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

Loa Andersson | 22 Apr 15:02 2016
Picon

working group adption poll on draft-kumarkini-mpls-spring-lsp-ping

Working Group,

This is to start a two week poll to see if we have consensus to
adopt draft-kumarkini-mpls-spring-lsp-ping 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.

There are no IPR disclosures against this document.

All the authors has stated that they are not aware of any IPRs that
relate to this document. In all but one case this has been done on the
on the mpls wg mailing list, in the last case this has been stated in a
mail to the wg chairs.

The working group adoption poll ends May 7, 2016.

/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

The IESG | 21 Apr 00:35 2016
Picon

Protocol Action: 'RFC6374 UDP Return Path' to Proposed Standard (draft-ietf-mpls-rfc6374-udp-return-path-05.txt)

The IESG has approved the following document:
- 'RFC6374 UDP Return Path'
  (draft-ietf-mpls-rfc6374-udp-return-path-05.txt) as Proposed Standard

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

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/

Technical Summary

The MPLS Packet Loss and Delay Measurement protocol is defined in RFC6374.
RFC 6374 defines how to send and process MPLS performance management 
responses for Loss and Delay measurement.

This document specifies the procedure to be used when an out of band
UDP/IP return path is available.

Working Group Summary

 There were nothing exceptional in the working group process other than
 the WG Chairs had to ask twice during the wglc to get any response at
 all. I guess that this is one of those document that is of very strong interest
 for a small group within the working group, while the rest of the working
 understands that it need to be done, being happy that someone takes on the 
 work.

Document Quality

We currently are aware of prototyping, as well as plans to any implement
 this specification, we have an ongoing implementation poll and the write-up
 will be updated if and when we get further news.
 There should be implementations since we made early allocations based
  on upcoming testing.

 No special purpose reviews has been necessary.

The document is well reviewed in mpls-rt and at working adoption
poll, even though the wglc gave nothing but supportive comments.

Personnel

Loa Andersson is the Document Shepherd.
Deborah Brungard is the Responsible Area Director

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


Gmane