Subject: [mpls-tp] WG Last Call comments on draft-ietf-mpls-tp-framework-10

From: <[email-masked]>
Date: Thu, 4 Feb 2010 22:59:21 +0000

Loa, Authors,

Below are my WG LC comments on draft-ietf-mpls-tp-framework-10

Section 1.3.4:

   5.  Is either point-to-point or point-to-multipoint.  Multipoint to
       point and multipoint to multipoint LSPs are not permitted.

You should be consistent with your use of hyphenation, i.e. if you hyphenate point-to-point and point--to-multipoint you should also hyphenate multipoint-to-       point and multipoint-to-multipoint.

Section 1.4:

I think it would be easier to read if the figures followed the text that referred to them rather than it being all text followed by 3 back to back figures.

Section 3.4.1 first paragraph last sentence: s/can only/can be only/

Also you should be consistent in your use of S-Bit/S Bit throughout the document as for example it is used inconsistenly in section 3.4.1

The paragraph immediately following Figure 5 appears to be practically identical to the paragraph immediate preceding Figure 5. Suggest you remove the paragraph immediately following Figure 5.

Figure 10 appears out of nowhere ;-). Suggest moving the 2nd paragraph immediately following Figure 10 to immediately precede the figure.

Section 3.6 paragraph 4, what does the following mean?

   The only other circumstance under which the label stack
   may be inspected for a GAL is when the TTL has expired.  Any MPLS-TP
   component that intentionally performs this inspection must assume
   that it is asynchronous with respect to the forwarding of other
   packets.

Is it trying to say that TTL expiry may cause a MPLS-TP packet to be taken out of the fast path?

The way it reads implies to me it is something quite important (e.g. may not be obvious to ITU folks) so it may be worth making the sentence more prominent/explicit.

Section 3.7 states part way through:

   Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
   layer processing is performed on a packet.  The architecture mandates
   that this must occur at least once.

I have no idea what the second sentence means!

Section 3.8 and 3.8.1.

Why use example node names B, A & Y in Section 3.8 and 3.8.2 and example node names D and U (which correspond to B & A respectively) in Section 3.8.1.

Also in section 3.8 a picture speaks a thousand words, maybe worth considering including a simple one showing the relationship between A, B & Y, e.g.

   A=====Y=====B

  ---> Direction of packet flow.

Section 3.8.2 Case 2 & 3.
I am not sure the insertion of traffic by an intermediate node of an MPLS-TP LSP so that the egress MPLS-TP node can route the packet back to the ingress MPLS-TP node is really a valid use case as wouldn't you be merging traffic for the return path with the original client traffic of the MPLS-TP LSP you are piggybacking on?

Section 3.12 3rd bullet: s/resources or which/resources of which/

Remove section 7 as the document is in last call ;-)

The formatting of your references sections is a bit screwy!

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Feb 2010 00:00:40 -0000

Hi Ben,

> The way it reads implies to me it is something quite important (e.g. may 
> not be
> obvious to ITU folks) so it may be worth making the sentence more 
> prominent/explicit.

Good catch!

I think that the component performing this function will know exactly 
whether it is performing it synchronously of asynchronously with respect to 
forwarding other packets. It does not need to make any assumptions and can 
make an implementaiton choice.

What it *might* be reasonable to say is that any *process* dependent on this 
function cannot assume that the inspection will happen synchronously with 
respect to the forwarding of other packets at the inspecting node. [Note the 
reversal of assumption since to assume asynchronicity is somewhat 
unbounded!]

And I agree that it would be worth teasing out the consequence of this 
non-assumption which is, I assume, that by the time the GAL has been found, 
other packets (received later) may have already been forwarded.

But note that the reason that I say *might* in the paragraph above is 
because it does not seem ridiculously hard to inspect TTL and check for GAL 
in one operation.

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 5 Feb 2010 09:35:55 +0200

Adrian, Ben and all,
I concur with Adrian regarding his "good catch" comment on Ben's comment.
However, I think that, from the point of view of interoperability, "cannot assume" 
in Adrian's version should be replaced with "MUST NOT assume". The TTL check is part of the MPLS 
(and hence MPLS-TP) data plane; and the standards defining this data plane do not require any 
additional checks once the TTL check fails. 

Of course, this does not prevent people from implementing non-standard extensions to the
MPLS data plane; but such extensions cannot be used as the basis for standardized behavior
in MPLS-TP.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adrian Farrel [[email-masked]]
Sent: Friday, February 05, 2010 2:00 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] WG Last Call comments on draft-ietf-mpls-tp-framework-10

Hi Ben,

Good catch!

Cheers,
Adrian

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 05 Feb 2010 08:56:56 +0000

Adrian Farrel wrote:
>> The way it reads implies to me it is something quite important (e.g. 
>> may not be
> whether it is performing it synchronously of asynchronously with 
> respect to forwarding other packets. It does not need to make any 
> assumptions and can make an implementaiton choice.
>
> What it *might* be reasonable to say is that any *process* dependent 
> on this function cannot assume that the inspection will happen 
> synchronously with respect to the forwarding of other packets at the 
> inspecting node. [Note the reversal of assumption since to assume 
> asynchronicity is somewhat unbounded!]
That was the warning we were trying to raise.
> non-assumption which is, I assume, that by the time the GAL has been 
> found, other packets (received later) may have already been forwarded.
>
> because it does not seem ridiculously hard to inspect TTL and check 
> for GAL in one operation.
I have never seen anything in either the MPLS architecture or indeed the 
IP architecture that MPLS inherits that suggests any synchronous 
operation associated with TTL expiry. Once you get a TTL exception the 
packet is withdrawn from the forwarding path, and it is up to the 
implementation how it continues with the disposal of the packet.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 05 Feb 2010 09:00:16 +0000

> additional checks once the TTL check fails. 
Exactly - hence the caution we were raising.
> MPLS data plane; but such extensions cannot be used as the basis for standardized behavior
I agree and I would expect to see strong push back if we ever suggested 
such a change in an RFC.

- Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Feb 2010 12:06:32 -0000

Sasha,

It's a framework. Why does it have RFC 2119 language in it?

We can have "must not" which is semantically no so far removed from 
"cannot". But "MUST NOT" would be out of order.

> I agree and I would expect to see strong push back if we ever suggested 

If there were to be found a radical benefit for synchronous processing, one 
could imagine a capabilities exchange that would enable nodes to know 
whether other nodes did or did not do synchronous processing. But I agree, 
that is for the future.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Feb 2010 12:12:08 -0000

Hi Stewart,

>> whether it is performing it synchronously of asynchronously with respect 
>> to forwarding other packets. It does not need to make any assumptions and 
>> can make an implementaiton choice.
>>
>> What it *might* be reasonable to say is that any *process* dependent on 
>> this function cannot assume that the inspection will happen synchronously 
>> with respect to the forwarding of other packets at the inspecting node. 
>> [Note the reversal of assumption since to assume asynchronicity is 
>> somewhat unbounded!]
>

Excellent! Then maybe some text tweaking?

>> because it does not seem ridiculously hard to inspect TTL and check for 
>> GAL in one operation.
>
> IP architecture that MPLS inherits that suggests any synchronous operation 
> associated with TTL expiry. Once you get a TTL exception the packet is 
> withdrawn from the forwarding path, and it is up to the implementation how 
> it continues with the disposal of the packet.

You are right.

And this does not say that the architecture *requires* that the only 
processing done in hardware is TTL checking. Since OAM is often implemented 
in hardware and since the OAM message hides behind TTL expiry, an 
implementation would be within its rights to do a little more than check the 
TTL in one bite of hardware processing.

So my point is (and see email to Sasha) that if (in the future) we discover 
some benefit to synchronous OAM processing and if we are able to determine 
that a set of nodes can perform such processing, then we should be able to 
leverage it.

I don't think this changes anything written in this draft. In particular: 
"cannot / must not assume" cover it very nicely, since the word "assume" can 
be countermanded by specific knowledge.

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 5 Feb 2010 20:08:06 +0200

Adrian, and all,
I've done some statistics on RFC that contain "Architecture" or Framework" in their titles.

Architecture: 104 RFCs, 24 on the standard track, 2 BCP, 3 Experimental, 
quite a few have been published on the Standard track and then re-classified
as Historical or Informational.

Framework: 82 RFCs, 15 on the Standard Track, 1 BCP, 2 experimental.

(I have counted "An Architecture for Describing Simple Network Management Protocol
(SNMP) Management Frameworks" under "Architecture". There are 4 documents with this 
name, and the most recent one has been published as STD 0062.)

Hence several questions dealing mainly with the process:

1. Do we plan to develop a Standard Track "MPLS-TP Architecture" document?
    (If we do, then the recent draft on the data plane architecture should be incorporated 
     into it, IMHO.)

2. Why do we target the current MPLS-TP Framework document  as Informational?
     (If we plan a Standard Track Architecture document, this question is not relevant).

3. Is 2119 language specifically disallowed in Informational documents? In Framework documents?
    (As for the first half of this double-barreled question, I can point to 4197, 5086 and 5087 which 
   all contain this language  in spite of being published as Informational. So even if a rule prohibiting 
   usage of 2119 language in Informational documents exists, it seems to be more honor'd in the breach 
   than the observance.)

Regards, 
     Sasha
________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Friday, February 05, 2010 2:06 PM
To: [email-masked]; Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] WG Last Call comments    on      draft-ietf-mpls-tp-framework-10

Sasha,

Cheers,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Tue, 09 Feb 2010 09:56:05 -0500

Adrian/Stewart,
	One point I've been grappling with on this topic is where does this
topic belong.  Given that we now have draft-fbb-mpls-tp-data-plane, it
seems to me that much of this discussion could now be moved from the
framework document to section 4 of draft-fbb.  I'll discuss further with
the authors...

Lou

On 2/5/2010 7:12 AM, Adrian Farrel wrote:
> mpls-tp mailing list