Subject: Re: draft-ietf-pwe3-control-protocol-08.txt - partial last call

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 28 Jul 2004 16:07:35 -0400

Luca,
below are my comments on the latest revision of this draft. I took
the liberty to also provide comments on sections other than those
listed below. I believe the proposed changes are minor.

Regards,
Mustapha.
-------------------------------------------------------------------------
1. Section 4: remove details of OAM behaviour for each PW type,
e.g., the whole section 4.2.4.1, section 4.2.5, and some text in
section 4.3. The latter are covered in great details in
draft-ietf-pwe3-oam-msg-map-00.txt. This section should only
summarize the encapsulation for each PW type.

2. Section 4.6: remove last sentence. The PW control word may be
required for the purpose of proper operation of inband PW OAM in a
ECMP network. There is now a draft which puts together the
encapsulation details for a IP PW,
http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt.

3. Section 5.1: add a forward reference to Section 5.4 at the end of
the section where the Interface Parameter field is defined. 

4. Section 5.2: suggest to rename the title, and other occurences
troughout the document, to "Generalized PW ID FEC ELEMENT".

5. Section 5.2.1: 5th paragraph states that the construction of the
AGI and AII fields is application specific. What if two applications
running on the same pair of PEs end up using the same contruction
rules? Is the only way to prevent this from happening to encourage
specific applications to request a codepoint type field from IANA?

6. Section 5.2.2: please provide a definition for the "PW info
Length" field. If it does include the AGI/SAII/TAAI fields, then the
minimum size of this will be 6 octets since the AGI, SAII, and TAAI
type and length are always included when their length is zero.

7. Section 5.2.2.2: add the following sentence in the beginning of
the section: "This TLV MUST only be used when sending the
Generalized PW ID FEC.". 

8. Section 5.2.2.2: the third paragraph describing the wildcard
command is contradictory to the text in the last praragraph of
Section 5.3.2. The former states that the "PW info Length" field
must be set to zero and the AGI/SAII/TAII fields should not be
included in the PW FEC element. The latter states that the
AGI/SAII/TAII fields should be included but have their length field
set to zero. This means that the "PW info Length" should be set to 6
octets.
I propose we keep the latter behaviour which is consistent with the
procedure described in 5.2.2 of always including the AGI, SAII, and
TAII fields and zeroing the length of those identifiers which are
not used by an application.

9. Sections 5.4.1 and 5.4.2 should be moved to a separate section
titled "Handling of Control Word".

10. Section 5.4.3 should be removed as it is redundant with 6.4 and
6.5.

11. Section 5.5: this is specific to the PW ID FEC and should be
moved into Section 5.1 under the description of the Group ID field. 

12. Appendix B: can we remove this and fold the details into the
second diagram in Section 5.3.2?
-------------------------------------------------------------------------
Stewart Bryant wrote:
> 
> This is the start of last call for sections 5.2, 5.3,  and 7 of
> 
> Pseudowire Setup and Maintenance using LDP
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-08.txt
> 
> Last call will end Monday 9th August 2004
> 
> - Stewart
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Wed, 28 Jul 2004 15:56:01 -0600

>listed below. I believe the proposed changes are minor.
not in last call - cannot change it. ( besides I do not want this 
document to depend on the msg mapping one. )

>http://pwe3.tcb.net/draft-balus-pwe3-ip-pseudowire-00.txt.
not in last call - cannot change it. ( The current design has been final 
for a long time. )
Also there is no encapsulation document describing this application. The 
encapsulation is in RFC3032, and there is no mention of control word there.

>the section where the Interface Parameter field is defined. 
??? I'm not sure this is necessary , The index clearly states which page 
section 5.4 is ....

>troughout the document, to "Generalized PW ID FEC ELEMENT".
Ok, Changed.

>specific applications to request a codepoint type field from IANA?
Yes.  I believe that we need another separate document to actually bite 
the bullet and specify these fields.

>type and length are always included when their length is zero.
Yes, for some reason this text got dropped in one of the revisions :

The PW information length field, contains the length of the SAII, TAII, 
AGI  combined, and the interface parameters field in octets. If this 
value is 0, then it references all PWs using the specified grouping ID. 
In this case there are no other FEC element fields (AGI,SAII, etc. ) 
present, nor any  interface 
parameters.                                                      

I will add it back. I 'm not sure we need to mention then the minimum is 
6 , since that is implied.

>the section: "This TLV MUST only be used when sending the
Yes,  that is definitely the intention. I had to change the MUST to MAY 
, as we do not want to make the TLV required , we just want to say it 
MAY only be used with the generalized FEC.

>not used by an application.
Actually the intention was to use the former behavior to be the same as 
the PWID FEC.
This text was written at a different time when the pw info field was 
removed for a short time.
Unless you have a strong objection I made the text consistent, with no 
AGI/SAII/TAII present in the wild card withdraw message.

>titled "Handling of Control Word".
you want me to renumber them ?  Yes I will create a section for these.

>10. Section 5.4.3 should be removed as it is redundant with 6.4 and
Haa yes ... Eric ;-) added these to comply with the latest ID 
requirements. ( He evidently missed the existing section above )
Fixed.

>moved into Section 5.1 under the description of the Group ID field. 
Actually I think that this section is  missing a mention of the grouping 
TLV in the first paragraph.
The second paragraph is already  "interface parameter TLV aware "
I fixed the hole section to apply to both FECs as intended.

>second diagram in Section 5.3.2?
Actually the reason this is in the appendix is that it is too specific 
to be used in section 5.3.2 . Yet  I wanted to make sure there is no 
misunderstanding about the TLV encoding, so I picked a specific example 
and put it in the appendix.
If this is really a problem we can delete it , but I would like to leave 
it as it can be useful.

Thanks!
Luca

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 29 Jul 2004 13:18:37 -0400

Luca,

> document to depend on the msg mapping one. )

MA> I am suggesting not to make any reference to OAM behaviour or
OAM draft in this document. Each encapsulation draft has some text
on OAM and the details are in draft-ietf-pwe3-oam-msg-map-00.txt. I
would prefer that we do not have many documents with inconsistent
procedures.
 
> encapsulation is in RFC3032, and there is no mention of control word there.

MA> I understand your concern but I am still uncomfortable with
this. I rather have the option to signal it than not to. Maybe, the
last sentence should be the default behavior instead of the only
behavior. 
 
> 6 , since that is implied.

MA> OK. 
 
> AGI/SAII/TAII present in the wild card withdraw message.

MA> I am OK with this proposal. Thus, you are going to correct the
text in Section 5.3.2 in the case of the wildcard status message to
state that AGI/SAII/TAII must not be included.
 
> you want me to renumber them ?  Yes I will create a section for these.

MA> Yes. They are currently sitting in Section 5.4 "Interface
Parameter Field" :-)
 
> If this is really a problem we can delete it , but I would like to leave

MA> What is so specific about the diagram in Appendix B that makes
it an example? Besides, I think there is an extra field "PWID FEC"
which should be removed (probably left from an older revision which
did not include the GID FEC).