headers
Loa Andersson | 1 Feb 2008 10:58
Picon

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

All,

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 -01 
and higher)
Internet-Draft Submissions

All revised Internet-Drafts (version -01 and higher) must be submitted
by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT).

Initial and revised Internet-Drafts received after their respective
cutoff dates will not be made available in the Internet-Drafts
directory or announced until on or after Monday, March 10th at 9:00
AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes.  Please do
(Continue reading)

Permalink | Reply | 0 comments |
headers
Loa Andersson | 1 Feb 2008 11:07
Picon

mpls working group meeting in Philadelphia

Working Group,

there will be an MPLS working group meeting at the Philadelphia
IETF meeting. The preliminary agenda for the IETF meeting will
be published next Friday, but that won't stop us from starting
to put the agenda for the mpls working group together.

Please send request for agenda slots to the mpls working group
mailing list and/or the working co-chars.

Loa and George

--

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson <at> acreo.se
                                            loa <at> pi.se
_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Matt Tylenda | 1 Feb 2008 16:19
Favicon

CFP for MPLS2008

The Call for Presentations (CFP) for MPLS 2008, the 11th event of this conference series, will become available and submissions will be open on officially February 15. You are encouraged to provide input to the CFP topics or submit abstracts in the related field by sending your proposals to mpls2008-cfp <at> isocore.com.

 

MPLS 2008 will be held October 19 -22 in Washington, DC. Check for more details at www.mpls2008.com.

 

Regards,

--
Matt Tylenda mtylenda <at> isocore.com ISOCORE 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
anshu | 4 Feb 2008 07:02
Favicon

query

How is the layer 3 related  decisions are taken at the egress of LSP as the MPLS label does not carry any such information.
Thanks and Regards,
Anshu

_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 501 comments |
headers
jayakrishna | 4 Feb 2008 09:56

mpls help

hai all,
currently i am developing MPLS for metro-ethernnet switch, i have a doubt on FEC that is how FEC-label mapping is done for the switch.
 
Thanks
Regards
Jaya Krishna
_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Sachin Kalra | 4 Feb 2008 17:17
Favicon

Re: query

By the time packet reaches egress, all the labels have already been stripped off (either PHP or egress popping). Thus, it goes through regular layer 3 processing.

- SK
 
At 01:02 AM 2/4/2008, anshu wrote:
How is the layer 3 related  decisions are taken at the egress of LSP as the MPLS label does not carry any such information.
Thanks and Regards,
Anshu


_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls 
_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 501 comments |
headers
bruno.decraene | 6 Feb 2008 15:23

Re: draft-ietf-mpls-ldp-interarea-01.txt to WG last call

George, Loa, WG,

We have updated the draft to take into account the comments received:

http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-interarea-02.txt

Additional comments are welcomed.

Thanks,
Regards,
Bruno

> -----Message d'origine-----
> De : George Swallow [mailto:swallow <at> cisco.com]
> Envoyé : mardi 29 janvier 2008 20:56
> À : DECRAENE Bruno RD-CORE-ISS
> Cc : dave.mcdysan <at> verizon.com; mpls <at> ietf.org; swallow <at> cisco.com
> Objet : Re: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
> 
> Bruno -
> 
> It seems my call for "is it ready" has turned into a bit of a last call.
> Could you update your draft with all the things you've been discussing
> over the last month?  I'll issue the "official" last call as soon as it
> is available.
> 
> Many thanks,
> 
> ...George
> 
> ========================================================================
> George Swallow             Cisco Systems                  (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719

_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
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
Permalink | Reply | 2 comments |
headers
Loa Andersson | 6 Feb 2008 18:07
Picon

wg last call for "LDP extension for Inter-Area LSP"

Working Group,

this is to initiate a working group last call on

"LDP extension for Inter-Area LSP"
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-interarea-02.txt

The working group last call will end on eob February 21st. Please send
your comments to the working group mailing list.

Loa and George

--

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson <at> acreo.se
                                            loa <at> pi.se
_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 11 comments |
headers
JP Vasseur | 6 Feb 2008 21:30
Picon
Favicon

Re: working group last callfordraft-ietf-mpls-number-0-bw-te-lsps

Hi Adrian,

> From: Adrian Farrel <adrian <at> olddog.co.uk>
> Reply-To: Adrian Farrel <adrian <at> olddog.co.uk>
> Date: Thu, 10 Jan 2008 10:17:13 -0000
> To: 'Jean Philippe Vasseur' <jvasseur <at> cisco.com>
> Cc: <mpls <at> lists.ietf.org>
> Subject: Re: [mpls] working group last
> callfordraft-ietf-mpls-number-0-bw-te-lsps
> 
> Hi,
> 
> I have been very tardy, so none of my notes below should be considered
> blocking on my account, nor even a request for a change.

Good timing. The current revision addresses all comments received during LC,
the next one will take yours into account.

See below,

> 
> You may want to consider them for any future revision.
> 
> Cheers,
> Adrian
> 
>>> Abstract
>>> s/carried onto/carried by/
>>> s/referred to as unconstrained TE LSP/referred to as unconstrained TE
>>> LSPs/
> ===
> Section 2
> 
> s/Label Switched Path(s) (TE LSP)/Label Switched Paths (TE LSPs)/
> s/assumption about/assumptions about/
> s/(Label Switching Router)/(Label Switching Routers)/
> ===

Done.

> Section 2
> 
>    Unconstrained TE LSPs that are configured and provisioned through a
>    management system MAY not be included in the count that is reported.
> 
> The use of "MAY not" is ambiguous. People will be unclear whether you
> actually mean "MAY NOT".
> 
> I think you want...
> 
>    Unconstrained TE LSPs that are configured and provisioned through a
>    management system MAY be omitted from the count that is reported.

Agree, there is no ambiguity with that wording. Changed.

> ===
>>> Section 2
>>>  "Furthermore, the knowledge of the number of unconstrained TE LSPs
>>>   signalled across each link can be used for other purposes (for
>>>   example to evaluate the number of affected TE LSPs in case of a link
>>>   failure)."
>>> Wouldn't this function be better if we knew the actual number of TE LSPs
>>> on a link rather than only the number of zero bandwidth TE LSPs? Since we
>>> don't propose an extension that simply counts the number of TE LSPs,
>>> perhaps it would be simpler to delete this paragraph.
> 
>> JP> Well for the number of deployed networks with 0-bw TE LSPs used for
>> FRR
>> purposes, it might still be useful to know the number of 0-bw TE LSPs.
> 
> Then you probably want...
> 
>    Furthermore, the knowledge of the number of unconstrained TE LSPs
>    signalled across each link can be used for other purposes (for
>    example to evaluate the number of affected unconstrained TE LSPs in
>    case of a link failure).

Done.

> ===
> Section 3
> s/The Number of 0-bandwidth TE LSP(s) Sub-TLV is defined/The Unconstrained
> TE LSP Count Sub-TLV is defined/

Done. 

> ===
> Section 3.2
> s/If a second instance of the Number of 0-bandwidth TE LSP(s) sub-TLV is
> present/If a second instance of the Unconstrained TE LSP Count Sub-TLV is
> present/

Done + also added to the section 3.1

> ===
>>> Section 6
>>> Is finger really the right protocol to reference for ISIS security?
> 
> Are you still *really* sure you want to reference RFC 1194? Don't you mean
> RFC 1195?

;-) Good Catch, Thanks.

Cheers.

JP.

> 
> 
> 
> 

_______________________________________________
mpls mailing list
mpls <at> ietf.org
http://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |

Gmane