RE: RE: [Isis-wg] CCAMP Working group last callondraft-ietf-ccamp-te-node-cap-02.txt

Hi Lee

Sorry for this late answer.
Thanks for your comments, please see inline, 

> -----Message d'origine-----
> De : Les Ginsberg (ginsberg) [mailto:ginsberg <at> cisco.com] 
> Envoyé : dimanche 22 octobre 2006 08:37
> À : zzx-adrian <at> olddog.co.uk; isis-wg <at> ietf.org; ospf <at> ietf.org; 
> mpls <at> lists.ietf.org
> Cc : routing-discussion <at> ietf.org
> Objet : [mpls] RE: [Isis-wg] CCAMP Working group last 
> callondraft-ietf-ccamp-te-node-cap-02.txt 
> 
> In regards to the IS-IS definitions, there is (again - sorry 
> JP...) confusion in the use of the terms TLV and subTLV.
> 
> For example, in Section 2 it states:
> 
> <snip>
> A new TLV is defined for ISIS and OSPF: the TE Node Capability 
>    Descriptor TLV, to be carried within: 
>         - The ISIS Capability TLV ([ISIS-CAP]) for ISIS...
> <end snip>
> 
> If the information is carried within another TLV, then it is 
> clearly subTLV information - the difference between the two 
> is more than terminology since it impacts both the encoding 
> and the scope of the identifiers which are assigned.
> 
(Continue reading)

JP Vasseur | 3 Nov 14:22 2006
Picon

Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi,

First of all, my full support to the ID, this is for sure a needed  
solution in several cases.

Here are my comments/suggestions:
1) To be discussed next week (live will be easier): it might be  
useful in some cases to tradeoff the rerouting times for the P2MP  
backup efficiency, provided that the failure detection times stays  
bounded of course and on the order of a few ms. Note that in  
situations where P2MP backup may be useful, it may make sense to have  
the PLR not immediately upstream to the protected element. We can use  
an distributed bidding mechanism to determine the PLR based on the  
P2MP backup cost and the distance between the PLR and the protected  
element.
2) In the introduction, don't you want to indicate that the use of  
bypass P2MP tunnels may lead to more states compared to the P2P case  
because of the requirement to fully intersect the protected primary ?
3) Trade-off between a set of P2P, one P2MP bypass tunnels and a set  
of P2MP bypass tunnels. There are cases where it might be preferable  
to use a set of P2P because of the number of states if the PLR has to  
protect a large number of primary P2MP tunnels and the PLR cannot  
find a good overlapping bypass P2MP. An alternative is also to use a  
"few" P2MP bypass tunnels in that case: the PLR would have to do some  
replication but still much less than with P2P bypass tunnels.
3) It would be useful to indicate that a P2MP TE LSP may be protected  
by some PLRs using P2P and by other PLRs using P2MP bypass tunnel  
along the protected P2MP primary path (thus comment 5)).
5) It might be useful to define:
* a flag in the LSP-ATTRIBUTE to indicate at each PLR whether the  
(Continue reading)

Nitin Bahadur | 3 Nov 19:06 2006
Picon

RE: Two Questions about LSP-ping/traceroute (RFC 4379)


> -----Original Message-----
> 1) How should LSP-ping deal with PHP mode (penultimate-hop-popping) ?
>
> Suppose I am sending an mpls echo request packet to check a
> regular lsp and the packet is sent with the proper label X
> (shimmed between L2 and L3) and a FEC Stack TLV which includes a
> LDP-IpV4 sub-tlv.
> This packet may reach its destination, some egress LER Y, without
> any shimmed label due to the use of
> PHP mode. Section 4.2 in RFC 4379 suggest that we use Nil-FEC
> sub-TLV to account for the missing Label that was popped. The
> question is which LSR insert this Nil-FEC. Note that the LER that
> initiated the echo-request doesn't know in advance if the label
> is going to be popped at the penultimate LSR. Moreover the
> penultimate LSR it self cannot add this FEC since it has no
> trigger to process the packet as he recieves a regular labeled
> packet and simply performs a popping and forwarding procedures. ?
> It is furthermore unclear wether in this case we should also use
> Explicite Null label (label 0) or not?.
>

The ingress LSR that initiates the request should add the NIL-FEC in
addition
to the FEC being tested. One can associate the EXPLICIT-NULL label with the
NIL FEC. That wat the ingress LSR does not need to know if the PHP will be
used
or not. If PHP is used, egress will receive the packet with EXPLICIT-NULL
label.
If PHP is not-used, egress will receive the packet with 2+ labels. In both
(Continue reading)

RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi Jean-Philippe

Thanks a lot for these comments

Please see inline, 

> -----Message d'origine-----
> De : JP Vasseur [mailto:jvasseur <at> cisco.com] 
> Envoyé : vendredi 3 novembre 2006 14:22
> À : LE ROUX Jean-Louis RD-CORE-LAN; zzx-rahul <at> juniper.net
> Cc : mpls <at> ietf.org
> Objet : Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt
> 
> Hi,
> 
> First of all, my full support to the ID, this is for sure a 
> needed solution in several cases.
> 
> Here are my comments/suggestions:
> 1) To be discussed next week (live will be easier): it might 
> be useful in some cases to tradeoff the rerouting times for 
> the P2MP backup efficiency, provided that the failure 
> detection times stays bounded of course and on the order of a 
> few ms. Note that in situations where P2MP backup may be 
> useful, it may make sense to have the PLR not immediately 
> upstream to the protected element. We can use an distributed 
> bidding mechanism to determine the PLR based on the P2MP 
> backup cost and the distance between the PLR and the 
> protected element.

(Continue reading)

Bill Fenner | 6 Nov 17:48 2006
Picon

TCP Authentication discussion: tcpm wg, Thursday 1300-1500


Hi,

  I'd like to draw your attention to the tcpm working group
agenda; it begins with a discussion of draft-bellovin-tcpsec,
whose abstract reads:

   The TCP-MD5 option, commonly used to secure BGP sessions between
   routers, has many serious deficiencies.  We present here
   justifications for designing a new, more capable version of that
   option; we also discuss some of the design criteria for one.

I'd encourage those with thoughts and experience in this area to attend
if you can.

Thanks,
  Bill

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

JP Vasseur | 7 Nov 03:10 2006
Picon

Re: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi Jean-Louis,

On Nov 6, 2006, at 9:58 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Jean-Philippe
>
> Thanks a lot for these comments
>
> Please see inline,
>
>> -----Message d'origine-----
>> De : JP Vasseur [mailto:jvasseur <at> cisco.com]
>> Envoyé : vendredi 3 novembre 2006 14:22
>> À : LE ROUX Jean-Louis RD-CORE-LAN; zzx-rahul <at> juniper.net
>> Cc : mpls <at> ietf.org
>> Objet : Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt
>>
>> Hi,
>>
>> First of all, my full support to the ID, this is for sure a
>> needed solution in several cases.
>>
>> Here are my comments/suggestions:
>> 1) To be discussed next week (live will be easier): it might
>> be useful in some cases to tradeoff the rerouting times for
>> the P2MP backup efficiency, provided that the failure
>> detection times stays bounded of course and on the order of a
>> few ms. Note that in situations where P2MP backup may be
>> useful, it may make sense to have the PLR not immediately
>> upstream to the protected element. We can use an distributed
(Continue reading)

Shahram Davari | 7 Nov 20:57 2006

re: draft-bryant-pwe3-mpls-transport-00.txt

Hi,

I don't think Transporting MPLS-O-Ethernet-O-MPLS is the best way for Transporting MPLS over another
MPLS network. Why not just define a simple MPLS PW? This would save you at least 14 bytes per packet. 

-Shahram

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

Internet-Drafts | 7 Nov 21:50 2006
Picon

I-D ACTION:draft-ietf-mpls-over-l2tpv3-02.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		: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
	Author(s)	: M. Townsley, et al.
	Filename	: draft-ietf-mpls-over-l2tpv3-02.txt
	Pages		: 12
	Date		: 2006-11-7
	
The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
   protocol for tunneling a variety of payload types over IP networks.
   This document defines how to carry an MPLS label stack and its
   payload over the L2TPv3 data encapsulation.  This enables an
   application which traditionally requires an MPLS-enabled core network
   to utilize an L2TPv3 encapsulation over an IP network instead.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-over-l2tpv3-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mpls-over-l2tpv3-02.txt".
(Continue reading)

Kireeti Kompella | 8 Nov 20:55 2006
Picon

Re: RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi Jean-Louis,

To re-iterate my comment in the WG, in general, node protection, 
whether for p2p or p2mp LSPs, is an order of magnitude less scalable 
than link protection.

I think we should step back at this point, and request SPs and others 
deploying MPLS networks to share with the WG: frequencies of link 
failures, node software failures (node recovers), node failures 
(requires manual intervention), and battery explosions, to give us a 
sense of the importance of continuing the work on node protection.

I realize that some of these figures may be sensitive, but even 
normalized numbers may be useful.

Kireeti.
-------

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

JP Vasseur | 8 Nov 22:00 2006
Picon

Re: RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

Hi Kireeti,

thoughts in line

On Nov 8, 2006, at 2:55 PM, Kireeti Kompella wrote:

> Hi Jean-Louis,
>
> To re-iterate my comment in the WG, in general, node protection,  
> whether for p2p or p2mp LSPs, is an order of magnitude less  
> scalable than link protection.
>

Ah well, starting some discussion on a definition of "scalability"  
may quickly become a cumbersome task. Node P undoubtedly requires  
more backup tunnels compared to link protection. Up to a point where  
the number of backup tunnels becomes unreasonable ? Looking a typical  
degree of connectivity, it does not look unreasonable especially with  
Bypass compared to the overall number of primary TE LSPs in most meshes.

> I think we should step back at this point, and request SPs and  
> others deploying MPLS networks to share with the WG: frequencies of  
> link failures, node software failures (node recovers), node  
> failures (requires manual intervention), and battery explosions, to  
> give us a sense of the importance of continuing the work on node  
> protection.
>
> I realize that some of these figures may be sensitive, but even  
> normalized numbers may be useful.
>
(Continue reading)


Gmane