Subject: [Gen-art] Gen-Art Review: draft-ietf-pwe3-satop-03.txt

From: Elwyn Davies <[email-masked]>
Date: Mon, 12 Dec 2005 12:02:42 +0000

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary:
This is a re-review of an updated version of this document which I
previously reviewed for IETF LC back in September 2005.

Almost all of my previous concerns have been addressed by this version
and it is almost ready for PS.

Details:
One remaining minor concern: The authors and I discussed the meaning of
'stray packets' in s6.3 since I was unclear what was meant by the term
in this context. The dialogue was:

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

> s6.3: I have no idea what a stray packet is or how I would 
> detect one!  
> The previous section talks about lost packets, so presumably 
> we are not talking about these, but I thought astray usually 
> might mean misrouted in which case the packet would never 
> arrive and can only be detected as lost.  Does it mean 
> 'excessively misordered'?  I am not sure what role the sync 
> source plays in this.

A stray packet is a packet that would normally not
reach the end-point, but did so anyway. For example,
consider one SAToP PW being torn down and a new one
over-expeditiously set up using the same PW label.
Late packets from the old PW could be erroneously perceived
as the packets of the new one, but could be detected when the
optional RTP header is used by observing the SSRC value.

-------

This explanation didn't (fully) make it into the update and I think it would 
help.  This may also be tied into the comment on 'misconnection' in the Security 
Considerations (s9)?

References:
PWE3-ARCH, PWE3-IANA, PWE3-TDM-CONTROL and PWE3-VCCV are normative IMO as the 
protocol cannot be implemented without knowledge of these items.

RFC1122 and RFC3551 aren't referenced.

[RFC2112] s/b [RFC2212]

Arguably RFC2212, RFC2914 and RFC3086 are informative, since they aren't needed 
to implement the protocol.

Editorial:

There are still a number of unexpanded acronyms in the document (MTU, L2TPv3, 
QoS, PDB leapt out at me).

The terms PSN-bound and CE-bound are not defined.

L2TPv3 could do with a reference.

s4.3: s/smoothless/seamless/ maybe???  Smoothless is in interesting new word!

s6.3, para 3rd from end: s/amount of times/amount of time/

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Dec 2005 13:42:23 +0100

That glitch with the reference is a (minor) DISCUSS
I'm afraid.

I've switched to the correct gen-art list address so that
the rest of this thread will be archived.

    Brian

Stewart Bryant wrote:
> Elwyn Davies wrote:
> 
>>
>>
>> Stewart Bryant wrote:
>>
>>> Some points about normative references:
>>>
>>>>
>>>>
>>>> References:
>>>> PWE3-ARCH, PWE3-IANA, PWE3-TDM-CONTROL and PWE3-VCCV are normative 
>>>> IMO as the protocol cannot be implemented without knowledge of these 
>>>> items.
>>>>
>>>>
>>> PWE3-ARCH = RFC3985 is only informational so I do think that it can
>>> be normative in a stds track RFC. RFC3985 should not contain anything 
>>> that this
>>> RFC should regard as normative - is there any text that you have in mind
>>> as being a normative dependency?
>>
>>
>>
>> Oh, dear!  Real problem, wrong solution! This is actually something I 
>> spotted previously and didn't get fixed in this version of the draft.  
>> The text in s4.3 would create a normative ref but the s5.4.4 isn't in 
>> RFC3985 any more!  From my previous comments:
>>
>> s4.3: s5.4.4 of RFC3985 does not exist.  Archaeology suggests that it 
>> was removed between the -06 (final) version of the draft and the RFC 
>> publication.  I take it the ref should either be to 
>> draft-bryant-mcpherson-pwe3-cw-00.txt or draft-ietf-pwe3-cw-05.txt, 
>> but this latter explicitly applies to MPLS control words.
>>
>> There SHOULD be a normative reference to one or more of these! In 
>> which case the architecture is indeed informative.
>>
> OK - I see what has happened.
> 
> The reference needs to be to
> 
> draft-ietf-pwe3-cw-06.txt
> which is in the RFC editor's queue. Although draft specifies the CW for
> an MPLS PSN, the author of the TDM drafts elected to use it for all
> PSN types.
> 
> Note that the earlier reference to s5.4.3 of RFC3985 (use of labels for
> mutiplexing need to remain, but I think is informative, since SAToP says 
> how to to the multiplexing.
> 
>>>
>>> PWE3-IANA creates a number of registries that this draft uses, it the 
>>> registries
>>> that are really normative - not the RFC. The draft is in the 
>>> RFC-editor's queue
>>> and we have asked IANA to expedite the registry creation.
>>
>>
>>
>> An interesting question:  The IANA draft creates the registry 
>> maintenance mechanisms which are normally in a PS.  Ask your AD for 
>> advice!
>>
>>>
>>> PWE3-TDM-CONTROL  is new work. A SAToP PW can be setup by manual
>>> configuration and that is the way SAToP PWs are currently deployed.
>>
>>
>>
>> You are right - the normative link is in the other direction only.
>>
> No, were right and I was wrong
> 
> The following text needs to be changed to make it clear that manual 
> config is called
> up here, and PWE3-TDM-CONTROL is workin progress.
> 
> "Usage of the fixed RTP header in a SAToP PW and all the options 
> associated with its usage (the time-stamping clock frequency, the time-
> stamping mode, selected PT and SSRC values) MUST be agreed upon between 
> the two SAToP IWFs at the PW setup as described in [PWE3-TDM-CONTROL]. 
> Other, RTP-specific, methods (e.g., see [RFC 3551]) MUST NOT be used."
> 
>>>
>>> PWE3-VCCV is not normative in any of the encap drafts, because although
>>> an OAM protocol is useful, it is not essential - there are many 
>>> deployed PWs that
>>> do not run an OAM. What is essential is that the SAToP design is such 
>>> that
>>> that VCCV cab run over the PW. That requirement is fulfilled.
>>
>>
>>
>> The last paragraph of s4.3.1 creates a relationship with VCCV which is 
>> at least on the surface normative.
>>
> I see what you mean. We could probably just strike the paragraph. The 
> way that
> VCCV runs over the CW is standard, and does not need to be repeated here.
> 
> Regards
> 
> Stewart
> 
>> Regards,
>> Elwyn
>>
>>>
>>> Regards
>>>
>>> Stewart
>>>
>>
>>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Dec 2005 13:59:01 +0100

Forgot to add: please wait for guidance from Mark about whether
to produce an updated version.

    Brian

---

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Dec 2005 15:48:03 +0100

> maintenance mechanisms which are normally in a PS.  Ask your AD for 

IANA drafts are often in the form of a BCP, as I believe this one will be.

I asked the question about informative vs. normative on the IESG list, 
according to our Chair, an informative reference for an IANA registry is OK.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Dec 2005 10:33:59 +0100

> according to our Chair, an informative reference for an IANA registry is 

Allison then pointed out that there may be cases where an implementor would
really need to read the IANA stuff, so the answer is probably a definite maybe.
But I do think this case is OK. [There is still a DISCUSS but it looks easy.]

    Brian