Subject: [mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-04.txt

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 15 Aug 2009 21:02:55 +0100

Hi,

I updated this document in line with the comments raised by the MEAD team 
during their review (please see my previous post).

I'm hoping that the I-D is pretty much complete now, and that WG last call 
won't be far away. Now might be a good time for you all to have quick read 
and check that it does what you want.

Cheers,
Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, August 15, 2009 9:00 PM
Subject: [mpls] I-D Action:draft-ietf-mpls-tp-gach-dcn-04.txt

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
> This draft is a work item of the Multiprotocol Label Switching Working 
> Group of the IETF.
>
>
> Title           : An Inband Data Communication Network For the MPLS 
> Transport Profile
> Author(s)       : D. Beller, A. Farrel
> Filename        : draft-ietf-mpls-tp-gach-dcn-04.txt
> Pages           : 9
> Date            : 2009-08-15
>
> The Generic Associated Channel (G-ACh) has been defined as a
> generalization of the pseudowire (PW) associated control channel to
> enable the realization of a control/communication channel associated
> with Multiprotocol Label Switching (MPLS) Label Switched Paths
> (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between
> adjacent MPLS-capable devices.
>
> The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
> architecture that identifies elements of the MPLS toolkit that may be
> combined to build a carrier grade packet transport network based on
> MPLS packet switching technology.
>
> This document describes how the G-ACh may be used to provide the
> infrastructure that forms part of the Management Communication
> Network (MCN) and a Signaling Communication Network (SCN).
> Collectively, the MCN and SCN may be referred to as the Data
> Communication Network (DCN). This document explains how MCN and SCN
> messages are encapsulated, carried on the G-ACh, and demultiplexed
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-dcn-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

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

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

---

From: <[email-masked]>
Date: Sun, 16 Aug 2009 00:17:04 +0100

Adrian,

My comments:

1)
Section 1:
   The use of the ACH is generalized in [RFC5586] and can be applied on
   any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP).
   This is referred to as the Generic Associated Channel (G-ACh) and is
   intended to create a control/management communication channel
   associated with the LSP that can be used to carry packets used for
   OAM and similar functions (e.g., control/management plane messages).

I think it would be worth discussing that there is no requirement for all
LSPs to have a G-Ach for DCN rather, at a minimum, any one LSP having a
G-Ach between two nodes requiring MCC/SCC communication with each other is
sufficient to build a DCN between those two nodes.

2)
Section 1.1:
None of the requirements listed have capitalised MUSTs/SHALLs/etc. Is this
intentional?

3)
Section 2:
   o No other ACH TLVs (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.

S/has been identified/have been identified/

4)
   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
     iteslf.

Should you s/ACh/ACH?
S/iteslf/itself/

5)
   If the PID value is known by the receiver it SHALL deliver the
   entire packet including the MCC/SCC message to the appropriate
   processing entity.

What is the rationale for delivering the whole packet (and not just the
payload) to the processing entity, or do you mean deliver the whole MCC/SCC
packet and do not mean deliver the whole MPLS-TP packet?

6)
   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 node MUST NOT forward the packet in
   the fast path. The node SHOULD apply layer 3 forwarding procedures
   in the slow path and MAY discard or rehect the message using the
   layer 3 protocol if it is unable to forward it.

What is the rationale for explicitly not allowing forwarding using the fast
path?

Also s/rehect/reject/

7)
Section 2.1, paragraph 1, s/singaling/signaling/

8)
Section 3, paragraph 1, s/intented/intended/

Ben

On 15/08/2009 21:02, "Adrian Farrel" <[email-masked]> wrote:

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 16 Aug 2009 17:11:01 +0300

Ben, Adrian  and all,
I wonder if the following requirement:
The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC message.
The ACH (Protocol ID TLV [[Sasha]]) 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
can be considered as common in the IETF context. I must admit that I do not remember another protocol that imposes restriction on position of a TLV in a TLV-based PDU. If/when fast (e.g., HW-based) parsing of PDUs is required, a fixed position method is used (as., e.g., in BFD).

Did I miss something important?

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Sunday, August 16, 2009 2:17 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Fw: I-D
> Action:draft-ietf-mpls-tp-gach-dcn-04.txt
>
> Adrian,
>
> My comments:
>
> 1)
> Section 1:
> --------------------------------------------------------------
> ----------------
> > --
> >
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Aug 2009 02:04:45 +0100

Hi Sasha,

Previous version, Protocol ID TLV was "just another TLV".

During review (by the MEAD team) it was pointed out that:
- it may be handy to have the PID located adjacent to the message
- we knew of no other TLVs that we would want in the DCN message.

To be fully flexible, however:
- Protocol ID TLV remains "just another TLV"
- other TLVs might be added in the future.

So we took the slightly unusual step of requiring the Protocol ID TLV to be 
the last one present.

Ordered TLVs are not uncommon. For example, look at RSVP-TE where semantics 
is placed on the object (i.e., TLV) ordering in some cases.

Cheers,
Adrian

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 16, 2009 3:11 PM:

Subject: RE: [mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-04.txt

Ben, Adrian  and all,
I wonder if the following requirement:
The ACH Protocol ID TLV identifies the PDU type of the MCC/SCC message.
The ACH (Protocol ID TLV [[Sasha]]) 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
can be considered as common in the IETF context. I must admit that I do not 
remember another protocol that imposes restriction on position of a TLV in a 
TLV-based PDU. If/when fast (e.g., HW-based) parsing of PDUs is required, a 
fixed position method is used (as., e.g., in BFD).

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 17 Aug 2009 08:23:19 +0300

Adrian,
Lots of thanks for a prompt response.

I will look up the RSVP-TE examples. However, I am not sure that the analogy is complete since in the ACH case semantics of the Protocol ID TLV is not affected by the other TLVs.

I also seem to remember that some protocols use NULL TLV to indicate the end of all TLVs. This may be not so uncommon, but surely is very much different from the what the draft now proposes.

Of course as long as the Protocol ID TLV is the only TLV in the ACH, arguing about its position is not very interesting. But the presumed convenience of adjacency will, IMHO, evaporate once the location of the last TLV (and the message itself) requires some parsing.

Could you (or possibly the MEAD participant that made this proposal) explain more about worthiness of this proposal?

Regards,
     Sasha

________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Monday, August 17, 2009 4:04 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-04.txt

Hi Sasha,

Cheers,
Adrian

----- Original Message -----
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 16, 2009 3:11 PM:

Ben, Adrian  and all,

Regards,
     Sasha

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Aug 2009 12:36:22 +0100

> Could you (or possibly the MEAD participant that made this proposal)
> explain more about worthiness of this proposal?

I'm only the editor :-(

I think the logic goes...

- It is useful to have a PID TLV for other G-ACh cases
  (hence the TLV exists in draft-bryant-mpls-tp-ach-tlv-02.txt)

- We need the PID in the DCN G-ACh message
  (so we should consider using the TLV)

- Some people consider that parsing the message in hardware to
  find the PID TLV may be onerous
  (so suggest putting the TLV in a well-known place - this might
   appear to suggest putting it first)

- Some people feel that it would be helpful to be able to pass around
  the DCN message along with its PID without passing around the
  whole G-ACh message
  (this suggests making the PID the byte immediately before the
   DCN message)

- It appears that we only have one TLV in a DCN message
  (so all questions of TLV ordering are moot)

> I also seem to remember that some protocols use NULL TLV to
> indicate the end of all TLVs. This may be not so uncommon, but
> surely is very much different from the what the draft now proposes.

Agreed. In our case (RFC 5586) the TLV sequence is prefixed by the ACH TLV 
header that lets us know the full length of the TLVs present. This means 
that knowing you're at the end of the TLVs is easy.

> Of course as long as the Protocol ID TLV is the only TLV
> in the ACH, arguing about its position is not very interesting.

Right. And that's where we are at the moment.

> But the presumed convenience of adjacency will, IMHO, evaporate
> once the location of the last TLV (and the message itself) requires
> some parsing.

You can get there pretty fast...
- Read the ACH header (known format)
  Channel type tells you that the ACH TLV MUST be present
- Read the ACH TLV header (known format)
- Step over "Length" bytes as indicated in the ACH TLV header
- Back-up two bytes and read the PID
Alternatively
- Back up 6 bytes and read the whole PID TLV

Beyond this, I don't think I can help.
Perhaps some of the MEAD team who wanted this change can step in?

Cheers,
Adrian

----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 17, 2009 6:23 AM
Subject: RE: [mpls-tp] Fw: I-D Action:draft-ietf-mpls-tp-gach-dcn-04.txt

Adrian,

I will look up the RSVP-TE examples. However, I am not sure that the analogy 
is complete since in the ACH case semantics of the Protocol ID TLV is not 
affected by the other TLVs.

I also seem to remember that some protocols use NULL TLV to indicate the end 
of all TLVs. This may be not so uncommon, but surely is very much different 
from the what the draft now proposes.

Of course as long as the Protocol ID TLV is the only TLV in the ACH, arguing 
about its position is not very interesting. But the presumed convenience of 
adjacency will, IMHO, evaporate once the location of the last TLV (and the 
message itself) requires some parsing.

Could you (or possibly the MEAD participant that made this proposal) explain 
more about worthiness of this proposal?

Regards,
     Sasha

Hi Sasha,

Cheers,
Adrian

----- Original Message -----
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 16, 2009 3:11 PM:

Ben, Adrian  and all,

Regards,
     Sasha

---

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

Hi Ben,

> My comments:

Thanks!

> sufficient to build a DCN between those two nodes.

Yes.
I have added a paragraph to the Applicability section (section 3) on this.
But I would note that we do not have any mechanisms to negotiate what use 
will be made of a G-ACh. Therefore, a sender may send anything on any G-ACh 
and the receiver must sort it out.

> Section 1.1:
> None of the requirements listed have capitalised MUSTs/SHALLs/etc.
> Is this intentional?

Yes. 2119 was not really designed for requirements specifications (hence the 
convoluted "although this document is not a protocol specification..." used 
in draft-ietf-mpls-tp-requirements). Since this I-D *is* a protocol 
specification we have used normal language for the requirements, and 2119 
for the protocol procedures.

> S/has been identified/have been identified/

Good point, but wrong fix :-)

"No other ACH TLV has been identified"

>     the PID field of the TLV is immediately adjacent to the message

Yes

> S/iteslf/itself/

Yes

> packet and do not mean deliver the whole MPLS-TP packet?

This is what I was asked to do :-(

I think the logic might be that the processing entity still needs to know 
what the payload protocol is. And if there were other TLVs, they would be 
useful to the processing entity as well.

In other words, the hardware simply determines that the whole buffer needs 
to be dumped to the control plane, but doesn't have to do much more.

> What is the rationale for explicitly not allowing forwarding using the 

I think there are two motivations (as well as "I was only obeying orders"):

- It is the only way to reduce the usage of the DCN for carrying user data.
  This is not a good motivation because it does not reduce the likelihood of
  user data being on the DCN. It simply reduces the chance of congestion.

- It is a consequence of the hoops we are going through to satisfy the "no 
IP
   present" requirements.

I'd be happy to alow fast path forwarding of IP in the DCN. Personally 
(having built a few transport network control planes in my time) I think 
this is very sensible.

Any suggestions for MAY/SHOULD language?

> Also s/rehect/reject/

Thanks

> Section 2.1, paragraph 1, s/singaling/signaling/

Yes

> Section 3, paragraph 1, s/intented/intended/

Yes

Many thanks,
Adrian

---

From: Francesco Fondelli <[email-masked]>
Date: Wed, 26 Aug 2009 19:29:28 +0200

On Tue, Aug 25, 2009 at 1:56 PM, Adrian Farrel<[email-masked]> wrote:
[cut]
>>  entire packet including the MCC/SCC message to the appropriate
[cut]
> to be dumped to the control plane, but doesn't have to do much more.

One can design/program the HW to deliver data on the base
of MCC/SCC message info to different internal network
devices (for example).  Thus, control plane processing entities
can implicitly infer MCC/SCC info (on the base of the internal
device they received data from) without consume precious CPU
cycles.  This approach saves internal bandwidth too.

Both the "pass the whole buffer to the control plane as soon as you
understand it is not a HW business" approach or the one described
above or any other approach is fine.  The point, IMHO, is that that
"SHALL deliver" is not verifiable by an external observer.  Thus it
is probably pointless.

[cut]
>>  the fast path. The node SHOULD apply layer 3 forwarding procedures

Ditto for this "MUST NOT forward".  How can you determine if
my box is compliant?  How can you enforce it?  I understand the
req and even the motivations, but I believe the real intention
was "please don't specify a protocol solution that implicitly
works only if I have a fast IP forwarding path".  That sentence
(i.e. "MUST NOT forward the packet in the fast path") (virtually)
disallow the opposite.  At least this is my understating.

[cut]
> Adrian

Ciao
FF

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Aug 2009 19:10:24 +0100

Francesco,

> The point, IMHO, is that that

Good point, well made.

> disallow the opposite.  At least this is my understating.

I agree here, too.

I think the authors were trying to accommodate the "must work in the absence 
of an IP forwarding plane" and "must not use the DCN to carry user data 
traffic."

The former got qualified by its proponents to mean "no fast IP forwarding 
path" while the latter is clearly an implementation detail where you would 
be ill advised to put user data in the DCN (but I bet the emergency planning 
people would say better to use the DCN than not deliver the packet :-).

I think both of these points can be reworked.

Thanks,
Adrian