headers
Luyuan Fang (lufang | 2 Apr 2008 09:01
Picon
Favicon

Re: wg last call on draft-ietf-mpls-ldp-igp-sync-01.txt

Hi Bruno,

Thank you for the comments. Please see in-line.

> -----Original Message-----
> From: mpls-bounces <at> ietf.org [mailto:mpls-bounces <at> ietf.org] On 
> Behalf Of bruno.decraene <at> orange-ftgroup.com
> Sent: 26 March 2008 13:08
> To: loa <at> pi.se; mpls <at> ietf.org
> Subject: Re: [mpls] wg last call on 
> draft-ietf-mpls-ldp-igp-sync-01.txt
> 
> Hi Markus, Alia, Luyuan, all,
> 
> A few comments:
> 
> 1) May be the document should talk about its interaction with 
> graceful restart. (I guess this document should not be used 
> when GR is used, unless GR is aborted or failed.).
> 

Very good point. Let's try to look the relationship between LDP-IGP
synch (LDP-IGP) and Graceful Restart (GR). In fact, LDP-IGP is also used
when GR is used.

There are LDP GR [RFC 3478] and IGP GR - OSPF GR [RFC 3623] and ISIS GR
[RFC 3847].

A. LDP GR and LDP-IGP synch:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Veitch | 2 Apr 2008 10:03
Picon
Favicon

Veitch, Andrew is out of the office.


I will be out of the office starting  03/31/2008 and will not return until
04/07/2008.

I will respond to your message when I return.

_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 0 comments |
headers
Masayuki Takase | 2 Apr 2008 12:37
Picon

Question on the status of Y.1711 and RFC3429

Hi Loa,

Hitachi has implemented Transport Switch chips that support MPLS OAM using 
the Label 14. Therefore we disagree to the modification of the existing 
RFC3429 document.
So we also suggest using a different label for the new function.

Regards,
-----------------------------------
Masayuki Takase
Hitachi, Communication Technologies, Ltd.
216 Totsuka-cho, Totsuka-ku,
Yokohama-shi 244-8567, Japan
Tel: +81-45-865-7003(Ext.4094)
Email:masayuki.takase.vx <at> hitachi.com

----- Original Message ----- 
> Hi Loa,
>
> Yes we have implemented the Label 14 in our packet processor/switch chips
> as
> requested by our customers. So we suggest using a different label for the
> new function.
>
>
> Regards,
>
>    Shahram Davari | Director, Systems Engineering
>    T|PACK| 9 King's Inn Trail | Markham | Ontario L3T 1T6| Canada
>    Direct: +1 905 597 3125 | Mobile: +1 416 371 3139 | Email:
(Continue reading)

Permalink | Reply | 504 comments |
headers
Ville Hallivuori | 2 Apr 2008 14:32
Picon
Picon
Favicon

Re: Question on the status of Y.1711 and RFC3429

Tellabs has implementation of Y.1711. Current Y.1373 seems to be
sufficiently backward-compatible to Y.1711 to make it preferable to
use label 14 for it.

We (Tellabs) would rather see that EXP and TTL fields would not be mis-used (as
current Y.1373 mis-uses them for MEL and for filtering packets in
MIPs). However if mis-use of these fields is insisted, changing label
value brings no additional advantages over using label 14.

As long as Y.1373 and Y.1711 packets can be differentiated and Y.1373
frames retain sufficient backward-compatibility (as is the case with
current specification), we prefer label 14. However Y.1373
specification should more clearly state the backward-compatibility with
Y.1711.

On Fri, Mar 28, 2008 at 09:49:54AM +0100, Loa Andersson wrote:
> All,
> 
> In the discussions the IETF and the ITU-T have had on T-MPLS we have
> discussed the intended use for label 14 and the different documents
> where this has been specified.
> 
> As a side effect we've also started to ask ourselves if there are any
> implementations and/or deployments that uses label 14.
> 
> A quick survey among known implementers of MPLS has not shown any
> implementations/deployments.
> 
> Since one of the approaches discussed in the Joint Working Team
> context is a solution that requires the allocation of a reserved
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Nadeau | 2 Apr 2008 15:50

Re: Question on the status of Y.1711 and RFC3429


	How could you have built MPLS OAM to support label 14? Do you mean  
you implemented Y1711 using label 14?

	--Tom

On Apr 2, 2008, at 6:37 AM, Masayuki Takase wrote:
> Hi Loa,
>
> Hitachi has implemented Transport Switch chips that support MPLS OAM  
> using
> the Label 14. Therefore we disagree to the modification of the  
> existing
> RFC3429 document.
> So we also suggest using a different label for the new function.
>
> Regards,
> -----------------------------------
> Masayuki Takase
> Hitachi, Communication Technologies, Ltd.
> 216 Totsuka-cho, Totsuka-ku,
> Yokohama-shi 244-8567, Japan
> Tel: +81-45-865-7003(Ext.4094)
> Email:masayuki.takase.vx <at> hitachi.com
>
> ----- Original Message -----
>> Hi Loa,
>>
>> Yes we have implemented the Label 14 in our packet processor/switch  
>> chips
(Continue reading)

Permalink | Reply | 503 comments |
headers
Francesco Fondelli | 2 Apr 2008 17:09
Picon

Re: Question on the status of Y.1711 and RFC3429

On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau <tnadeau <at> lucidvision.com> wrote:
>
>         How could you have built MPLS OAM to support label 14? Do you mean
>  you implemented Y1711 using label 14?
>
>         --Tom

Back in 2002/2003/2004? there used to be no 'T-' :-)

http://www.itu.int/rec/T-REC-Y.1711/en

"Y.1711: Operation & Maintenance mechanism for MPLS networks"

Clear, isn't it? //I'm sarcastic

Ciao
FF
_______________________________________________
mpls mailing list
mpls <at> ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Permalink | Reply | 10 comments |
headers
Jukka MJ Manner | 1 Apr 2008 08:18
Picon
Picon
Favicon

Re: [Tsvwg] WG last callfor draft-ietf-tsvwg-rsvp-user-error-spec-03


Hi,

Sounds very good to me. 

Sorry that I missed that "MAY" for the suboptions. :)

Cheers,
Jukka

On Mon, 31 Mar 2008, Adrian Farrel wrote:

> Hi Jukka,
> 
> > I have read the draft, and think it is a reasonable proposal, and
> > presented well. I have just a few minor comments/clarification requests:
> >
> > - What is exactly meant by "it is RECOMMENDED that organizations use a
> >  published scheme for this string to promote consistent decoding."? Could
> >  you add an example, perhaps?
> 
> Ah. Probably over-enthusiastic text created when we added the Error
> Description string before this became a WG I-D.
> 
> What we meant was that it might be helpful to a device that is going to a user
> that is going to read this string if they knew that a string coming from a
> device made by vendor X should be interpreted in a particular way. For
> example, date stamp, IP address, error string.
> 
> However, looking at this again, I would be happy to strike this text.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Apr 2008 21:15
Picon
Favicon

I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Component Link Recording and Resource Control for TE Link Bundles
	Author(s)	: A. Zamfir
	Filename	: draft-ietf-mpls-explicit-resource-control-bundle-03.txt
	Pages		: 12
	Date		: 2008-4-2
	
Record Route is a useful administrative tool that has been used  
   extensively by the service providers. However, when TE links are 
   bundled, identification of label resource in Record Route Object 
   (RRO) is not enough for the administrative purpose. Network service 
   providers would like to know the component link within a TE link that 
   is being used by a given LSP. In other words, when link bundling is 
   used, resource recording requires mechanisms to specify the component 
   link identifier, along with the TE link identifier and Label. As it 
   is not possible to record component link in the RRO, this draft 
   defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify 
   component link identifiers for resource recording purposes.   

   This draft also defines the Explicit Route Object (ERO) counterpart 
   of the RRO extension. The ERO extensions are needed to perform 
   explicit label/ resource control over bundled TE link. Hence, this 
   document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to 
   specify component link identifiers for explicit resource control and 
   recording over TE link bundles.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adrian Farrel | 3 Apr 2008 00:15
Picon

Re: I-D ACTION:draft-ietf-mpls-explicit-resource-control-bundle-03.txt

Hi Anca,

Interesting to see this draft back again. I think it expired in April 2007 
and I had assumed we had given up on it.

A couple of thoughts...

===

In the terminology section you have:
   For unnumbered component links, the component link
   ID is assumed to be unique on an advertising node.

I think this reflects exactly what was discussed several IETFs ago (possibly 
in CCAMP with respect to the hierarchy-bis draft or maybe 
draft-ietf-ccamp-gmpls-addressing-03). However, don't you need to have some 
RFC 2119 language here? Failing this assumption will break your draft, so 
this is a "MUST" in which case I suggest you move it from the Terminology 
section to the main body of the draft.

===

More generally, way back in March 2006, in Dallas, CCAMP discussed how to 
build EROs and RROs in order to qualify this in 
draft-ietf-ccamp-gmpls-addressing (now RFC 4990). We had a survey and 
published the results in 
http://www.watersprings.org/pub/id/draft-farrel-ccamp-ero-survey-00.txt. The 
conclusion seemed to be that implementations of bundling simply reported 
(and signaled) component links by including two sequential interface IDs, 
the first indicating the TE link and the second the component link. There
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Nadeau | 3 Apr 2008 01:32

Re: Question on the status of Y.1711 and RFC3429


	ITU recommendation Y1711 has nothing to do with MPLS OAM.  If you  
want a
good overview of IETF MPLS OAM take a look at RFC4221.

	--Tom

On Apr 2, 2008, at 11:09 AM, Francesco Fondelli wrote:
> On Wed, Apr 2, 2008 at 3:50 PM, Thomas Nadeau  
> <tnadeau <at> lucidvision.com> wrote:
>>
>>        How could you have built MPLS OAM to support label 14? Do  
>> you mean
>> you implemented Y1711 using label 14?
>>
>>        --Tom
>
> Back in 2002/2003/2004? there used to be no 'T-' :-)
>
> http://www.itu.int/rec/T-REC-Y.1711/en
>
> "Y.1711: Operation & Maintenance mechanism for MPLS networks"
>
> Clear, isn't it? //I'm sarcastic
>
> Ciao
> FF
>

_______________________________________________
(Continue reading)

Permalink | Reply | 9 comments |

Gmane