Re: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an mpls wg document

[Quintin Zhao <[e-mail]>]

Dan, 

Thank you for your review and helping us create a better document. I will
discuss your comments with the other authors and we will incorporate changes
in a future version of our document. 

Thanks,
Quintin.

----------------------------------------------------------------------

Message: 1
Date: Sun, 2 Oct 2011 21:33:59 +0100
From: "Daniel King" <[e-mail]>
To: <[e-mail]>
Subject: Re: [mpls] poll on making
	draft-zhao-mpls-ldp-multi-topology-02.txt	an mpls wg document
Message-ID: <001e01cc8142$9dd61760$d9824620$@olddog.co.uk>
Content-Type: text/plain;	charset="US-ASCII"

Hi WG,

Just wanted to add my support for the work/document.

Authors,  I have also reviewed the document. I can provide an MS word
document with change modification indicators  to the current editor(s). In
the meantime here are a number of comments and suggestions. Assuming the
document is adopted, these suggestions might be incorporated after the ID is
submitted as draft-ietf. 

1. Solution Comments

Having spoken to various vendors and operators I believe the preferred
solution is to extend MPLS for MT networks by mapping an IP address to the
corresponding Multi Topology:

Single topology label ~ address
MT label ~ (address plus topology)

This would negate the need for changes at the data plane.  Then the only
mapping required is at the ingress-PE of an MPLS-MT LSP, each node would be
capable of identifying the MPLS-MT LSP, and traffic is switched accordingly
based on the incoming label information. This solution uses minimal protocol
extensions. 

Please find my suggested updates and fixes for the first half of the
document. 

1. Document editors, table of contents  and formatting

- ChinaMobile/China Mobile
- Verison/Verizon
- Unnecessary number of CRs between authors and document title/name. 
- FEC TLV with MT-ID Extenstion/FEC TLV with MT-ID Extension

2. Revised Abstract

>>
Multi-topology (MT) routing is supported in IP through extension of IGP
protocols, such as OSPF and IS-IS.  It would be advantageous to extend
Multiprotocol Label Switching (MPLS), using Label Distribution Protocol
(LDP), to support multiple topologies. These LDP extensions, known as
Multiple Topology Label Distribution Protocol (MT LDP), would allow the
configuration of multiple topologies within an MPLS LDP enabled network. 

This document describes the protocol extensions required to extend the
existing MPLS LDP signalling protocol for creating and maintaining LSPs in
an MT environment.
<<

Line 34: enviroment/environment

3. The introduction, as well as other areas of the document, could do with
significant weight loss. Although interesting, some of the text is redundant
in this document. I would suggest the introduction is slimmed down to the
following text/edits, and a new requirements section (see comment 4) is
added:

>>
OSPF and IS-IS use MT-ID (Multi-Topology Identification) to identify
different topologies.  For each topology identified by a MT-ID, IGP computes
a separate SPF tree independently to find the best paths to the IP prefixes
associated with this topology. 

For FECs that are associated with a specific topology, this solution
utilises the same MT-ID of this topology in LDP.  Thus LSP for a certain FEC
may be created and maintained along the IGP path in this topology.

Maintaining multiple MTs for MPLS network in a backwards-compatible manner
requires several extensions to the label signaling encoding and processing
procedures.  When label is associated with a FEC, the FEC includes both IP
address and topology it belongs to.
<<

Line 204: certian/certain

Line 238: managment/management

Line 241: forwarding/forwarding

Line 251: tolology/topology

Line 253: assinged/assigned

Line 256: prtoco/protocol

Line 260: distingushed/distinguished and assinged/assigned

4. Requirements, specifically the lack thereof. The document would benefit
from a paragraph with bullets detailing the objectives/requirements for
these protocol extensions. 

5.  Application Scenarios are useful but specific requirements can be
blended into the requirements section. 

Thanks,
Dan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Loa
Andersson
Sent: 20 September 2011 19:16
To: [e-mail]; [e-mail]
Subject: [mpls] poll on making draft-zhao-mpls-ldp-multi-topology-02.txt an
mpls wg document

Working Group,

this is to start a two week poll to see if there is support to make

     LDP Extension for Multi Topology Support
     draft-zhao-mpls-ldp-multi-topology-02.txt

an MPLS working group document.

Send your opinions to [e-mail]

Please remember that it is particular important that you include a technical
motivation if you don't want the ID to become a working group document.

The poll ends Wednesday Oct 5, 2011.

/Loa
for the MPLS wg co-chairs


-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]
_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls



------------------------------

Message: 2
Date: Mon, 03 Oct 2011 09:46:46 -0400
From: Eric Rosen <[e-mail]>
To: Kamran Raza <[e-mail]>
Cc: [e-mail]
Subject: Re: [mpls] mpls-ldp-ipv6 : Issue needs WG input
Message-ID: <28735.1317649606@erosen-linux>


I agree with Carlos and Kamran, and would suggest the removal of section 7.

Also, the last paragraph of section 3 seems dubious:

   Additionally, it is desirable that a packet is forwarded to an LSP
   of an egress router, only if LSP's address-family matches with that
   of the LDP hello adjacency on the next-hop interface.

> The issue is that the current LDP spec rfc5036 allows an LDP peer to
> advertise IPv6 bindings to an LDP IPv4 peer, even though the peer may
> not have any IPv6 enabled (or IPv6 LDP), and vice versa.

There is a general issue of how to prevent LDP from sending label bindings
to a particular peer, if the peer doesn't need those label bindings.  I
don't think the set of label bindings needed by the peer can be inferred
from the type of the Hello adjacency.

The information needed to choose the network layer protocol used by the LDP
session should not be used to infer the set of label bindings to be
distributed, as these are two independent choices.

I think proposals for constraining the set of advertised label bindings
should be outside the scope of this document.









------------------------------

Message: 3
Date: Mon, 03 Oct 2011 09:43:31 -0700
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-07.txt
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

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           : MPLS Transport Profile lock Instruct and Loopback
Functions
	Author(s)       : Sami Boutros
                          Siva Sivabalan
                          Rahul Aggarwal
                          Martin Vigoureux
                          Xuehui Dai
	Filename        : draft-ietf-mpls-tp-li-lb-07.txt
	Pages           : 11
	Date            : 2011-10-03

   Two useful Operations, Administration, and Maintenance (OAM)
   functions in a transport network are &quot;lock&quot; and
&quot;loopback&quot;. The lock
   function enables an operator to lock a transport path such that it
   does not carry client traffic, but can continue to carry OAM messages
   and may carry test traffic. The loopback function allows an operator
   to set a specific node on the transport path into loopback mode such
   that it returns all received data.

   This document specifies the lock function for MPLS networks and
   describes how the loopback function operates in MPLS networks.

   This document updates RFC 6371 section 7.1.1.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-07.txt


------------------------------

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls


End of mpls Digest, Vol 90, Issue 3
***********************************