Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt
"Shahram Davari" <davari@broadcom.com> Wed, 16 September 2009 17:46 UTC
Return-Path: <davari@broadcom.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15693A6AE7 for <mpls-tp@core3.amsl.com>; Wed, 16 Sep 2009 10:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKH0pVNuwmsP for <mpls-tp@core3.amsl.com>; Wed, 16 Sep 2009 10:46:00 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 599743A6B93 for <mpls-tp@ietf.org>; Wed, 16 Sep 2009 10:45:48 -0700 (PDT)
Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 16 Sep 2009 10:46:20 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 16 Sep 2009 10:46:20 -0700
From: Shahram Davari <davari@broadcom.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Date: Wed, 16 Sep 2009 10:46:19 -0700
Thread-Topic: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt
Thread-Index: Aco29JO/73U00hR+STeveAeH/n8GLAAAKkBA
Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751BF9E@SJEXCHCCR02.corp.ad.broadcom.com>
References: <9FD656FFC3D444868908B6F7FC727402@your029b8cecfe> <2C2F1EBA8050E74EA81502D5740B4BD6815751BA4F@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD6815751BBA1@SJEXCHCCR02.corp.ad.broadcom.com> <E30714E9B2F2432B8236C426AD67140B@your029b8cecfe> <2C2F1EBA8050E74EA81502D5740B4BD6815751BE5F@SJEXCHCCR02.corp.ad.broadcom.com> <B768638ABF464837AB6E9B2F5EA4D064@your029b8cecfe>
In-Reply-To: <B768638ABF464837AB6E9B2F5EA4D064@your029b8cecfe>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 66AFFBE639G18414614-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 17:46:02 -0000
Hi Adrian, OK, good trick :) But how do we handle the IPV4/V6? RFC5586 says use the Channel Type. Are we going to change that and use PID to signal IPV4/V6? Or both can be used? Regards, Shahram -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, September 16, 2009 10:29 AM To: Shahram Davari Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Shahram, hello. Equally, the PID could be considered as part of the G-ACh message. Then no change would be required. In the DCN case we would be saying that the G-ACh message consists of: - 2 bytes indicating the PID - the MCC/SCC message. Adrian ----- Original Message ----- From: "Shahram Davari" <davari@broadcom.com> To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: <mpls-tp@ietf.org> Sent: Wednesday, September 16, 2009 1:55 AM Subject: RE: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Hi Adrian, Here is what RFC5586 says: "The Channel Type field indicates the type of message carried on the associated control channel, e.g., IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel, or OAM or other maintenance function if IP demultiplexing is not used. For associated control channel packets where IP is not used as the multiplexer, the Channel Type indicates the specific protocol carried in the associated control channel." Also Figure 6 of that RFC shows this: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Zero or more ACH TLVs ~ ~ (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ G-ACh Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Which clearly shows ACH as 32 bits. So if we decide to add a PID then we need to update this RFC. Regards, Shahram -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Saturday, September 12, 2009 4:47 AM To: Shahram Davari Cc: mpls-tp@ietf.org Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Hi Shahram, I don't believe you are right that there is any change proposed to the ACH definition in 5586. The ACH is unchanged, but a PID field is inserted after the end of the ACH and before the start of the MCC/SCC message. You have made two suggestions which would both work, but I don't think you have given any strong reason to adopt either or to reject the current proposal the support of a number of people. If we use the ACH type to identify the payload protocol, we then have to define some difficult TLV presence rules (since the intention is to not have TLVs in the MCC/SCC case, but we might need TLVs in other cases where the payload is the same protocol). We could do that based on the setting of ACH header bits that were previously reserved. That would itself be a change to 5586 since the presence of the TLV header is described as a function of the ACH type. Cheers, Adrian ----- Original Message ----- From: "Shahram Davari" <davari@broadcom.com> To: "Adrian Farrel" <adrian@olddog.co.uk>; <mpls-tp@ietf.org> Sent: Friday, September 11, 2009 9:37 PM Subject: RE: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Hi Adrian, I have another proposal. My proposal is to use the reserved bits (at least one bit) to indicate Control or Management channel. That would be a simpler solution. Regards, Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Shahram Davari Sent: Thursday, September 10, 2009 4:05 PM To: Adrian Farrel; mpls-tp@ietf.org Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Hi Adrian, Can't the channel type be used to indicate the protocol? RFC4385 is using it that way to identify the protocol: 6. IANA Considerations IANA has set up a registry of "Pseudowire Associated Channel Types". These are 16-bit values. Registry entries are assigned by using the "IETF Consensus" policy defined in [RFC2434]. The value 0x21 indicates that the Associated Channel carries an IPv4 packet. The value 0x57 indicates that the Associated Channel carries an IPv6 packet. Also by adding PID you now need to go and change RFC5586, since in that RFC, the ACH is only 32 bits. Regards, Shahram -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, September 10, 2009 3:38 PM To: mpls-tp@ietf.org Subject: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt Hi all, Dieter and I had the honor of having this document reviewed again by the MEAD team on Tuesday. I am presenting their comments here as working group last call comments with my proposed solutions. As last call comments, they are (of course) up for discussion if anyone wants to add/change/refute them. Thanks, Adrian ===== 1. How to encode the PID This had been discussed on the mailing list a couple of times. It was felt that there is no need to use a TLV to encode the PID, and the removal of the ACH PID TLV from the message meant that there was no reason to include the ACH TLV header (as there are no other TLVs). If a TLV is invented in the future, new Channel Type values will be used to indicate (e.g.) MCC with TLVs. We then condsidered (again) whether 32 bit alignment was needed. Although historically we have always felt the need for alignment, it was felt that this is no longer a requirement for modern hardware or software. People who disagree wth this point are strongly encouraged to speak up now as this is the last chance to insert the necessary padding. This point results in the largest number of changes, as follows. Section 1 OLD The purpose of a packet carried on the G-ACh is indicated by the value carried by the Channel Type field of the ACH and a registry of values is maintained by IANA ([RFC4446] and [RFC4385]). The combination of the ACH and the ACH TLVs that may be appended to the ACH is referred in this document as the G-ACh header. NEW The purpose of a packet carried on the G-ACh is indicated by the value carried by the Channel Type field of the ACH and a registry of values is maintained by IANA ([RFC4446] and [RFC4385]). The ACH is referred in this document as the G-ACh header. END --- Section 2 OLD Figure 1 depicts the format of an MCC/SCC packet that is sent on the G-ACh. The Channel Type field indicates the function of the ACH message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message is prepended with an ACH with the Channel Type set to indicate that the message is an MCC or SCC message. The ACH MUST include the ACH Protocol ID TLV [ACH-TLV] to identify the protocol type of the MCC or SCC message, and MAY include further ACH TLVs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ zero or more ACH TLVs ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH Protocol ID TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MCC/SCC Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: G-ACh MCC/SCC Packet o The Channel Type field determines whether the message is an MCC or an SCC message. See Section 5 for the codepoint assignments. o No other ACH TLV (except the ACH protocol ID TLV - see below) has been identified for use on a DCN message. If a message is received carrying an ACH TLV that is not understood in the context of a DCN message, the ACH TLV SHOULD be silently ignored and processing of the message SHOULD continue. o The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC message. The ACH MUST be present in a DCN message and MUST be placed last in the sequence of ACH TLVs so that it comes immediately before the MCC/SCC message. Note that this means that the PID field of the TLV is immediately adjacent to the message itself [ACH-TLV]. The ACH Protocol ID TLV is defined in [ACH-TLV] and uses the PPP protocol identifiers to distinguish different protocols [RFC1661], [RFC3818]. When the G-ACh sender receives an MCC message that is to be sent over the MCC, the sender creates the G-ACh header, provides an ACH Protocol ID TLV indicating the MCC layer 3 PDU type, sets the Channel Type field to MCC, and prepends the MCC message with the G-ACh header. The same procedure is applied when a control plane message is to be sent over the SCC. In this case, the sender sets the Channel Type field to SCC. If the G-ACh is associated with an MPLS section, the GAL is added to the message as defined in [RFC5586]. The TTL field MUST be set to 1, and the S-bit of the GAL MUST be set to 1. If the G-ACh is associated with an LSP, the GAL is added to the packet and the LSP label is pushed on top of the GAL as defined in [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit of the GAL MUST be set to 1. The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification. When a receiver has received a packet on the G-ACh with the ACH Channel Type set to MCC or SCC, it SHALL look at the PID field carried in the ACH Protocol ID TLV. If the TLV is absent, the message SHALL be silently discarded, although a local system MAY increment a counter that records discarded or errored packets, and MAY log an event. If the PID value is known by the receiver it delivers the the MCC/SCC message to the appropriate processing entity. If the PID value is unknown, the receiver SHALL silently discard the received packet, MAY increment a counter that records discarded or errored messages, and MAY log an event. It must be noted that according to [RFC5586] a receiver MUST NOT forward a GAL packet based on the GAL label as is normally the case for MPLS packets. If the GAL appears at the bottom of the label stack, it MUST be processed as described in the previous paragraph. Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore it is important that user data (i.e., data NEW Figure 1 depicts the format of an MCC/SCC packet that is sent on the G-ACh. The Channel Type field indicates the function of the ACH message so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message is prepended with an ACH with the Channel Type set to indicate that the message is an MCC or SCC message. The ACH MUST NOT include the ACH TLV Header [RFC5586] meaning that no ACH TLVs can be included in the message. A two byte Protocol Identifier (PID) field indicates the protocol type of the payload DCN message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MCC/SCC Message | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: G-ACh MCC/SCC Packet o The Channel Type field determines whether the message is an MCC or an SCC message. See Section 5 for the codepoint assignments. o The presence of the PID field is deduced from the Channel Type value indicating MCC or SCC. The field contains an identifier of the payload protocol using the PPP protocol identifiers [RFC1661], [RFC3818]. When the G-ACh sender receives an MCC message that is to be sent over the MCC, the sender creates the G-ACh header, sets the Channel Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU type,and prepends the MCC message with the G-ACh header. The same procedure is applied when a control plane message is to be sent over the SCC. In this case, the sender sets the Channel Type field to SCC. If the G-ACh is associated with an MPLS section, the GAL is added to the message as defined in [RFC5586]. The TTL field MUST be set to 1, and the S-bit of the GAL MUST be set to 1. If the G-ACh is associated with an LSP, the GAL is added to the packet and the LSP label is pushed on top of the GAL as defined in [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit of the GAL MUST be set to 1. The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification. When a receiver has received a packet on the G-ACh with the ACH Channel Type set to MCC or SCC, it SHALL look at the PID field. If the PID value is known by the receiver it delivers the the MCC/SCC message to the appropriate processing entity. If the PID value is unknown, the receiver SHALL silently discard the received packet, MAY increment a counter that records discarded or errored messages, and MAY log an event. It must be noted that according to [RFC5586] a receiver MUST NOT forward a GAL packet based on the GAL label as is normally the case for MPLS packets. If the GAL appears at the bottom of the label stack, it MUST be processed as described in the previous paragraph. Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore it is important that user data (i.e., data END --- Section 6 DELETE [ACH-TLV] Bryant, S., et al., "Definition of ACH TLV Structure", draft-bryant-mpls-tp-ach-tlv, work in progress. END ===== 2. How to prioritise DCN packets It was noted that the 4th requirement in seciton 1.1 said that: The channel separation mechanism shall allow the use of separate rate limiters and traffic shaping functions for each channel It was felt that this may be ambiguous as "shall allow" might be assumed to mean that the separation must be the mechanism that facilitates the rate limiters. In discussion, it was agreed that the intent was that the separate channels must not prevent the use of separate rate limiters etc. At the same time, it was noted that the TC in the MPLS header already provides extensive capabilities for prioritising packets within and across channels. So two changes were made as follows. --- Section 1.1 OLD 4. The channel separation mechanism shall allow the use of separate rate limiters and traffic shaping functions for each channel (MCC and SCC) ensuring that the flows do not exceed their assigned traffic profiles. The rate limiters and traffic shapers are outside the scope of the MCC and SCC definitions. NEW 4. The channel separation mechanism shall not preclude the use of separate rate limiters and traffic shaping functions for each channel (MCC and SCC) ensuring that the flows do not exceed their assigned traffic profiles. The rate limiters and traffic shapers are outside the scope of the MCC and SCC definitions. END --- Page 5 NEW Para 4 Note that packet processing for DCN packets in the G-ACh is, in common with all G-ACh MPLS packets, subject to the normal processing of the Traffic Class (TC) field of the MPLS header. This could be used to enable prioritisation of different DCN packets. END ===== 3. Motivation for independent MCC and SCC It was felt that this requirement was real, but that the motivation needed a small amount of additional clatification. Therefore the following change was made. --- Section 1.1 OLD 3. The G-ACh shall provide two independent channels: an MCC to build the MCN and an SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is an MCC or an SCC packet in order to forward it to the management or control plane application for processing. NEW 3. The G-ACh shall provide two independent channels: an MCC to build the MCN and an SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is an MCC or an SCC packet in order to forward it to the management or control plane application for processing. This facilitates easy demultiplexing of control and management traffic from the DCN and enables separate or overlapping address spaces and duplicate protocol instances in the management and control planes. END ===== 4. Support for IP Fast Path Although the use of an IP fast path is not required, and the solution must support not having one, it was felt that the solution must not prohibit the use of a fast path if an implementation chooses to have one. A very minor change was made as follows. --- Seciton 2 OLD Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore it is important that user data (i.e., data NEW Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow or fast path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore it is important that user data (i.e., data END _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp
- [mpls-tp] Last call comments on draft-ietf-mpls-t… Adrian Farrel
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Shahram Davari
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Shahram Davari
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Adrian Farrel
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Shahram Davari
- Re: [mpls-tp] Last call comments on draft-ietf-mp… neil.2.harrison
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Adrian Farrel
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Shahram Davari
- Re: [mpls-tp] Last call comments on draft-ietf-mp… Adrian Farrel