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

["Adrian Farrel" <[e-mail]>]

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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
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:[e-mail]]
Sent: Saturday, September 12, 2009 4:47 AM
To: Shahram Davari
Cc: [e-mail]
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" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf
Of Shahram Davari
Sent: Thursday, September 10, 2009 4:05 PM
To: Adrian Farrel; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf
Of Adrian Farrel
Sent: Thursday, September 10, 2009 3:38 PM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp


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