Subject: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 27 Sep 2014 11:02:41 -0400

PWE3ers,

Revision -00 of this draft was presented at the Toronto IETF and we
received good feedback from the WG. We've updated the draft to incorporate
the received comments. The draft plugs an important hole in resilience for
static MS-PWs. Please review and comment to the list, it's a very quick
read.

Thanks,
Andy

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Sep 26, 2014 at 6:05 PM
Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : S-PE Outage Protection for Static Multi-Segment
Pseudowires
        Authors         : Andrew G. Malis
                          Loa Andersson
                          Huub van Helvoort
                          Jongyoon Shin
                          Lei Wang
                          Alessandro D'Alessandro
        Filename        : draft-shawam-pwe3-ms-pw-protection-01.txt
        Pages           : 5
        Date            : 2014-09-26

Abstract:
   In MPLS and MPLS-TP environments, statically provisioned Single-
   Segment Pseudowires (SS-PWs) are protected against tunnel failure via
   MPLS-level and MPLS-TP-level tunnel protection.  With statically
   provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the
   MS-PW is likewise protected from tunnel failures via MPLS-level and
   MPLS-TP-level tunnel protection.  However, static MS-PWs are not
   protected end-to-end against failure of one of the switching PEs
   (S-PEs) along the path of the MS-PW.  This document describes how to
   achieve this protection by updating the existing procedures in RFC
   6870.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shawam-pwe3-ms-pw-protection/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-shawam-pwe3-ms-pw-protection-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-shawam-pwe3-ms-pw-protection-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/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 28 Sep 2014 05:03:21 +0000

Andy,

I've read the draft and re-read RFC 6780, and I have a couple of questions/comments that, from my point of view, should be clarified in the next revision of the draft.

  1.  RFC 6780 and RFC 6718 describe multiple use cases for PW redundancy, including use cases with dual-homed CEs, use cases for VPLS etc. The draft refers to specific sections in these RFCs that deal with the use case of two single-homed CEs, so I guess that this is the intended scope of the draft. Is this assumption correct? If yes, I would suggest stating this explicitly and even including the corresponding reference network model diagram in the draft. This would not unduly expand the document while making it much more readable IMO.  (And maybe you should mention draft-cheng-pwe3-mpls-tp-dual-homing-protection a dealing with the dual-homing use cases?)
  2.  RFC 6870 does not explain how S-PE failure is detected. I assume that one of the possible ways to do that could be by treating failure of the targeted/indirect LDP session between this S-PE and its adjacent PEs as S-PE failure. This is clearly not relevant in the case of statically set up MS-PWs. I would suggest adding a few words regarding possible methods for detecting S-PE failure. (As an absolute minimum, you could state that this is out of scope of the document...)
  3.  To the best of my recollection somebody has once posted a draft that suggested treating static MS-PWs as MPLS-TP co-routed bi-directional LSPs (which is true)and applying LSP Linear Protection for end-to-end protection of MS-PWs. This draft has long expired, but maybe the idea should be mentioned as a possible alternative approach?

With these points in mind, I think that the draft is mature enough to be adopted as a WG document (even if you did not ask for that:-).

Regards,

Sasha

________________________________
From: pwe3 <[email-masked]> on behalf of Andrew G. Malis <[email-masked]>
Sent: Saturday, September 27, 2014 6:02 PM
To: [email-masked]
Subject: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

PWE3ers,

Revision -00 of this draft was presented at the Toronto IETF and we received good feedback from the WG. We've updated the draft to incorporate the received comments. The draft plugs an important hole in resilience for static MS-PWs. Please review and comment to the list, it's a very quick read.

Thanks,
Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Sep 26, 2014 at 6:05 PM
Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
To: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : S-PE Outage Protection for Static Multi-Segment Pseudowires
        Authors         : Andrew G. Malis
                          Loa Andersson
                          Huub van Helvoort
                          Jongyoon Shin
                          Lei Wang
                          Alessandro D'Alessandro
        Filename        : draft-shawam-pwe3-ms-pw-protection-01.txt
        Pages           : 5
        Date            : 2014-09-26

Abstract:

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<http://tools.ietf.org>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft> directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Sep 2014 07:46:21 -0400

Sasha,

Thanks for your comments. In order:

1. No, the intended scope of this draft is Section 3.2.3 of RFC 6718 and
Section A.5 of RFC 6870, which describe a single-homed CE. They both use
the same network model diagram. I hadn't thought it was necessary to
replicate that diagram a third time, but I certainly can and will in the
next revision.

2. This is actually discussed in those two sections. Basically, the entire
primary PW is protected against failure by switching to the secondary PW if
the primary fails for any reason. In the case of a MS-PW where the
individual segments are each protected via tunnel protection, the likely
cause of primary PW failure would be S-PE failure.

3. You're actually thinking of the -00 revision of this draft. That is the
approach that was presented at the Toronto PWE3 meeting, and the consensus
of the discussion was that the approach in this revision should be used
instead.

Cheers,
Andy

On Sun, Sep 28, 2014 at 1:03 AM, Alexander Vainshtein <
[email-masked]> wrote:

>  Andy,
>
> I've read the draft and re-read RFC 6780, and I have a couple of
> questions/comments that, from my point of view, should be clarified in the
> next revision of the draft.
>
>    1. RFC 6780 and RFC 6718 describe multiple use cases for PW
>    redundancy, including use cases with dual-homed CEs, use cases for VPLS
>    etc. The draft refers to specific sections in these RFCs that deal with the *use
>    case of two single-homed CEs, so I guess that this is the intended scope of
>    the draft*. Is this assumption correct? If yes, I would suggest
>    stating this explicitly and even including the corresponding reference
>    network model diagram in the draft. This would not unduly expand the
>    document while making it much more readable IMO.  (And maybe you should
>    mention draft-cheng-pwe3-mpls-tp-dual-homing-protection a dealing with the
>    dual-homing use cases?)
>    2. RFC 6870 does not explain how S-PE failure is detected. I assume
>    that one of the possible ways to do that could be by treating failure of
>    the targeted/indirect LDP session between this S-PE and its adjacent PEs as
>    S-PE failure. This is clearly not relevant in the case of statically set up
>    MS-PWs. I would suggest adding a few words regarding possible methods for
>    detecting S-PE failure. (As an absolute minimum, you could state that this
>    is out of scope of the document...)
>    3. To the best of my recollection somebody has once posted a
>    draft that suggested treating static MS-PWs as MPLS-TP co-routed
>    bi-directional LSPs (which is true)and applying LSP Linear Protection for
>    end-to-end protection of MS-PWs. This draft has long expired, but maybe the
>    idea should be mentioned as a possible alternative approach?
>
> With these points in mind, I think that the draft is mature enough to be
> adopted as a WG document (even if you did not ask for that:-).
>
>
>
> Regards,
>
> Sasha
>  ------------------------------
>  *From:* pwe3 <[email-masked]> on behalf of Andrew G. Malis <
> [email-masked]>
> *Sent:* Saturday, September 27, 2014 6:02 PM
> *To:* [email-masked]
> *Subject:* [PWE3] Fwd: I-D Action:
> draft-shawam-pwe3-ms-pw-protection-01.txt
>
>   PWE3ers,
>
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
> directories: http://www.ietf.org/shadow.html

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 29 Sep 2014 12:03:27 +0000

Andy,
Lots of thanks for a prompt and detailed response. Please see more inline below.

Regards,
       Sasha
Email: [email-masked]
Mobile: 054-9266302

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Monday, September 29, 2014 2:46 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

Sasha,

1. No, the intended scope of this draft is Section 3.2.3 of RFC 6718 and Section A.5 of RFC 6870, which describe a single-homed CE. They both use the same network model diagram. I hadn't thought it was necessary to replicate that diagram a third time, but I certainly can and will in the next revision.[[Sasha]] Great!

2. This is actually discussed in those two sections. Basically, the entire primary PW is protected against failure by switching to the secondary PW if the primary fails for any reason. In the case of a MS-PW where the individual segments are each protected via tunnel protection, the likely cause of primary PW failure would be S-PE failure.[[Sasha]] I have looked up these sections again, and they say “If active/primary PW fails…”. They also mention  that typically the reason for PW failure (end-to-end) is S-PE failure. But no specific method for detecting the failure of the primary/active PW is mentioned. Maybe this should be expanded a bit in the draft with emphasis on methods that are specific to MPLS-TP and statically configured MS-PWs?

3. You're actually thinking of the -00 revision of this draft. That is the approach that was presented at the Toronto PWE3 meeting, and the consensus of the discussion was that the approach in this revision should be used instead.[[Sasha]] Could be my mistake. And even if the approach has been changed from -00 to -01, I think that mentioning an alternative approach would be nice IMO.

Cheers,
Andy

On Sun, Sep 28, 2014 at 1:03 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:

Andy,

Regards,

Sasha

________________________________
From: pwe3 <[email-masked]<mailto:[email-masked]>> on behalf of Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, September 27, 2014 6:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

PWE3ers,

Thanks,
Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Sep 26, 2014 at 6:05 PM
Subject: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Sep 2014 08:43:02 -0400

Sasha,

The mechanism for static PW failure handling is in RFC 6478, which is also
referenced in the draft.

The primary purpose for an RFC is interoperability. If the draft contains
more than one approach, then one of those approaches has to be mandatory to
implement and use, and the other optional, otherwise you can't assure
interoperability. In which case, does it make sense to include more than
one approach and make one optional to implement? And of course, if you
implement both, then the primary approach has to be the default one used.
Then you'll also require either consistent provisioning to make sure that
the two ends agree on the approach used, or a negotiation mechanism. It
seems like you're adding a lot of work to document more than one approach.

Cheers,
Andy

On Mon, Sep 29, 2014 at 8:03 AM, Alexander Vainshtein <
[email-masked]> wrote:

>  Andy,
>
> Lots of thanks for a prompt and detailed response. Please see more *inline
> below*.
>
>
>
> Regards,
>
>        Sasha
>
> *From:* Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Monday, September 29, 2014 2:46 PM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]
> *Subject:* Re: [PWE3] Fwd: I-D Action:
> next revision.*[[Sasha]] Great! *
>
>
>
> cause of primary PW failure would be S-PE failure.*[[Sasha]] I have
> looked up these sections again, and they say “If active/primary PW fails…”.
> They also mention  that typically the reason for PW failure (end-to-end) is
> S-PE failure. But no specific method for detecting the failure of the
> primary/active PW is mentioned. Maybe this should be expanded a bit in the
> draft with emphasis on methods that are specific to MPLS-TP and statically
> configured MS-PWs? *
>
>
>
> instead.*[[Sasha]] Could be my mistake. And even if the approach has been
> changed from -00 to -01, I think that mentioning an alternative approach
> would be nice IMO.   *
>
>
>
> Cheers,
>
> Andy
>
>
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 29 Sep 2014 15:33:56 +0200

Hello,

I agree with the assessment from Andy.
Use the mechanism in RFC6478 also for PW.
A single approach is much less complex to provision.

Suppose there is a second approach, do _we_ have to search for it?
Then it has to determined which is preferred/better to use as default,
Maybe there is even a third approach...

Best regards, Huub.

> The mechanism for static PW failure handling is in RFC 6478, which is
> also referenced in the draft.
>
> The primary purpose for an RFC is interoperability. If the draft
> contains more than one approach, then one of those approaches has to be
> mandatory to implement and use, and the other optional, otherwise you
> can't assure interoperability. In which case, does it make sense to
> include more than one approach and make one optional to implement? And
> of course, if you implement both, then the primary approach has to be
> the default one used. Then you'll also require either consistent
> provisioning to make sure that the two ends agree on the approach used,
> or a negotiation mechanism. It seems like you're adding a lot of work to
> document more than one approach.
>
> Cheers,
> Andy
>
>
> On Mon, Sep 29, 2014 at 8:03 AM, Alexander Vainshtein
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Andy,____
>
>     Lots of thanks for a prompt and detailed response. Please see more
>     */inline below/*.____
>
>     __ __
>
>     Regards,____
>
>             Sasha ____
>
>     <mailto:[email-masked]>____
>
>     Mobile: 054-9266302____
>
>     __ __
>
>     *From:*Andrew G. Malis [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     draft-shawam-pwe3-ms-pw-protection-01.txt____
>
>     __ __
>
>     Sasha,____
>
>     __ __
>
>     Thanks for your comments. In order:____
>
>     __ __
>
>     1. No, the intended scope of this draft is Section 3.2.3 of RFC 6718
>     and Section A.5 of RFC 6870, which describe a single-homed CE. They
>     both use the same network model diagram. I hadn't thought it was
>     necessary to replicate that diagram a third time, but I certainly
>     can and will in the next revision.*/[[Sasha]] Great! /*____
>
>     __ __
>
>     2. This is actually discussed in those two sections. Basically, the
>     entire primary PW is protected against failure by switching to the
>     secondary PW if the primary fails for any reason. In the case of a
>     MS-PW where the individual segments are each protected via tunnel
>     protection, the likely cause of primary PW failure would be S-PE
>     failure.*/[[Sasha]] I have looked up these sections again, and they
>     say “If active/primary PW fails…”. They also mention  that typically
>     the reason for PW failure (end-to-end) is S-PE failure. But no
>     specific method for detecting the failure of the primary/active PW
>     is mentioned. Maybe this should be expanded a bit in the draft with
>     emphasis on methods that are specific to MPLS-TP and statically
>     configured MS-PWs? /*____
>
>     __ __
>
>     3. You're actually thinking of the -00 revision of this draft. That
>     is the approach that was presented at the Toronto PWE3 meeting, and
>     the consensus of the discussion was that the approach in this
>     revision should be used instead.*/[[Sasha]] Could be my mistake. And
>     even if the approach has been changed from -00 to -01, I think that
>     mentioning an alternative approach would be nice IMO. /*____
>
>     __ __
>
>     Cheers,____
>
>     Andy____
>
>     __ __
>
>     On Sun, Sep 28, 2014 at 1:03 AM, Alexander Vainshtein
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>     Andy,____
>
>     questions/comments that, from my point of view, should be clarified
>     in the next revision of the draft.____
>
>         redundancy, including use cases with dual-homed CEs, use cases
>         for VPLS etc. The draft refers to specific sections in these
>         RFCs that deal with the /use case of two single-homed CEs, so I
>         guess that this is the intended scope of the draft/. Is this
>         assumption correct? If yes, I would suggest stating this
>         explicitly and even including the corresponding reference
>         network model diagram in the draft. This would not unduly expand
>         the document while making it much more readable IMO.  (And maybe
>         you should mention
>         draft-cheng-pwe3-mpls-tp-dual-homing-protection a dealing with
>         the dual-homing use cases?) ____
>         that one of the possible ways to do that could be by treating
>         failure of the targeted/indirect LDP session between this S-PE
>         and its adjacent PEs as S-PE failure. This is clearly not
>         relevant in the case of statically set up MS-PWs. I would
>         suggest adding a few words regarding possible methods for
>         detecting S-PE failure. (As an absolute minimum, you could state
>         that this is out of scope of the document...)____
>         bi-directional LSPs (which is true)and applying LSP Linear
>         Protection for end-to-end protection of MS-PWs. This draft has
>         long expired, but maybe the idea should be mentioned as a
>         possible alternative approach?____
>
>     With these points in mind, I think that the draft is mature enough
>     to be adopted as a WG document (even if you did not ask for that:-).
>     ____
>
>     ____
>
>     Regards,____
>
>     Sasha____
>
>     ------------------------------------------------------------------------
>
>     *From:*pwe3 <[email-masked] <mailto:[email-masked]>>
>     on behalf of Andrew G. Malis <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* [email-masked] <mailto:[email-masked]>
>     draft-shawam-pwe3-ms-pw-protection-01.txt____
>
>     ____
>
>     PWE3ers, ____
>
>     __ __
>
>     received good feedback from the WG. We've updated the draft to
>     incorporate the received comments. The draft plugs an important hole
>     in resilience for static MS-PWs. Please review and comment to the
>     list, it's a very quick read.____
>
>     __ __
>
>     Thanks,____
>
>     Andy____
>
>     __ __
>
>     From: <[email-masked] <mailto:[email-masked]>>
>     To: [email-masked] <mailto:[email-masked]>
>

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 29 Sep 2014 13:44:45 +0000

Huub,

To the best of my understanding RFC 6478 is all about Static PW Status messages. 
So I am not sure what you mean when you say "use it also for PW". 

The draft actually proposes to use the PW redundancy mechanisms defined in RFC 6718 and RFC 6870 for static MS-PWs using static PW Status messages (defined in RFC 6478) in order to carry the "forwarding preference" and "request switchover" bits needed for  PW redundancy.

As for an alternative approach - I believe I have been misunderstood, probably did not present my position clearly.
I did not mean that linear protection should be presented as an optional alternative solution, just that it should be mentioned as an approach that has been considered and rejected.

To the best of my recollection, the L2VPN WG is now advancing the IPLS draft to become a Historic RFC for the same purpose - to record an idea that has been considered and rejected...
(Not sure if we can consider this as a precedent - the IPLS draft has been in limbo for more than 10 years IMO. Does age count as a special merit?:-)

Regards,
       Sasha 

> -----Original Message-----
> From: pwe3 [mailto:[email-masked]] On Behalf Of Huub van
> Helvoort
> Sent: Monday, September 29, 2014 4:34 PM
> To: [email-masked]
> > contains more than one approach, then one of those approaches has to
> > be mandatory to implement and use, and the other optional, otherwise
> > you can't assure interoperability. In which case, does it make sense
> > to include more than one approach and make one optional to implement?
> > And of course, if you implement both, then the primary approach has to
> > be the default one used. Then you'll also require either consistent
> > provisioning to make sure that the two ends agree on the approach
> > used, or a negotiation mechanism. It seems like you're adding a lot of
> > work to document more than one approach.
> >
> > Cheers,
> > Andy
> >
> >
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Sep 2014 10:14:24 -0400

Sasha,

Typically, solution drafts don't include alternative rejected approaches,
usually it's a framework or architecture draft that discusses the universe
of possible approaches.

The IPLS draft is being published because the concepts in the original work
have been adopted by newer work, thus making it interesting historically.

Cheers,
Andy

On Mon, Sep 29, 2014 at 9:44 AM, Alexander Vainshtein <
[email-masked]> wrote:

> The draft actually proposes to use the PW redundancy mechanisms defined in
> RFC 6718 and RFC 6870 for static MS-PWs using static PW Status messages
> (defined in RFC 6478) in order to carry the "forwarding preference" and
> "request switchover" bits needed for  PW redundancy.
>
> As for an alternative approach - I believe I have been misunderstood,
> probably did not present my position clearly.
> I did not mean that linear protection should be presented as an optional
> alternative solution, just that it should be mentioned as an approach that
> has been considered and rejected.
>
> To the best of my recollection, the L2VPN WG is now advancing the IPLS
> draft to become a Historic RFC for the same purpose - to record an idea
> that has been considered and rejected...
> (Not sure if we can consider this as a precedent - the IPLS draft has been
> in limbo for more than 10 years IMO. Does age count as a special merit?:-)
>
> Regards,
>        Sasha
> > >              Filename        :
> > >     until the htmlized version and diff are available at
> tools.ietf.org
> > >     <http://tools.ietf.org>.
> > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 29 Sep 2014 14:15:38 +0000

Andy,
I am OK with this.

Regards,
       Sasha

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Monday, September 29, 2014 5:14 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Fwd: I-D Action: draft-shawam-pwe3-ms-pw-protection-01.txt

Sasha,

Typically, solution drafts don't include alternative rejected approaches, usually it's a framework or architecture draft that discusses the universe of possible approaches.

The IPLS draft is being published because the concepts in the original work have been adopted by newer work, thus making it interesting historically.

Cheers,
Andy

On Mon, Sep 29, 2014 at 9:44 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Huub,

Regards,
       Sasha
Email: [email-masked]<mailto:[email-masked]>
Mobile: 054-9266302

> From: pwe3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Huub van
> Helvoort
> > <[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >     Andy,____
> >
> >     Email: [email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>____
> >
> >     Mobile: 054-9266302____
> >
> >     __ __
> >
> >     *From:*Andrew G. Malis [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>]
> >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >     <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:____
> >
> >     Andy,____
> >
> >     *From:*pwe3 <[email-masked]<mailto:[email-masked]> <mailto:pwe3-<mailto:pwe3->
> [email-masked]<mailto:[email-masked]>>>
> >     on behalf of Andrew G. Malis <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>
> >     *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >     From: <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> >     To: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >
> >     until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>
> >     <http://tools.ietf.org>.
> >
> [email-masked]<mailto:[email-masked]>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Sep 2014 18:03:17 -0400

Sasha,

Thanks!

All, I'm planning another update prior to the pre-Hawaii deadline to
incorporate Sasha's comments and any others that come in. Please read and
comment.

Cheers,
Andy

On Mon, Sep 29, 2014 at 10:15 AM, Alexander Vainshtein <
[email-masked]> wrote:

> *Sent:* Monday, September 29, 2014 5:14 PM
> *Cc:* [email-masked]; [email-masked]
>
> The IPLS draft is being published because the concepts in the original
> work have been adopted by newer work, thus making it interesting
> historically.
>
>
>
> Cheers,
>
> Andy
>
>
>