Loa Andersson | 1 Sep 2006 10:01
Picon

wg last on draft-ietf-mpls-iana-rsvp-session-flags-00.txt

Working Group,

this initiates a two week last call for
draft-ietf-mpls-iana-rsvp-session-flags-00.txt

The last call ends September 17th (yes - it is a Sunday
and we won't do anything until Monday morning :) ).

Please send comments to the working group mailing list and/or
the wg group chairs.

Since this is a very short draft, we'd like to see comments on
the text/content as well as comments if we are ready to
send it to the IESG for review  to become an informational RFC.

/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> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
(Continue reading)

Loa Andersson | 1 Sep 2006 10:08
Picon

WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

Working Group,

this initiates a two week working group last call on
draft-ietf-mpls-number-0-bw-te-lsps-02.txt

The wg last call ends on September 17.

Please send comments to the working group mailing list and/or
the working group chairs.

/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> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Loa Andersson | 1 Sep 2006 10:14
Picon

draft-farrel-mpls-p2mp-te-mib-01.txt to become an mpls working group document

Working Group,

the authors of draft-farrel-mpls-p2mp-te-mib-01.txt
has requested the the draft is made a working group
document.

Please send comments to the working group mailing list
and/or the wg chairs.

/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> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

JP Vasseur | 1 Sep 2006 12:40
Picon
Favicon

Re: draft-farrel-mpls-p2mp-te-mib-01.txt to become an mpls working group document

In favor.

Thanks.

JP.

On Sep 1, 2006, at 4:14 AM, Loa Andersson wrote:

> Working Group,
>
> the authors of draft-farrel-mpls-p2mp-te-mib-01.txt
> has requested the the draft is made a working group
> document.
>
> Please send comments to the working group mailing list
> and/or the wg chairs.
>
> /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
(Continue reading)

RE: draft-farrel-mpls-p2mp-te-mib-01.txt to become an mpls working group document

Hi Loa, all

This draft should become a WG doc

Regards

JL 

> -----Message d'origine-----
> De : Loa Andersson [mailto:loa <at> pi.se] 
> Envoyé : vendredi 1 septembre 2006 10:14
> À : mpls <at> ietf.org
> Objet : [mpls] draft-farrel-mpls-p2mp-te-mib-01.txt to become 
> an mpls working group document
> 
> Working Group,
> 
> the authors of draft-farrel-mpls-p2mp-te-mib-01.txt
> has requested the the draft is made a working group document.
> 
> Please send comments to the working group mailing list and/or 
> the wg chairs.
> 
> /Loa and George
> 
> --
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
(Continue reading)

Adrian Farrel | 1 Sep 2006 18:59
Picon

Re: WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

Loa,

In the light of recent experience with draft-ietf-ccamp-automesh, I strongly 
recommend that you notify the OSPF and IS-IS working groups about this last 
call.

Cheers,
Adrian
----- Original Message ----- 
From: "Loa Andersson" <loa <at> pi.se>
To: mpls <at> ietf.org
Sent: Friday, September 01, 2006 9:08 AM
Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

> Working Group,
>
> this initiates a two week working group last call on
> draft-ietf-mpls-number-0-bw-te-lsps-02.txt
>
> The wg last call ends on September 17.
>
> Please send comments to the working group mailing list and/or
> the working group chairs.
>
> /Loa and George
>
> -- 
> Loa Andersson
>
> Principal Networking Architect
(Continue reading)

Loa Andersson | 4 Sep 2006 11:55
Picon

Re: WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

Adrain,

point taken - and will notify the the routing directorate as well.

/Loa

Adrian Farrel wrote:
> Loa,
> 
> In the light of recent experience with draft-ietf-ccamp-automesh, I
> strongly recommend that you notify the OSPF and IS-IS working groups
> about this last call.
> 
> Cheers,
> Adrian
> ----- Original Message ----- From: "Loa Andersson" <loa <at> pi.se>
> To: mpls <at> ietf.org
> Sent: Friday, September 01, 2006 9:08 AM
> Subject: [mpls] WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt
> 
> 
>> Working Group,
>>
>> this initiates a two week working group last call on
>> draft-ietf-mpls-number-0-bw-te-lsps-02.txt
>>
>> The wg last call ends on September 17.
>>
>> Please send comments to the working group mailing list and/or
>> the working group chairs.
(Continue reading)

Adrian Farrel | 5 Sep 2006 00:00
Picon

Re: WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

Hi,

A quick review of this I-D leaves me puzzled by the motivation. I don't 
think it is enough to say "I want to know how many unconstrained TE LSPs 
traverse every link in the network"; we must have an idea of how that 
information will be used.

Now the I-D says:

... in the Abstract
   There are various
   circumstances (for example in order to load balance unconstrained TE
   Label Switched Path (LSP) across a set of equal cost paths) where it
   would be useful to also advertise the number of unconstrained Traffic
   Engineering Label Switched Path(s) (TE LSP) signalled across a link.

... and in the Introduction
   If the
   number of unconstrained TE LSPs traversing each link in the network
   is known, various algorithms can be designed so as to efficiently
   load balance the traffic carried onto such unconstrained TE LSPs.

...but this seems to me to be an supported assertion. I guess you could cite 
a reference so you don't need to prove the algorithms here. But it seems to 
me that the count of such LSPs is a very poor measure indeed. The only way 
you could use it would be if you could make some fairly tight statistical 
assumptions about the traffic on each LSP, or at least the statistically 
aggregate traffic on a number of LSPs.

Surely it would be better for the LSRs to report link usage rather than the 
(Continue reading)

Daniel King | 6 Sep 2006 23:32
Favicon

Re: WG Last Call on draft-ietf-mpls-number-0-bw-te-lsps-02.txt

Hi Guys,

I believe there are some situations where balancing the number of zero
bandwidth LSPs across the network may be very helpful. Certainly one
example arises where there are lots of zero bandwidth LSPs and
statistical techniques may be used to predict the aggregate load of the
LSPs on a link. I might think of other situations, including where the
only use of zero bandwidth LSPs is for FRR. 

For me the point that is not sufficiently clear from the current text is
that the load balancing does not just apply to the placement of new
unconstrained LSPs. I think it's important to highlight that the
information can also be used to determine onto which LSPs to place
traffic in the traffic classification function.

In order to clarify the purpose of the I-D and to address Adrian's
point, I would like to suggest the following change to the I-D in the
Introduction (section 1).

OLD
   With MPLS Traffic Engineering a usual rerouting criteria is the
   discovery of a better path for a TE LSP where a better path is
   defined as a path with a lower cost according to a specific metric;
   other metric such that the percentage of reserved bandwidth or the
   number of hops can also be used.  Unfortunately, for instance in the
   presence of ECMPs (Equal Cost Multi-Paths) in symmetrical networks
   when unconstrained TE LSP are used, such metrics are usually
   ineffective and may lead to poorly load balanced traffic.  If the
   number of unconstrained TE LSPs traversing each link in the network
   is known, various algorithms can be designed so as to efficiently
(Continue reading)

Romascanu, Dan (Dan | 7 Sep 2006 15:04
Favicon

Re: Last Call: 'Label Switching Router Self-Test' to Proposed Standard (draft-ietf-mpls-lsr-self-test)

I read this document and in general I believe that it's well and clear
written. I have a couple of technical issues and a few editorial nits

1. The document is sharing allocation space and refers in several places
to [LSP-Ping] which is also listed as a Normative Reference. I could not
however clearly identify what document is that, as no I-D is provided.
Did this reference become in the meantime RFC4379? 

In any case, there are a few problems with the shared IANA allocations:
- Section 2.1 makes a provisional allocation for FEC element type 130,
which is not mentioned in the IANA Considerations section
- Section 3.1 makes a provisional assignment for two message types
without mentioning IANA
- Section 3.2 mentions the need for allocation of a new UDP port, but
the IANA Considerations does not mention it. I also guess that this is a
non-system port, but there is no mention of this in the document, would
be good to clarify

2. The document lacks any information about operational impact and
management issues. I believe that it should state as a minimum in the
security considerations section that any control interface that allows
for packets generation needs to be properly access-secured and that the
levels of test traffic must be kept within reasonable limits, so that
they do not impact the performance of the LSRs involved in the tests or
the levels of traffic in the network. 

Editorial nits:

1. As LSR and MPLS are expanded in the Abstract section it would be nice
and consistent to expand also FEC. 
(Continue reading)


Gmane