Subject: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Sep 2009 23:37:31 +0100

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

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 10 Sep 2009 16:04:41 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, September 10, 2009 3:38 PM
To: [email-masked]
Subject: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 11 Sep 2009 13:37:28 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, September 10, 2009 4:05 PM
To: Adrian Farrel; [email-masked]
Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Hi Adrian,

6. IANA Considerations

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, September 10, 2009 3:38 PM
To: [email-masked]
Subject: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 12 Sep 2009 12:47:25 +0100

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf 
Of Shahram Davari
Sent: Thursday, September 10, 2009 4:05 PM
To: Adrian Farrel; [email-masked]
Subject: Re: [mpls-tp] Last call comments on 
draft-ietf-mpls-tp-gach-dcn-05.txt

Hi Adrian,

6. IANA Considerations

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: [email-masked] [mailto:[email-masked]] On Behalf 
Of Adrian Farrel
Sent: Thursday, September 10, 2009 3:38 PM
To: [email-masked]
Subject: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 15 Sep 2009 17:55:09 -0700

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:[email-masked]]
Sent: Saturday, September 12, 2009 4:47 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Hi Shahram,

Cheers,
Adrian

----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, September 11, 2009 9:37 PM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----

Hi Adrian,

6. IANA Considerations

Regards,
Shahram

-----Original Message-----

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

---

From: <[email-masked]>
Date: Wed, 16 Sep 2009 05:40:17 +0100

All,

I've mentioned this before, but let me say it one more time in case
there is still time to 'get it right first time' in MPLS-TP:

We should have a clear differentiation between the logically OOB CP/MP
and the DP (so that is both client traffic and *this (server) layer*
OAM) networks in MPLS-TP.  Further, the Characteristic Information (a
Functional Architecture term) should always be consistent in all cases.
What this means practically is this:

-	DP traffic units should always look identical to DP OAM messages
wrt DP forwarding information, ie exactly the same header.  This will
not be true if the DP OAM sits under the GAL (whilst clearly the client
traffic does not).  The plain fact is that the OAM indicate function
should be part of the normal DP traffic header and it should be
logically associated with (ie wrt insertion/extraction) LSP trail
termination points (ie fully independent of client traffic case that
comes down through client/server adaptation...LSP OAM should not come
down through this same adaptation, eg we want the DP OAM to be able
monitor a protection LSP that is not carrying any traffic).

-	The GAL should only be used for the logically OOB CP/MP network
case.

-	PID considerations:  There are 2 separate cases (i) CP/MP
network and (ii) DP network.  So a different PID instance is required in
each case.  Shahram is largely talking about the CP/MP case below.  In
the DP case, one *only* needs a PID function IFF the parent LSP
connection will carry different client instances over its lifetime.  We
should not confuse these 2 PID cases....but I fear we will if we carry
only with the current arch position of GAL/ACH use.

I would urge we try and get MPLS-TP as architecturally right as we can
at the outset.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shahram Davari
> Sent: 16 September 2009 01:55
> To: Adrian Farrel
> Cc: [email-masked]
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Shahram Davari
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Adrian Farrel

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Sep 2009 18:28:45 +0100

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 16, 2009 1:55 AM
Subject: RE: [mpls-tp] Last call comments on 

Hi Adrian,

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:[email-masked]]
Sent: Saturday, September 12, 2009 4:47 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on 

Hi Shahram,

Cheers,
Adrian

----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, September 11, 2009 9:37 PM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----

Hi Adrian,

6. IANA Considerations

Regards,
Shahram

-----Original Message-----

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 16 Sep 2009 10:46:19 -0700

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:[email-masked]]
Sent: Wednesday, September 16, 2009 10:29 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on draft-ietf-mpls-tp-gach-dcn-05.txt

Shahram, hello.

Adrian
----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 16, 2009 1:55 AM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Saturday, September 12, 2009 4:47 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on

Hi Shahram,

Cheers,
Adrian

----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, September 11, 2009 9:37 PM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----

Hi Adrian,

6. IANA Considerations

Regards,
Shahram

-----Original Message-----

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Sep 2009 20:35:27 +0100

Hi again,

After a *lot* of trawling, I managed to find the email thread I had in 
private with Stewart some months ago. Yes, I too had the same questions as 
you!

I hope Stewart won't mind me copying his private response.

>> I am looking at the DCN work for the G-ACh
>>
>> I thought I had this all clear, but I just looked at 4385 (not 4446)
>> and the IANA page at http://www.iana.org/assignments/pwe3-parameters,
>> and I found *far* fewer allocated code points than I expected.
>
> Currently the only protocol that runs over an ACH is VCCV, and in
> practice the only protocol stack runs is IPv4/UDP/BFD.
>
> The IP-free BFD has not been given a code point in the registry although
> the draft has an expected value.
>
>> In my mind, there were a bunch of allocations for various "uses"
>> (things like VCCV...). But what I find is that only two values are
>> allocated...
>> Registry:
>> Value   Description                                 Reference
>> -----   ------------------------------------------  ---------
>> 0x21    Associated Channel carries an IPv4 packet   [RFC4385]
>> 0x57    Associated Channel carries an IPv6 packet   [RFC4385]
>
>Given where we are today and how we think we should move forward
> we should change the description to VCCV over IPv4, etc.
>
> Matthew and I are planning and update to RFC4385, and we could pick
> that up in the update.
>
>> In the DCN work we intended doing two things:
>>
>> 1. Indicate that the packet is for the DCN (actually split to MCN and
>> SCN)
>> 2. Indicate the payload protocol (IPv4, IPv6, OSI, etc, etc.)
>>
>> Because I mistook the current usage of the ACH channel type field, I
>> assumed we should use it to indicate MCN and SCN. That left us
>> defining the payload protocol somewhere else.
>>
>> Am I completely wrong?
>
> No the current plan - which is consistent with the actuality of the past -
> is to use the ACH to indicate a function.
>
>> A. Should we use the ACH channel type to identify the payload
>> protocol?
>
> The ACH should indicate the function. If the designers believe it
> optimizes there parsing they may have an ACH codepoint per
> function per encap.
>
>> B. Should we use the ACH channel type *only* for the purpose of
>> identifying the payload protocol?
>
> I don't think so. For example some functions need to be queued in
> different places with different policies. So need to be executed in h/w
> some in the mgt processor. We need to use the ACH to provide the
> necessary steering of the packet.
>
>> C. Do we actually need to identify the channel usage (OAM, MCN,
>> SCN, whatever...)?
>
> I think so for the reasons articulated in (B).

I hope that helps to clear that up.

Regards,
Adrian

----- Original Message ----- 
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 16, 2009 6:46 PM
Subject: RE: [mpls-tp] Last call comments on 

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:[email-masked]]
Sent: Wednesday, September 16, 2009 10:29 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on 

Shahram, hello.

Adrian
----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 16, 2009 1:55 AM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Saturday, September 12, 2009 4:47 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] Last call comments on

Hi Shahram,

Cheers,
Adrian

----- Original Message -----
From: "Shahram Davari" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, September 11, 2009 9:37 PM
Subject: RE: [mpls-tp] Last call comments on

Hi Adrian,

Regards,
Shahram

-----Original Message-----

Hi Adrian,

6. IANA Considerations

Regards,
Shahram

-----Original Message-----

Hi all,

Thanks,
Adrian

=====

1. How to encode the PID

Section 1
OLD

    0                   1                   2                   3

    0                   1                   2                   3

---

Section 6

DELETE

=====

---
Section 1.1
OLD

=====

---

Section 1.1

OLD

=====

---

Seciton 2

OLD