Danny McPherson | 1 Feb 2008 23:13
Favicon

Fwd: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA

	
FYI...

Begin forwarded message:

> From: ietf-secretariat <at> ietf.org
> Date: February 1, 2008 11:36:56 AM MST
> To: ietf-announce <at> ietf.org
> Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF   
> Meeting in Philadelphia, PA, USA
>
> There are two (2) Internet-Draft cutoff dates for the 71st
> IETF Meeting in Philadelphia, PA, USA:
>
> February 18th: Cutoff Date for Initial (i.e., version -00)
> Internet-Draft Submissions
>
> All initial Internet-Drafts (version -00) must be submitted by Monday,
> February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for
> version -00 WG drafts that replace existing non-WG drafts.  Such  
> drafts
> may be submitted until the cutoff date for version -01 and higher
> drafts.
> As always, all initial submissions with a filename beginning with
> "draft-ietf" must be approved by the appropriate WG Chair before they
> can be processed or announced.  The Secretariat would appreciate
> receiving WG Chair approval by Monday, February 11th at 9:00 AM ET  
> (14:00 UTC/GMT).
>
> February  (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version  
(Continue reading)

Chad McCarthy | 3 Feb 2008 19:17
Picon
Favicon

Clarification on L/M bits

The following question is regarding the L/M bit description outlined within RFC5086. When the M bit is set to "10", must we play out "as received"? It seems like the obvious answer is Yes, considering the following entry in "Table 1. Interpretation of bits L and M in the CESoPSN CW":  | 0 | 10  | CESoPSN data packet, RDI condition of the AC.  All    |

  |   |     | CESoPSN implementations MUST support this codepoint:  |

  |   |     | payload MUST be played out "as received", and, if      |

  |   |     | so configured, the receiving CESoPSN IWF instance     |

  |   |     | SHOULD be able to command the NSP to force the RDI    |

  |   |     | condition on the outgoing TDM trunk.                  |

 But, later on in section "6.2. IWF Operation" , it doesn't list play out as received as an option, unless it's covered under "None". Is this the case? 6.2. IWF OperationIf the data packets received are marked with L bit cleared and M bits set to '10' or with R bit set, the CE-bound CESoPSN IWF will be locally configured to command its local NSP to perform one of the following  o  None (MUST be supported by all the implementations)   o  Transmit the RAI pattern towards the local CE on the E1 or actions:

T1

      trunk carrying the local attachment circuit (support of this

      action is RECOMMENDED)

 

   o  Send the "Channel Idle" signal to the local CE for all the DS0

      channels comprising the local attachment circuit (support of this

      action is OPTIONAL and requires also that the CE-bound CES IWF

      replaces the actually received payload with the equivalent amount

      of the locally configured "idle" bit pattern.

 
Thanks in advance,Chad 


_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
http://www.ietf.org/mailman/listinfo/pwe3
Alexander Vainshtein | 3 Feb 2008 20:23

Re: Clarification on L/M bits

Hi Chad,
Please see answers inline below.
 
Regards,
               Sasha Vainshtein

From: pwe3-bounces <at> ietf.org on behalf of Chad McCarthy
Sent: Sun 2/3/2008 8:17 PM
To: pwe3 <at> ietf.org
Subject: [PWE3] Clarification on L/M bits

The following question is regarding the L/M bit description outlined within RFC5086. When the M bit is set to "10", must we play out "as received"? It seems like the obvious answer is Yes, considering the following entry in "Table 1. Interpretation of bits L and M in the CESoPSN CW":  | 0 | 10  | CESoPSN data packet, RDI condition of the AC.  All    |  |   |     | CESoPSN implementations MUST support this codepoint:  |  |   |     | payload MUST be played out "as received", and, if      |  |   |     | so configured, the receiving CESoPSN IWF instance     |  |   |     | SHOULD be able to command the NSP to force the RDI    |  |   |     | condition on the outgoing TDM trunk.                  | But, later on in section "6.2. IWF Operation" , it doesn't list play out as received as an option, unless it's covered under "None". Is this the case?[Sasha] Yes, this is the case. I.e., L=0 and M=01 usually results in playout ofvalid payload. On top of that, it is possible (if the IWF has been so configured) to transmit RAI towards the local CE (note that RAI is a certain pattern in the framing, not in the payload.)6.2. IWF OperationIf the data packets received are marked with L bit cleared and M bits set to '10' or with R bit set, the CE-bound CESoPSN IWF will be locally configured to command its local NSP to perform one of the following  o  None (MUST be supported by all the implementations)   o  Transmit the RAI pattern towards the local CE on the E1 or actions:T1      trunk carrying the local attachment circuit (support of this      action is RECOMMENDED)    o  Send the "Channel Idle" signal to the local CE for all the DS0      channels comprising the local attachment circuit (support of this      action is OPTIONAL and requires also that the CE-bound CES IWF      replaces the actually received payload with the equivalent amount      of the locally configured "idle" bit pattern. Thanks in advance,Chad 
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
http://www.ietf.org/mailman/listinfo/pwe3
Raman Rangaswamy | 4 Feb 2008 12:47
Picon
Favicon

PW OAM Mapping context: Is VCCV-Ping will always be in no reply mode.?

Hi,

 

Can I assume from the below PW OAM message mapping draft section that,

“For PW fault detection, VCCV-Ping will always be in no reply mode, running periodically”           

 

Draft:

Pseudo Wire (PW) OAM Message Mapping

draft-ietf-pwe3-oam-msg-map-05.txt

 

Draft Section:

6.1 PW Forward Defect Entry/Exit

- It detects a loss of PW connectivity, including label errors,

       through VCCV-BFD or VCCV-PING in no reply mode.

 

Thanks,

Raman R

 

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
http://www.ietf.org/mailman/listinfo/pwe3
Picon
Favicon

Can we use VCCV-BFD Diagnostic code when the session is UP ?

Hi,

 

  As per my understanding of draft-ietf-bfd-base-07

  Diagnostic code should be used only when the BFD session goes to Down or Admin Down.

  “A diagnostic code specifying the local system's reason for the

  last session state change to states Down or AdminDown.”

 

  But as per draft-ietf-pwe3-oam-msg-map-04 status codes 6 & 8 can be used to signal AC fault.

  In this case VCCV-BFD session state is UP.

 

  Does it mean thatdiagnostic code” can be used even when bfd state is “up”?

 

 

 

 

Regards,

Damodharan.S

 

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------
_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
http://www.ietf.org/mailman/listinfo/pwe3
Georges Sebek | 5 Feb 2008 19:48
Favicon

New Liaison Statement, "Endorsement of selection of option 1 agreed in Stuttgart meeting"


Title: Endorsement of selection of option 1 agreed in Stuttgart meeting
Submission Date: 2008-02-05
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=416 
Please reply by 2008-09-01

From: Georges Sebek(ITU-T SG 13) <tsbsg13 <at> itu.int>
To: IETF IESG, IAB, PWE3 WG, MPLS WG, routing and internet Area Directors(iab-chair <at> iab.org,
chair <at> ietf.org, jari.arkko <at> piuha.net, townsley <at> cisco.com, rcallon <at> juniper.net,
dward <at> cisco.com, swallow <at> cisco.com, loa <at> pi.se, danny <at> arbor.net, stbryant <at> cisco.com)
Cc: iab <at> iab.org
iesg <at> ietf.org
pwe3 <at> ietf.org
mpls <at> lists.ietf.org
Reponse Contact: sebek <at> itu.int
tsbsg13 <at> itu.int
hhelvoort <at> huawei.com
Technical Contact: hhelvoort <at> huawei.com
Purpose: For action 
Body: 
Attachment(s):
     Endorsement of selection of option 1 agreed in Stuttgart meeting (https://datatracker.ietf.org/documents/LIAISON/file523.pdf)
Georges Sebek | 5 Feb 2008 20:45
Favicon

New Liaison Statement, "Status of T-MPLS OAM and label 14"


Title: Status of T-MPLS OAM and label 14
Submission Date: 2008-02-05
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=420 

From: Georges Sebek(ITU-T SG 13) <tsbsg13 <at> itu.int>
To: IETF PWE3 and MPLS WG(danny <at> arbor.net, stbryant <at> cisco.com, swallow <at> cisco.com, loa <at> pi.se)
Cc: rcallon <at> juniper.net
dward <at> cisco.com
jari.arkko <at> piuha.net
townsley <at> cisco.com
sob <at> harvard.edu
pwe3 <at> ietf.org
mpls <at> lists.ietf.org
Reponse Contact: sebek <at> itu.int
tsbsg13 <at> itu.int
hhelvoort <at> huawei.com
Technical Contact: hhelvoort <at> huawei.com
Purpose: For information 
Body: 
Attachment(s):
     Status of T-MPLS OAM and label 14, and attachment (https://datatracker.ietf.org/documents/LIAISON/file527.zip)
Stewart Bryant | 6 Feb 2008 16:53
Picon
Favicon

Proposed response to liaison 406

We were sent this liaison rather late in the day (9th Jan)
an need to get a response back in time for the SG15 meeting
next week. In the meantime there have been a whole bunch 
of higher priority T-MPLS activities that have need priority
hence late response.

I drew the attention of the liaison to Yaakov Stein to review
the TDM material and Luca Martini to review the ATM material
and their commments are included verbatim.

The concerns about the semi-detailed redefinition of existing
texts and corresponding issues of difficulty of presentation
and normative reference conflict are mine. Please indicate
if I should tone this down.

I need to send this out friday evening my time.

Regards

Stewart

Thank you for your liaison of 9th January 2008 entitled 
"Addition of ATM and PDH clients to T-MPLS <https://datatracker.ietf.org/documents/LIAISON/file510.pdf>"

https://datatracker.ietf.org/liaison/406/

This rather short description of the packet processing is more 
difficult to read than the descriptions found in either
the relevant RFCs or the corresponding Y series recommendations
as such we found it difficult to review. Rather than defining
the operations in semi-detail we would prefer that you simply
indicate the primary references and modes that you propose to
support and refer the reader there for the description. This 
prevents any issue of conflicting definitions. In any case 
there needs to be a clear indication that this is a subset
of existing IETF PWE3 and SG13  recommendations 
and that their packet processing definitions are authoritative.

We are concerned that you only propose to use the structure
agnostic TDM mode. This mode has limitations which are 
addressed by  the structure aware modes jointly developed 
in the IETF PWE3 Working Group and ITU-T SG13.

Please can we suggest that you add text explaining that the 
structure-agnostic mode is not always the idea method of TDM
emulation and preferably include text describing the use of
the structure aware modes as described in Y.1413, RFC 5086 
and RFC 5087.

In the case of ATM, please can you be more specific about
the exact type of PW that you intend to support. The 
confusion arises as a result of the text at the end of 
section 7.1.4 of the document which says:

" For the case of Mode 1

   * Cell de-multiplexing according to the VPI value, including
     unmatched VPI cell discard
   * Remove the VPI field"

Since MODE 1 is defined as the N-to-One cell mode of [IETF RFC 4717] ,
this this text appears to be in error, and we believe that you should 
call up
Mode 2.

There are some other items that are unclear in this section. The paper
discusses  N-1 mode but then discusses  multiple VP. Is the mode that you
wish to use what we call cell relay mode PW type 0x0003 ?

Reagrds etc

_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls

Stewart Bryant | 6 Feb 2008 17:18
Picon
Favicon

Re: draft-ietf-pwe3-fc-encap-06.txt Last Call

I would like to start a (hopefully) final last call on the
Fiber Channel draft

http://tools.ietf.org/html/draft-ietf-pwe3-fc-encap-07

As you can see there are a couple of issues that David Black
raises. The first is easily fixed, the second is more
difficult. On the face of it the right thing to do is to
use a new status code, but on the other hand there are
only 31 values available so we need to be suitably
parsimonious.

If we do decide to us a common value with dynamic-ms-pw
I propose to make this the allocating document since
it will get to the IESG first.

Last call will close 29th Feb 2008, so please can
we have any additional comments by then.

Thanks

Stewart

Moran Roth wrote:
> Stewart,
>
> I would suggest to address the small clean-up issues David mentioned as
> part of the WGLC, since this may bring up more such issues.
>
> Thanks,
> Moran
>
> -----Original Message-----
> From: Black_David <at> emc.com [mailto:Black_David <at> emc.com] 
> Sent: Thursday, January 17, 2008 10:16 PM
> To: stbryant <at> cisco.com; pwe3 <at> ietf.org
> Cc: danny <at> tcb.net
> Subject: RE: [PWE3] draft-ietf-pwe3-fc-encap-06.txt Last Call
>
> The -07 version of the FC-PW draft addresses most of the congestion
> control issue around CIR.  There are still a few small things to clean
> up:
>
> (1) A reference needs to be cited for R_A_TOV and a sentence should be
> added to stat that the default value of R_A_TOV is 10 seconds.  R_A_TOV
> is defined in section 20.2.1.4 of FC-FS-2:
>
> [FC-FS-2] "Fibre Channel Framing and Signaling-2 (FC-FS-2)",
> 		ANSI INCITS 424:2007, August 2006.
>
> (2) The PW status of "Bandwidth resources unavailable" is defined by
> draft-ietf-pwe3-dynamic-ms-pw.  This raises a couple of concerns:
> - The dynamic-ms-pw draft defines that PW status for PW
> 	setup failure when the requested bandwidth resources
> 	for the PS aren't available, and hence the PW can't
> 	be created.  That status code is being used here for
> 	loss of bandwidth after the PW is up and running.
> 	I'm not sure whether that's a good idea, vs.
> 	defining a new PW status code.
> - The IANA registration of that PW status code is
> 	temporary because the dynamic-ms-pw draft is still
> 	in the pwe3 WG.  If that PW status is to be re-used,
> 	a normative reference to the dynamic-ms-pw draft
> 	appears to be needed from the FC PW draft.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david <at> emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>   
Stewart Bryant | 6 Feb 2008 18:48
Picon
Favicon

PROTO Statement: draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt

PROTO Statement:  draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt

The PWE3 Chairs would like to request Standards Track publication
of this document.

(1.a)  Who is the Document Shepherd for this document?  Has the
           Document Shepherd personally reviewed this version of the
           document and, in particular, does he or she believe this
           version is ready for forwarding to the IESG for publication?

Stewart Bryant (stbryant <at> cisco.com) is the Shepherd. I have
reviewed the document and it is ready for publication.

    (1.b)  Has the document had adequate review both from key WG members
           and from key non-WG members?  Does the Document Shepherd have
           any concerns about the depth or breadth of the reviews that
           have been performed?

This document (-04 revision) has been reviewed by the WG. A detailed
list of all of this issues and the resolution was presented to the
WG and published as (-05) and a minor editorial was published one
week later (-06) which is the version that we propose to advance.
The proposed advancement of this document was discussed at the last IETF.

I have no concerns about state of readiness of this document, although
it needs a minor edit to change the affiliation of one of the authors
which we can do as an editor's note.

    (1.c)  Does the Document Shepherd have concerns that the document
           needs more review from a particular or broader perspective,
           e.g., security, operational complexity, someone familiar with
           AAA, internationalization or XML?

I have no concerns regarding the requirement for further review.

    (1.d)  Does the Document Shepherd have any specific concerns or
           issues with this document that the Responsible Area Director
           and/or the IESG should be aware of?  For example, perhaps he
           or she is uncomfortable with certain parts of the
document, or
           has concerns whether there really is a need for it.  In any
           event, if the WG has discussed those issues and has indicated
           that it still wishes to advance the document, detail those
           concerns here.

I have no specific concerns about this document, nor are there
concerns that should be conveyed to the IESG or Responsible AD.

    (1.e)  How solid is the WG consensus behind this document?  Does it
           represent the strong concurrence of a few individuals, with
           others being silent, or does the WG as a whole understand and
           agree with it?

This document is fully understood and supported by the PWE3
WG.  There is no contention as to whether this work provides utility
and it is generally supported across the WG.

    (1.f)  Has anyone threatened an appeal or otherwise indicated
extreme
           discontent?  If so, please summarise the areas of conflict in
           separate email messages to the Responsible Area Director.
(It
           should be in a separate email because this questionnaire is
           entered into the ID Tracker.)

No one has indicated to the WG chairs or WG mailing list that they
have intentions of appealing any proposed publication of this
document.

    (1.g)  Has the Document Shepherd personally verified that the
           document satisfies all ID nits?  (See
           http://www.ietf.org/ID-Checklist.html and
           http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
           not enough; this check needs to be thorough.  Has the
document
           met all formal review criteria it needs to, such as the MIB
           Doctor, media type and URI type reviews?

I have reviewed nits output on IETF tools, and there is nothing
that should prevent this document advancing.

    (1.h)  Has the document split its references into normative and
           informative?

Yes.

           Are there normative references to documents that
           are not ready for advancement or are otherwise in an unclear
           state?  If such normative references exist, what is the
           strategy for their completion?  Are there normative
references
           that are downward references, as described in [RFC3967]?  If
           so, list these downward references to support the Area
           Director in the Last Call procedure for them [RFC3967].

All references are RFCs (two are listed under draft names, but have
recently advanced. This will be fixed in the edit phase).

    (1.i)  Has the Document Shepherd verified that the document IANA
           consideration section exists and is consistent with the body
           of the document?  If the document specifies protocol
           extensions, are reservations requested in appropriate IANA
           registries?  Are the IANA registries clearly identified?  If
           the document creates a new registry, does it define the
           proposed initial contents of the registry and an allocation
           procedure for future registrations?  Does it suggested a
           reasonable name for the new registry?  See
           [I-D.narten-iana-considerations-rfc2434bis].  If the document
           describes an Expert Review process has Shepherd conferred
with
           the Responsible Area Director so that the IESG can appoint
the
           needed Expert during the IESG Evaluation?

Yes.

Also note that we have been requested by the authors to provide
early allocation of three Interface Parameters Sub-TLV type values
and I propose that we should do this.

    (1.j)  Has the Document Shepherd verified that sections of the
           document that are written in a formal language, such as XML
           code, BNF rules, MIB definitions, etc., validate correctly in
           an automated checker?

Not applicable

    (1.k)  The IESG approval announcement includes a Document
           Announcement Write-Up.  Please provide such a Document
           Announcement Writeup?  Recent examples can be found in the
           "Action" announcements for approved documents.  The approval
           announcement contains the following sections:

           Technical Summary
  This document defines extension to the PWE3 control protocol [RFC4447]
  and PWE3 IANA allocations [RFC4446] required for setup of TDM
  (RFC4553, RFC5086 and RFC5087) pseudowires in MPLS networks.

            Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

           Protocol Quality

This is a simple extension to RFC4447 to allow the provisioning of
some additional (well known) PW types using the already established
rules and procedures.

           Personnel
              Who is the Document Shepherd for this document?

Stewart Bryant (stbryant <at> cisco.com)

              Who is the Responsible Area Director?

Mark Townsley (townsley <at> cisco.com)

_______________________________________________
pwe3 mailing list
pwe3 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

Gmane