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

[<[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Shahram Davari
> Sent: 16 September 2009 01:55
> To: Adrian Farrel
> Cc: [e-mail]
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>