Picon

New Liaison Statement, "Response to your liaison entitled “IETF draft on mobile backhaul“"

Title: Response to your liaison entitled “IETF draft on mobile backhaul“
Submission Date: 2014-10-21
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1356/

From: Broadband Forum (Christophe Alter <christophe.alter <at> orange.com>)
To: Multiprotocol Label Switching (Loa Andersson <loa <at> pi.nu>, George Swallow <swallow <at> cisco.com>,
Ross Callon <rcallon <at> juniper.net>)
Cc: Adrian Farrel <adrian <at> olddog.co.uk>,Alia Atlas <akatlas <at> gmail.com>,mpls <at> ietf.org,David
Sinicrope <david.sinicrope <at> ericsson.com>,christophe.alter <at> orange.com,rmersh <at> broadband-forum.org,gbingham <at> broadband-forum.org,charles.a.rexrode <at> verizon.com
Response Contact: 
Technical Contact: 
Purpose: In response
Referenced liaison: IETF draft on mobile back haul (http://datatracker.ietf.org/liaison/1343/)
Body: Dear Loa,

The IP MPLS & Core WG thanks the IETF MPLS WG for your liaison on “IETF draft on
mobile backhaul.” We have reviewed it and the individual draft it references,
(http://tools.ietf.org/id/draft-li-mpls-seamless-mpls-mbh-00.txt), at our Q3 meeting in
Dublin.

The WG concluded that the draft does not seem to specify extending or enhancing
protocols but appears to be more a solution architecture and requirements document.
Indeed, in the introduction of the draft, we find “the proposed requirements make it
possible to work out the complete solution for a flexible deployment of an end to end
mobile backhaul service delivery.”

The BBF has a history of working in this space; see for example TR-221, TR-178 and
TR-224. While not all the issues and requirements mentioned in the draft are covered in
these documents, we believe there is significant overlap.

(Continue reading)

BRUNGARD, DEBORAH A | 20 Oct 23:38 2014
Picon

FW: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11

FYI -

 

From: CCAMP [mailto:ccamp-bounces <at> ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Monday, October 20, 2014 5:27 PM
To: ccamp <at> ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11

 

All,

 

This starts a two-week working group last call on draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-11.

 

This working group last call ends on Nov. 3rd. Please send your comments to the CCAMP mailing list.

 

As noted, there is one IPR disclosed.

 

Thanks,

Deborah (and Lou)

 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
The IESG | 20 Oct 21:47 2014
Picon

Last Call: <draft-ietf-mpls-deprecate-bgp-entropy-label-01.txt> (Deprecation of BGP Entropy Label Capability Attribute) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Deprecation of BGP Entropy Label Capability Attribute'
  <draft-ietf-mpls-deprecate-bgp-entropy-label-01.txt> as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-11-03. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   RFC 6790 defines the BGP Entropy Label Capability attribute.
   Regrettably, it has a bug: although RFC 6790 mandates that Entropy
   Label-incapable routers must remove the attribute, in practice this
   requirement can't be guaranteed to be fulfilled.  This specification
   deprecates the attribute.  A forthcoming document will propose a
   replacement.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-deprecate-bgp-entropy-label/ballot/

No IPR declarations have been submitted directly on this I-D.

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

The IESG | 20 Oct 16:22 2014
Picon

Last Call: <draft-ietf-mpls-pim-sm-over-mldp-02.txt> (Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs'
  <draft-ietf-mpls-pim-sm-over-mldp-02.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-11-03. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   When IP multicast trees created by PIM-SM in Any Source Multicast
   (ASM) mode need to pass through an MPLS domain, it may be desirable
   to map such trees to Point-to-Multipoint Label Switched Paths. This
   document describes how to accomplish this in the case where such
   Point-to-Multipoint Label Switched Paths are established using Label
   Distribution Protocol Extensions for Point-to-Multipoint and
   Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP).

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/ballot/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/2189/

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

Lizhong Jin | 20 Oct 08:35 2014
Picon

Re: [Gen-art] review: draft-ietf-mpls-lsp-ping-relay-reply-04

Hi Joel,
Sorry for the late reply. I missed this email, and was reminded by Adrian.
Thank you for the review. Please see my comments inline below.

Regards
Lizhong

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 08 Oct 2014 19:20:17 -0400
> From: "Joel M. Halpern" <jmh <at> joelhalpern.com>
> To: "A. Jean Mahoney" <mahoney <at> nostrum.com>, gen-art <at> ietf.org,
> 	"mpls <at> ietf.org" <mpls <at> ietf.org>, Adrian Farrel
> <adrian <at> olddog.co.uk>,
> 	IETF discussion list <ietf <at> ietf.org>
> Subject: [mpls] [Gen-art] review:
> 	draft-ietf-mpls-lsp-ping-relay-reply-04
> Message-ID: <5435C6B1.2090908 <at> joelhalpern.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-mpls-lsp-ping-relay-reply-04
>      Relayed Echo Reply mechanism for LSP Ping
> Reviewer: Joel M. Halpern
> Review Date: 8-October-2014
> IETF LC End Date: 13-October-2014
> IESG Telechat date: (if known)
> 
> Summary: This document is not ready for publication as a Proposed Standard
> 
> Major issues:
>      There is either a major technical flaw in this document, or there is
a need
> for significantly better explanation.  The following is what I was able to
> understand from reading the document.
>      The procedure in the document calls for a responding or relaying LSR
to
> search the response addresses from the top to the bottom (top being the
> originator of the request, bottom being visible originators).
>   The responder then sends the reply to the first usable address it can
find in
> the stack.  Usable is variously described as "public routable"
> and as "routable" (in sections 4.2), the converse is described as
"unroutable"
> in section 4.3, while section 4.4 uses "routable".
> If it means "routable", then this assumes that the private addresses used
by
> one AS will not happen to also be used in another AS (which would make
> them routable in that domain, directing the reply to completely the wrong
> place.
> If it means "publicly routable", this would seem to fail since routers do
not
> know whether routable addresses are public, private, or simply not
martian.
[Lizhong] the "routable address" means that it is possible to route an IP
packet to this address using the normal information exchanged by the IGP
operating in the AS. I will add the definition explicitly in the document.
And for section 2, change "private address" to "routable address in AS1, but
not routable in AS2". For section 4.2, change "first public routable IP
address" to "first routable IP address".
Hope above changing will make things clear.

> 
> Minor issues:
>      The procedures assume that border routers will know the correct
address
> to put in the reply stack.  It is not bovious that even if the router has
a public
> address, it will get put on.  The requirement stated here is that the
address
> put on be the same one used to originate the reply.  Which would seem
likely
> to be na internal address in many cases.
[Lizhong] If there is a public address on the node, it is also possible to
add that address to the stack, which will help to relay the reply back.
Rephrase section 4.2:
The first address entry added by the replying LSR MUST be same as the source
IP address of Relay Echo Reply (section 4.3) or Echo Reply message (section
4.5) being sent. A second or more address entries could also be added if
necessary, which depends on implementation.

> 
>      The procedure for setting k=0 allowing entries to be removed from the
> stack seems fragile.  It relies on routers being able to determine that
their
> address will not be needed for relay by the next hop.
[Lizhong] if k=0, then the Relay Node Address Stack TLV could be compressed
to reduce the relayed hop number. This is a useful feature, and top to down
searching of the routable address will ensure relaying reply back correctly.

> 
> Nits/editorial comments:
>     Some of the procedure for originating a reply is described in section
4.2 on
> Receiving a request, rather than in seciton 4.3 on originating the reply.
> (Information such as the address to put on the stack, where it goes on the
> stack, and the handling of the reply packet being too large all belong in
4.3.)
[Lizhong] we try to put all Relay Node Address Stack processing into one
place to make it clear. Splitting the stack processing words into two
sections may cause confusion. But we could add a sentence in section 4.3,
saying that the updating of Relay Node Address Stack TLV in Relayed Echo
Reply is described in section 4.2.

> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> mpls mailing list
> mpls <at> ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> ------------------------------
> 
> End of mpls Digest, Vol 126, Issue 10
> *************************************

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

internet-drafts | 19 Oct 09:07 2014
Picon

I-D Action: draft-ietf-mpls-oam-ipv6-rao-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           : IPv6 Router Alert Option for MPLS OAM
        Authors         : Kamran Raza
                          Nobo Akiya
                          Carlos Pignataro
	Filename        : draft-ietf-mpls-oam-ipv6-rao-00.txt
	Pages           : 5
	Date            : 2014-10-19

Abstract:
   RFC4379 defines the MPLS LSP Ping/Traceroute mechanism, in which the
   Router Alert option must be set in the IP header of the MPLS Echo
   Request messages, and may conditionally be set in the IP header of
   the MPLS Echo Reply messages.  While a generic "Router shall examine
   packet" Option Value is used for the IPv4 Router Alert Option (RAO),
   there is no generic Router Alert Option Value defined for IPv6 that
   can be used.  This document allocates a new generic IPv6 Router Alert
   Option Value that can be used by MPLS OAM tools, including the MPLS
   Echo Request and MPLS Echo Reply messages for MPLS IPv6.

   The initial motivation to request an IPv6 Router Alert Option (RAO)
   code point for MPLS OAM comes from MPLS LSP Ping/Traceroute.
   However, this codepoint is applicable to all MPLS OAM and not limited
   to MPLS LSP Ping/Traceroute.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-oam-ipv6-rao-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

internet-drafts | 19 Oct 02:39 2014
Picon

I-D Action: draft-ietf-mpls-pim-sm-over-mldp-02.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           : Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs
        Authors         : Yakov Rekhter
                          Rahul Aggarwal
                          Nicolai Leymann
                          Wim Henderickx
                          Quintin Zhao
                          Richard Li
	Filename        : draft-ietf-mpls-pim-sm-over-mldp-02.txt
	Pages           : 12
	Date            : 2014-10-18

Abstract:
   When IP multicast trees created by PIM-SM in Any Source Multicast
   (ASM) mode need to pass through an MPLS domain, it may be desirable
   to map such trees to Point-to-Multipoint Label Switched Paths. This
   document describes how to accomplish this in the case where such
   Point-to-Multipoint Label Switched Paths are established using Label
   Distribution Protocol Extensions for Point-to-Multipoint and
   Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-pim-sm-over-mldp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-pim-sm-over-mldp-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-pim-sm-over-mldp-02

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

Martin Vigoureux | 18 Oct 22:19 2014

Slots requests for MPLS WG sessions - IETF 91 - Honolulu

All,

it is time we start building the MPLS WG agenda for Honolulu.
The IETF agenda is available at:
https://datatracker.ietf.org/meeting/agenda/

The MPLS WG sessions are scheduled on:
Monday, November 10th, Morning Session I, 09:00-11:30
and
Friday, November 14th, Morning Session I, 09:00-11:30

Please send *me* (by replying to this e-mail and copying the co-chairs)
your request for a presentation slot, indicating:
draft name, speaker and desired duration (covering presentation + Q&As)
*as well as* what the objective of the presentation is.

Please send the requests before the 26th of October.
Thank you

Martin

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

Adrian Farrel | 18 Oct 01:53 2014
Picon

AD review and progressing draft-ietf-mpls-deprecate-bgp-entropy-label

Hi,

I've done my AD review of this tiny draft and have no additional 
comments.

Any time you want to spell my name right, you can go right ahead :-)

Since the document has only Juniper authors, I will follow the
procedure Alia and I set out when she was appointed as my co-AD and
pass the document to another AD to complete the process.

Spencer Dawkins has agreed to step in to the breach.

Thanks,
Adrian

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

Loa Andersson | 17 Oct 15:59 2014
Picon

IPR poll on draft-kini-mpls-spring-entropy-label

Working Group,

We have done an MPLS-RT review of draft-kini-mpls-spring-entropy-label.

The outcome is such that we anticipate a poll for working group adoption
after the authors have updated the draft.

Before we do poll to see if we have consensus to accept the document
as a working group document we want to do an IPR poll on the document.

This mail starts that IPR poll.

Are you aware of any IPR that applies to draft-kini-mpls-spring-entropy-
label?

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 one 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)
--

-- 

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

Kamran Raza (skraza | 17 Oct 04:41 2014
Picon

My review comments [Re: MPLS-RT review of draft-kini-mpls-spring-entropy-label-01.txt]

I have reviewed the draft and here are my comments:

- I have found this document useful as it puts forward a good case of use
of EL in SR, as well as suggest EL procedures/algo for use in SR networks.
- I have found some sections (introductory + solution) that require some
cleanup / clarifications as per my per-section comments [ see below ].
- I believe that once author respin the rev that take care of
cleanup/re-org as per review comments, this document could be adopted as a
WG doc. 

Following are my per-section detailed comments:

Section 1: Introduction:
Although reader could infer the problem statement by reading other text in
this section, IMO, this section needs to state the problem statement
explicitly and clearly. For example, the last para talks about ³A
recommended solution² without stating the problem explicitly.

Section 3:
In the Service chaining use case, it is easy to confuse as a reader/writer
amongst ³S² (the LSR) vs ³S1² (Svc) vs ³S2² (Svc). The example is further
complicated as you are using notion SN to denote where ³S² is used as node
Segment Id of LSR-N. All this makes the description of label stack
cluttered with too many Ss. I suggest using LSR I/E (or A/B) for src and
dest LSRs, N1/N2 instead of S1/S2 service LSRs, F1 and F2 for respective
service functions, and keep using SN for SID of node N.  This means your
example of <SS1, S-SvcS1, SS2, S-SvcS2, SD> becomes <SN1, SF1, SN2, SF2,
SE>.

Section 4:

 - The title of this section is ³Recommended EL Solution for SPRING² ..
Should it not be renamed something like ³EL Procedures in SPRING²  ?
 - EL insertion algorithm needs to be bulletized or written in more
readable form (Flowchart?).

Section 5: 
  - As per my comment regarding section 4 title, the title needs renaming
from ³Options considered² to something like ³Discarded options for EL in
SPRING² ? 
  - I am not sure but should this section be moved to Appendix ?
  - Or, should we not swap section 4 and 5 ? ‹ i.e. first list all the
options and why they were rejected, followed by the recommended one.

Section 8. Security considerations:
  - The section is empty and needs some contents. At minimum, it needs to
state TBD to be addressed in later revisions.

Thanks.
‹ Kamran

On 2014-10-14, 4:11 PM, "Markus Jork" <mjork <at> juniper.net> wrote:

>I have been asked to review draft-kini-mpls-spring-entropy-label-01 as
>one of the MPLS-RT members.
> 
>The document is coherent and makes a good argument for why the entropy
>label mechanism is useful and needed for SPRING. There are likely to be
>networks for which this would be beneficial.
>
>Unfortunately, the nature of the problem and existing hardware
>compatibility constraints don't lend themselves to very elegant
>solutions. The proposed solution in section 4 pretty much screams
>"compromise". But the following sections do a good job of describing the
>design constraints and why other solutions were rejected. It will be
>useful to keep this content in the document somewhere even in its final
>version.
>
>I believe the document is ready for WG adoption. Though I think there are
>a couple of small problems with the examples in section 5 that should be
>corrected:
>
>1. Up to section 5.1, the example label stack includes a label S-SvcS2
>for the service at S2. But in all the following sections, this label is
>dropped from the examples. I think it's best to leave this out in all of
>the examples for brevity.
>
>2. In section 5.3, the first example is given as <SS11, ELI, EL, S-SvcS1,
>SS2, SD>.
>  That should be <SP1, ELI, EL, SS1, S-SvcS1, SS2, SD>
>
>3. In section 5.4, the example is given as:
>
>  "For the same Figure 1 above, if LSR P1
>   needs to have the EL within a depth of 4, then the source LSR S
>   encoded label stack would be <SS1, S-SvcS1, ELI, EL2, SS2, SD> where
>   all the ELs would typically have the same value."
>
>That is leaving out the first hop SP1 from the stack (which means the EL
>has to move up the stack). Also, only one EL is present. So why call it
>EL2?
>
>-Markus
>

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


Gmane