From lizhong.jin@zte.com.cn Thu Mar 1 00:46:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7725C21F8623 for ; Thu, 1 Mar 2012 00:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.178 X-Spam-Level: X-Spam-Status: No, score=-101.178 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCl0wuPGwhpE for ; Thu, 1 Mar 2012 00:46:53 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 930E921F85F8 for ; Thu, 1 Mar 2012 00:46:52 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Thu, 1 Mar 2012 16:15:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 49094.4734952721; Thu, 1 Mar 2012 16:46:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q218kY4Z088518; Thu, 1 Mar 2012 16:46:34 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: Vishwas Manral MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Thu, 1 Mar 2012 16:45:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-01 16:46:37, Serialize complete at 2012-03-01 16:46:37 Content-Type: multipart/alternative; boundary="=_alternative 003034C2482579B4_=" X-MAIL: mse02.zte.com.cn q218kY4Z088518 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:46:54 -0000 This is a multipart message in MIME format. --=_alternative 003034C2482579B4_= Content-Type: text/plain; charset="US-ASCII" > Hi Lizhong/ Pranjal/ Mustapha, > > So the two main comments that have come after last call are: > > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. > > The second could lead to changes required in both OSPF and IS-IS, as > well because the new LSR ID would then need to be exchanged. We > could treat it as an enhancement instead in my view. Do you agree? [Lizhong] agree, but as Kamran pointed out also in another email, it is not necessary to flood LSR-ID in routing protocol, the transport address in hello message is required to be flooded. Regards Lizhong > > Thanks, > Vishwas > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) < > pranjal.dutta@alcatel-lucent.com> wrote: > Yes, I support that too. There would be network management issues > with mapping of 4 byte LSR-ID to an IPV6 remote address. > Most of the implementations I know off usually maps 4 byte of the > LSR-ID with a local ipv4 interface address in the system. > > Thanks, > Pranjal > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out in my first email. > > Thanks > Lizhong > > > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003034C2482579B4_= Content-Type: text/html; charset="US-ASCII"

> Hi Lizhong/ Pranjal/ Mustapha,
>
> So the two main comments that have come after last call are:
>
> 1. Allow for separation of sessions along with the adjacency.
> 2. Allow for an IPv6 based LSR-ID.
>
> The second could lead to changes required in both OSPF and IS-IS, as
> well because the new LSR ID would then need to be exchanged. We
> could treat it as an enhancement instead in my view. Do you agree?
[Lizhong] agree, but as Kamran pointed out also in another email, it is not necessary to flood LSR-ID in routing protocol, the transport address in hello message is required to be flooded.

Regards
Lizhong

>
> Thanks,
> Vishwas
> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <
> pranjal.dutta@alcatel-lucent.com> wrote:
> Yes, I support that too. There would be network management issues
> with mapping of 4 byte LSR-ID to an IPV6 remote address.
> Most of the implementations I know off usually maps 4 byte of the
> LSR-ID with a local ipv4 interface address in the system.
>  
> Thanks,
> Pranjal
>  
>
> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> Sent: Wednesday, February 29, 2012 4:57 PM
> To: Aissaoui, Mustapha (Mustapha)
> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
>
> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  
>
> Hi Mustapha,
> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I
> pointed out in my first email.
>
> Thanks
> Lizhong
>  
>
> "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com
> > wrote 2012/03/01 04:35:41:
>
> > Hi Lizhong,
> > I actually think that we would need to define a new one which will
> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> > a all-IPv6 network will not be possible. I cannot see that operators
> > will start maintaining a mapping of some global non routable LSR-id
> > value to an IPv6 loopback interface on each router in the network.
> >  
> > Mustapha.
> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> > Aissaoui, Mustapha (Mustapha)
> > Sent: Tuesday, February 07, 2012 10:12 AM
> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
> > Cc: mpls@ietf.org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> > Lizhong,
> > the existing LSR-id will do the job and should be supported since
> > the LSR-id need not be an IP address. Most implementations will
> > actually populate the field with a /32 address in IPv4 and thus If
> > necessary we could define a new format to allow the use of /128
> IPv6addresses.
> >  
> > Mustapha.
> >
> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
> > Sent: Monday, February 06, 2012 10:23 PM
> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui,
> > Mustapha (Mustapha)
> > Cc: mpls@ietf.org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> >
> > Hi,
> > I wonder if it is feasible to use LDP capability to advertise IPv6
> > FEC without IPv6 adjacency, and only use one adjacency for LDP
> > session in dual-stack network. LDP capability is per node
> > capability, not per interface capability. But for LDP to choose the
> > correct downstream session and output interface for each FEC, it
> > should also check if the output interface is LDP enabled or not. The
> > link adjacency could be used to assist such kind of checking.
> >
> > However, IMO, it is valuable to allow two independent LDP sessions
> > for IPv4 and IPv6 as an option. Regarding the format definition in
> > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> > new format of LSR-ID.
> >
> > Regards
> > Lizhong
> >
> >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > > To: Vishwas Manral <vishwas.ietf@gmail.com>
> > > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > >    <mustapha.aissaoui@alcatel-lucent.com>,   "mpls@ietf.org"
> > >    <mpls@ietf.org>
> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > > Message-ID:
> > >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.
> > > alcatel-lucent.com>
> > >    
> > > Content-Type: text/plain; charset="us-ascii"
> > >
> > > I would rather for complete separation with multiple lsr-id because
> > > having separate link adjacencies does not really solved any problem.
> > > Since hello adjacencies are associated with a link, still fate
> > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6.
> > > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > > only decide whether such a link is to be programmed for IPV4 or IPV6
> > > egress traffic but I see it as overkill and unnecessary
> scalability impacts.
> > >
> > > Thanks,
> > > Pranjal
> > >
> > --------------------------------------------------------
> > ZTE Information Security Notice: The information contained in this
> > mail is solely property of the sender's organization. This mail
> > communication is confidential. Recipients named above are obligated
> > to maintain secrecy and are not permitted to disclose the contents
> > of this communication to others.
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please
> > notify the originator of the message. Any views expressed in this
> > message are those of the individual sender.
> > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003034C2482579B4_=-- From mustapha.aissaoui@alcatel-lucent.com Thu Mar 1 06:51:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673FA21E8309 for ; Thu, 1 Mar 2012 06:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.834 X-Spam-Level: X-Spam-Status: No, score=-6.834 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2OiXDJeIXJz for ; Thu, 1 Mar 2012 06:51:28 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id AEB5121E81DA for ; Thu, 1 Mar 2012 06:51:23 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q21EpInA015411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 08:51:19 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21EoEIC026826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 08:51:17 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 1 Mar 2012 08:51:14 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: Kamran Raza , Vishwas Manral , "Dutta, Pranjal K (Pranjal)" Date: Thu, 1 Mar 2012 08:51:13 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3ZVLPXkGCI1J0x0KRiPd99Trm7QAVPjbg Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5811502@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50AD5811502USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:51:30 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD5811502USNAVSXCHMBSC_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable that is correct. We do not want to change the meaning of LSR-ID. We just wa= nt it to be able to accomodate a global unique ID of the size of an IPv6 ad= dress. There will certainly be other additions to make the protocol support separa= te sessions and as such bumping the protocol version might be required. Mustapha. ________________________________ From: Kamran Raza [mailto:skraza@cisco.com] Sent: Wednesday, February 29, 2012 11:40 PM To: Vishwas Manral; Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Firstly, I don=92t agree that LSR Id be made IPv6 (address) based and/or ro= ute-able; LSR Id, as defined in the base spec, is just a 4 octet unique id = and need not be routable, though most implementations currently populate it= with /32 loopback address. Let=92s not carry forward a wrong notion/usage. Secondly, If there is a need to define new =93LDP Identifier=94 in order to= establish/maintain a separate session for IPv6 AF, this should be a protoc= ol change =97 i.e. we should bump up LDP protocol version in LDP PDU header= for this, and possibly define new format for =93LDP Identifier=94 in the c= ontext of new LDP protocol version. My 2 cents. On 12-02-29 8:11 PM, "Vishwas Manral" wrote: Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" wrot= e 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > To: Vishwas Manral > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > , "mpls@ietf.org" > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > > alcatel-lucent.com > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --_000_5DF53972F7E9134782DCE51624466FE50AD5811502USNAVSXCHMBSC_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06</TITL= E> <META content=3D"text/html; charset=3DWindows-1252" http-equiv=3DContent-Ty= pe> <META name=3DGENERATOR content=3D"MSHTML 8.00.6001.19170"></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D356594714-01032012><FONT size=3D2= =20 face=3DArial>that is correct. We do not want to change the meaning of LSR-I= D. We=20 just want it to be able to accomodate a global unique ID of the size of an = IPv6=20 address.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D356594714-01032012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D356594714-01032012><FONT size=3D2= =20 face=3DArial>There will certainly be other additions to make the protocol s= upport=20 separate sessions and as such bumping the protocol version might be=20 required.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D356594714-01032012><FONT size=3D2= =20 face=3DArial></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D356594714-01032012><FONT size=3D2= =20 face=3DArial>Mustapha.</FONT></SPAN></DIV><BR> <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft> <HR tabIndex=3D-1> <FONT size=3D2 face=3DTahoma><B>From:</B> Kamran Raza [mailto:skraza@cisco.= com]=20 <BR><B>Sent:</B> Wednesday, February 29, 2012 11:40 PM<BR><B>To:</B> Vishwa= s=20 Manral; Dutta, Pranjal K (Pranjal)<BR><B>Cc:</B> Aissaoui, Mustapha (Mustap= ha);=20 mpls@ietf.org; Lizhong Jin<BR><B>Subject:</B> Re: [mpls] Comments on=20 draft-ietf-mpls-ldp-ipv6-06<BR></FONT><BR></DIV> <DIV></DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR>Firstly, I don=92t agree that LSR Id be made = IPv6=20 (address) based and/or route-able; LSR Id, as defined in the base spec, is = just=20 a 4 octet unique id and need not be routable, though most implementations=20 currently populate it with /32 loopback address. Let=92s not carry forward = a wrong=20 notion/usage.<BR><BR>Secondly, If there is a need to define new =93LDP Iden= tifier=94=20 in order to establish/maintain a separate session for IPv6 AF, this should = be a=20 protocol change =97 i.e. we should bump up LDP protocol version in LDP PDU = header=20 for this, and possibly define new format for =93LDP Identifier=94 in the co= ntext of=20 new LDP protocol version. <BR><BR>My 2 cents. <BR><BR>On 12-02-29 8:11 PM,= =20 "Vishwas Manral" <<A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A>>=20 wrote:<BR><BR></SPAN></FONT> <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt">Hi Lizhong/ Pranjal/ Mustapha,<BR><BR>So the tw= o main=20 comments that have come after last call are:<BR><BR>1. Allow for separati= on of=20 sessions along with the adjacency.<BR>2. Allow for an IPv6 based=20 LSR-ID.<BR><BR>The second could lead to changes required in both OSPF and= =20 IS-IS, as well because the new LSR ID would then need to be exchanged. We= =20 could treat it as an enhancement instead in my view. Do you=20 agree?<BR><BR>Thanks,<BR>Vishwas<BR><BR>On Wed, Feb 29, 2012 at 5:03 PM,= =20 Dutta, Pranjal K (Pranjal) <<A=20 href=3D"pranjal.dutta@alcatel-lucent.com">pranjal.dutta@alcatel-lucent.co= m</A>>=20 wrote:<BR></SPAN></FONT> <BLOCKQUOTE><FONT color=3D#000080><FONT size=3D2><FONT face=3DArial><SPAN= =20 style=3D"FONT-SIZE: 10pt">Yes, I support that too. There would be netwo= rk=20 management issues with mapping of 4 byte LSR-ID to an IPV6 remote=20 address.<BR>Most of the implementations I know off usually maps 4 byte = of=20 the LSR-ID with a local ipv4 interface address in the=20 system.<BR> <BR>Thanks,<BR>Pranjal<BR> <BR></SPAN></FONT></FO= NT></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt"></SPAN></FONT> <P align=3Dcenter><FONT face=3D"Times New Roman"><SPAN style=3D"FONT-SI= ZE: 12pt"> <HR align=3Dcenter SIZE=3D3 width=3D"100%"> </SPAN></FONT> <P><FONT size=3D2><FONT face=3D"Tahoma, Verdana, Helvetica, Arial"><SPA= N=20 style=3D"FONT-SIZE: 10pt"><B>From:</B> Lizhong Jin [<A=20 href=3D"mailto:lizhong.jin@zte.com.cn">mailto:lizhong.jin@zte.com.cn</A= >]=20 <BR><B>Sent:</B> Wednesday, February 29, 2012 4:57 PM<BR><B>To:</B>=20 Aissaoui, Mustapha (Mustapha)<BR><B>Cc:</B> <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A>; Dutta, Pranjal K (Pranjal); <= A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A><BR></SPAN></= FONT></FONT><FONT=20 face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR><B>Subject:</B> RE: [mpls] Comments on=20 draft-ietf-mpls-ldp-ipv6-06<BR></SPAN></FONT><FONT=20 face=3D"Times New Roman"><SPAN=20 style=3D"FONT-SIZE: 12pt"> <BR><BR></SPAN></FONT><FONT size=3D2><F= ONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 1= 0pt">Hi=20 Mustapha,</SPAN></FONT></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 1= 1pt">=20 <BR></SPAN><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">I agree, and = I also=20 prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first= =20 email.</SPAN></FONT><SPAN style=3D"FONT-SIZE: 11pt"> <BR><BR></SPAN><FO= NT=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt">Thanks</SPAN></FONT><SPAN=20 style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">Lizhong</SPAN></FONT><SPAN style=3D"FONT-SIZE= : 11pt">=20 <BR></SPAN><FONT size=3D1><SPAN=20 style=3D"FONT-SIZE: 7pt"> </SPAN></FONT><SPAN style=3D"FONT-SIZE: = 11pt">=20 <BR><BR></SPAN><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">"Aissaoui= ,=20 Mustapha (Mustapha)" <<A=20 href=3D"mustapha.aissaoui@alcatel-lucent.com">mustapha.aissaoui@alcatel= -lucent.com</A>>=20 wrote 2012/03/01 04:35:41:<BR><BR>> Hi Lizhong,</SPAN></FONT><SPAN=20 style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> I actually think that we would need to d= efine a=20 new one which will <BR>> accomodate an IPv6 /128 address. Otherwise,= =20 targeted LDP sessions in<BR>> a all-IPv6 network will not be possibl= e. I=20 cannot see that operators<BR>> will start maintaining a mapping of s= ome=20 global non routable LSR-id <BR>> value to an IPv6 loopback interface= on=20 each router in the network.</SPAN></FONT><SPAN style=3D"FONT-SIZE: 11pt= ">=20 <BR></SPAN><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">>=20  </SPAN></FONT><SPAN style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> Mustapha.</SPAN></FONT><S= PAN=20 style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> From: <A=20 href=3D"mpls-bounces@ietf.org">mpls-bounces@ietf.org</A> [<A=20 href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</A>]= On=20 Behalf Of <BR>> Aissaoui, Mustapha (Mustapha)<BR>> Sent: Tuesday,= =20 February 07, 2012 10:12 AM<BR>> To: Lizhong Jin; Dutta, Pranjal K=20 (Pranjal); <A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A><BR>> Cc: = <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>> Subject: Re: [mpls] Co= mments=20 on draft-ietf-mpls-ldp-ipv6-06<BR></SPAN></FONT><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> Lizhong,</SPAN></FONT><SPAN=20 style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> the existing LSR-id will do the job and = should=20 be supported since <BR>> the LSR-id need not be an IP address. Most= =20 implementations will <BR>> actually populate the field with a /32 ad= dress=20 in IPv4 and thus If <BR>> necessary we could define a new format to = allow=20 the use of /128 IPv6addresses.</SPAN></FONT><SPAN style=3D"FONT-SIZE: 1= 1pt">=20 <BR></SPAN><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">>=20  </SPAN></FONT><SPAN style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT=20 size=3D2><SPAN style=3D"FONT-SIZE: 10pt">> Mustapha.</SPAN></FONT><S= PAN=20 style=3D"FONT-SIZE: 11pt"> <BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> <BR>> From: Lizhong Jin [<A=20 href=3D"mailto:lizhong.jin@zte.com.cn">mailto:lizhong.jin@zte.com.cn</A= >]=20 <BR>> Sent: Monday, February 06, 2012 10:23 PM<BR>> To: Dutta, Pr= anjal=20 K (Pranjal); <A href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com<= /A>;=20 Aissaoui, <BR>> Mustapha (Mustapha)<BR>> Cc: <A=20 href=3D"mpls@ietf.org">mpls@ietf.org</A><BR>> Subject: Re: [mpls] Co= mments=20 on draft-ietf-mpls-ldp-ipv6-06<BR></SPAN></FONT><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR></SPAN><FONT size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt">> <BR>> Hi, <BR>> I wonder if it is= =20 feasible to use LDP capability to advertise IPv6 <BR>> FEC without I= Pv6=20 adjacency, and only use one adjacency for LDP <BR>> session in dual-= stack=20 network. LDP capability is per node <BR>> capability, not per interf= ace=20 capability. But for LDP to choose the <BR>> correct downstream sessi= on=20 and output interface for each FEC, it <BR>> should also check if the= =20 output interface is LDP enabled or not. The<BR>> link adjacency coul= d be=20 used to assist such kind of checking. <BR>> <BR>> However, IMO, i= t is=20 valuable to allow two independent LDP sessions <BR>> for IPv4 and IP= v6 as=20 an option. Regarding the format definition in <BR>> RFC5036, we may = need=20 new LDP version number to identify IPv6 LSR-ID.<BR>> Or we use diffe= rent=20 32bit LSR-ID for IPv6 with IPv4, but I prefer <BR>> new format of LS= R-ID.=20 <BR>> <BR>> Regards <BR>> Lizhong <BR>> <BR>> <BR>> &= gt;=20 ----------------------------------------------------------------------<= BR>>=20 > <BR>> > Message: 1<BR>> > Date: Tue, 7 Feb 2012 05:28:= 21=20 +0530<BR>> > From: "Dutta, Pranjal K (Pranjal)" <<A=20 href=3D"pranjal.dutta@alcatel-lucent.com">pranjal.dutta@alcatel-lucent.= com</A>><BR>>=20 > To: Vishwas Manral <<A=20 href=3D"vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</A>><BR>> = >=20 Cc: "Aissaoui, Mustapha \(Mustapha\)"<BR>> >    <<A= =20 href=3D"mustapha.aissaoui@alcatel-lucent.com">mustapha.aissaoui@alcatel= -lucent.com</A>>,=20   "<A href=3D"mpls@ietf.org">mpls@ietf.org</A>"<BR>> >  = ;=20  <<A href=3D"mpls@ietf.org">mpls@ietf.org</A>><BR>> >= =20 Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06<BR>> >= ;=20 Message-ID:<BR>> >    <<A=20 href=3D"C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in">C= 584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in</A>.<BR>>=20 > alcatel-lucent.com <<A=20 href=3D"http://alcatel-lucent.com">http://alcatel-lucent.com</A>>=20 ><BR>> >    <BR>> > Content-Type: text/plain;= =20 charset=3D"us-ascii"<BR>> > <BR>> > I would rather for comp= lete=20 separation with multiple lsr-id because <BR>> > having separate l= ink=20 adjacencies does not really solved any problem.<BR>> > Since hell= o=20 adjacencies are associated with a link, still fate <BR>> > sharin= g=20 would continue over the single ldp/tcp session for IPV4 and IPV6.<BR>&g= t;=20 > Having IPV4 and IPV6 specific hello adjacencies over a link would= =20 <BR>> > only decide whether such a link is to be programmed for I= PV4=20 or IPV6<BR>> > egress traffic but I see it as overkill and unnece= ssary=20 scalability impacts.<BR>> > <BR>> > Thanks,<BR>> >=20 Pranjal<BR>> > <BR>>=20 --------------------------------------------------------<BR>> ZTE=20 Information Security Notice: The information contained in this <BR>>= mail=20 is solely property of the sender's organization. This mail <BR>>=20 communication is confidential. Recipients named above are obligated <BR= >>=20 to maintain secrecy and are not permitted to disclose the contents <BR>= >=20 of this communication to others.<BR>> This email and any files=20 transmitted with it are confidential and <BR>> intended solely for t= he=20 use of the individual or entity to whom they<BR>> are addressed. If = you=20 have received this email in error please <BR>> notify the originator= of=20 the message. Any views expressed in this <BR>> message are those of = the=20 individual sender.<BR>> This message has been scanned for viruses an= d=20 Spam by ZTE Anti-Spam system.<BR></SPAN></FONT></FONT></P></BLOCKQUOTE>= <FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20 style=3D"FONT-SIZE: 11pt"><BR><BR> <HR align=3Dcenter SIZE=3D3 width=3D"95%"> </SPAN></FONT><FONT size=3D2><FONT face=3D"Consolas, Courier New, Courier= "><SPAN=20 style=3D"FONT-SIZE: 10pt">_______________________________________________= <BR>mpls=20 mailing list<BR><A href=3D"mpls@ietf.org">mpls@ietf.org</A><BR><A=20 href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/= mailman/listinfo/mpls</A><BR></SPAN></FONT></FONT></BLOCKQUOTE><FONT=20 size=3D2><FONT face=3D"Consolas, Courier New, Courier"><SPAN=20 style=3D"FONT-SIZE: 10pt"><BR></SPAN></FONT></FONT><FONT=20 face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE: 11pt"= >--=20 <BR></SPAN></FONT><FONT size=3D1><FONT face=3D"Courier, Courier New"><SPAN= =20 style=3D"FONT-SIZE: 9pt">Syed Kamran Raza<BR>Technical Leader, SPRSG IOS-XR= =20 Routing (MPLS)<BR>Cisco Systems, Inc., <BR>Kanata, ON, K2K 3E8, Canada <BR>= Ph:=20 +1 (613) 254-4520<BR><FONT color=3D#0f32ef><U><A=20 href=3D"http://www.cisco.com">http://www.cisco.com</A></U></FONT>=20 <BR></SPAN></FONT></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial">= <SPAN=20 style=3D"FONT-SIZE: 11pt"><BR><BR><BR></SPAN></FONT></BODY></HTML> --_000_5DF53972F7E9134782DCE51624466FE50AD5811502USNAVSXCHMBSC_-- From shane@castlepoint.net Thu Mar 1 07:45:30 2012 Return-Path: <shane@castlepoint.net> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2C21E808C for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 07:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ae0Cv6E9CDW for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 07:45:29 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 265E321E8075 for <mpls@ietf.org>; Thu, 1 Mar 2012 07:45:29 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 99D9126806D; Thu, 1 Mar 2012 08:45:28 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 01 Mar 2012 08:45:28 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56032; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C83950B4-90E1-48FB-B416-8BD7B8C472FA" From: Shane Amante <shane@castlepoint.net> In-Reply-To: <CB7467C0.26ACD%skraza@cisco.com> Date: Thu, 1 Mar 2012 08:45:27 -0700 Message-Id: <A7BFD490-F563-44BB-BD65-B8012CC34468@castlepoint.net> References: <CB7467C0.26ACD%skraza@cisco.com> To: Kamran Raza <skraza@cisco.com> X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" <mustapha.aissaoui@alcatel-lucent.com>, Lizhong Jin <lizhong.jin@zte.com.cn>, "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Mar 2012 15:45:30 -0000 --Apple-Mail=_C83950B4-90E1-48FB-B416-8BD7B8C472FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > Firstly, I don=92t agree that LSR Id be made IPv6 (address) based = and/or route-able; LSR Id, as defined in the base spec, is just a 4 = octet unique id and need not be routable, though most implementations = currently populate it with /32 loopback address. Let=92s not carry = forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that = in the networks I operate it is *always* routable. =46rom a simple = troubleshooting PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ = location of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the = 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us = not underestimate that. All I'm saying is, let's not go out of our way = to try to make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for = purely theoretical reasons. -shane > Secondly, If there is a need to define new =93LDP Identifier=94 in = order to establish/maintain a separate session for IPv6 AF, this should = be a protocol change =97 i.e. we should bump up LDP protocol version in = LDP PDU header for this, and possibly define new format for =93LDP = Identifier=94 in the context of new LDP protocol version.=20 >=20 > My 2 cents.=20 >=20 > On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com> wrote: >=20 >> Hi Lizhong/ Pranjal/ Mustapha, >>=20 >> So the two main comments that have come after last call are: >>=20 >> 1. Allow for separation of sessions along with the adjacency. >> 2. Allow for an IPv6 based LSR-ID. >>=20 >> The second could lead to changes required in both OSPF and IS-IS, as = well because the new LSR ID would then need to be exchanged. We could = treat it as an enhancement instead in my view. Do you agree? >>=20 >> Thanks, >> Vishwas >>=20 >> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) = <pranjal.dutta@alcatel-lucent.com> wrote: >>> Yes, I support that too. There would be network management issues = with mapping of 4 byte LSR-ID to an IPV6 remote address. >>> Most of the implementations I know off usually maps 4 byte of the = LSR-ID with a local ipv4 interface address in the system. >>> =20 >>> Thanks, >>> Pranjal >>> =20 >>>=20 >>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]=20 >>> Sent: Wednesday, February 29, 2012 4:57 PM >>> To: Aissaoui, Mustapha (Mustapha) >>> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); = vishwas.ietf@gmail.com >>>=20 >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> =20 >>>=20 >>> Hi Mustapha,=20 >>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I = pointed out in my first email.=20 >>>=20 >>> Thanks=20 >>> Lizhong=20 >>> =20 >>>=20 >>> "Aissaoui, Mustapha (Mustapha)" = <mustapha.aissaoui@alcatel-lucent.com> wrote 2012/03/01 04:35:41: >>>=20 >>> > Hi Lizhong,=20 >>> > I actually think that we would need to define a new one which will=20= >>> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions = in >>> > a all-IPv6 network will not be possible. I cannot see that = operators >>> > will start maintaining a mapping of some global non routable = LSR-id=20 >>> > value to an IPv6 loopback interface on each router in the network.=20= >>> > =20 >>> > Mustapha.=20 >>> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of=20 >>> > Aissaoui, Mustapha (Mustapha) >>> > Sent: Tuesday, February 07, 2012 10:12 AM >>> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); = vishwas.ietf@gmail.com >>> > Cc: mpls@ietf.org >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> > Lizhong,=20 >>> > the existing LSR-id will do the job and should be supported since=20= >>> > the LSR-id need not be an IP address. Most implementations will=20 >>> > actually populate the field with a /32 address in IPv4 and thus If=20= >>> > necessary we could define a new format to allow the use of /128 = IPv6addresses.=20 >>> > =20 >>> > Mustapha.=20 >>> >=20 >>> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]=20 >>> > Sent: Monday, February 06, 2012 10:23 PM >>> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui,=20= >>> > Mustapha (Mustapha) >>> > Cc: mpls@ietf.org >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> >=20 >>> > Hi,=20 >>> > I wonder if it is feasible to use LDP capability to advertise IPv6=20= >>> > FEC without IPv6 adjacency, and only use one adjacency for LDP=20 >>> > session in dual-stack network. LDP capability is per node=20 >>> > capability, not per interface capability. But for LDP to choose = the=20 >>> > correct downstream session and output interface for each FEC, it=20= >>> > should also check if the output interface is LDP enabled or not. = The >>> > link adjacency could be used to assist such kind of checking.=20 >>> >=20 >>> > However, IMO, it is valuable to allow two independent LDP sessions=20= >>> > for IPv4 and IPv6 as an option. Regarding the format definition in=20= >>> > RFC5036, we may need new LDP version number to identify IPv6 = LSR-ID. >>> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer=20= >>> > new format of LSR-ID.=20 >>> >=20 >>> > Regards=20 >>> > Lizhong=20 >>> >=20 >>> >=20 >>> > > = ---------------------------------------------------------------------- >>> > >=20 >>> > > Message: 1 >>> > > Date: Tue, 7 Feb 2012 05:28:21 +0530 >>> > > From: "Dutta, Pranjal K (Pranjal)" = <pranjal.dutta@alcatel-lucent.com> >>> > > To: Vishwas Manral <vishwas.ietf@gmail.com> >>> > > Cc: "Aissaoui, Mustapha \(Mustapha\)" >>> > > <mustapha.aissaoui@alcatel-lucent.com>, "mpls@ietf.org" >>> > > <mpls@ietf.org> >>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> > > Message-ID: >>> > > = <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in. >>> > > alcatel-lucent.com <http://alcatel-lucent.com> > >>> > > =20 >>> > > Content-Type: text/plain; charset=3D"us-ascii" >>> > >=20 >>> > > I would rather for complete separation with multiple lsr-id = because=20 >>> > > having separate link adjacencies does not really solved any = problem. >>> > > Since hello adjacencies are associated with a link, still fate=20= >>> > > sharing would continue over the single ldp/tcp session for IPV4 = and IPV6. >>> > > Having IPV4 and IPV6 specific hello adjacencies over a link = would=20 >>> > > only decide whether such a link is to be programmed for IPV4 or = IPV6 >>> > > egress traffic but I see it as overkill and unnecessary = scalability impacts. >>> > >=20 >>> > > Thanks, >>> > > Pranjal >>> > >=20 >>> > -------------------------------------------------------- >>> > ZTE Information Security Notice: The information contained in this=20= >>> > mail is solely property of the sender's organization. This mail=20 >>> > communication is confidential. Recipients named above are = obligated=20 >>> > to maintain secrecy and are not permitted to disclose the contents=20= >>> > of this communication to others. >>> > This email and any files transmitted with it are confidential and=20= >>> > intended solely for the use of the individual or entity to whom = they >>> > are addressed. If you have received this email in error please=20 >>> > notify the originator of the message. Any views expressed in this=20= >>> > message are those of the individual sender. >>> > This message has been scanned for viruses and Spam by ZTE = Anti-Spam system. >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 > --=20 > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc.,=20 > Kanata, ON, K2K 3E8, Canada=20 > Ph: +1 (613) 254-4520 > http://www.cisco.com=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_C83950B4-90E1-48FB-B416-8BD7B8C472FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Kamran,<div><br><div><div>On Feb 29, 2012, at 9:39 PM, Kamran Raza = wrote:</div><blockquote type=3D"cite"><div><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size:11pt">Firstly, I = don=92t agree that LSR Id be made IPv6 (address) based and/or = route-able; LSR Id, as defined in the base spec, is just a 4 octet = unique id and need not be routable, though most implementations = currently populate it with /32 loopback address. Let=92s not carry = forward a wrong = notion/usage.<br></span></font></div></blockquote><div><br></div>Although,= in theory, the LSR-ID "need not be routable", I can say that in the = networks I operate it is *always* routable. =46rom a simple = troubleshooting PoV, it's extremely easy to:</div><div>a) ping the /32 = (4-octet) LSR-ID; or,</div><div>b) look at a routing table for the = existence of a /32 (4-octet) LSR-ID</div><div>b) use traceroute and/or a = routing table to learn the _topological_ location of the /32 (4-octet) = LSR-ID in the network ...</div><div><br></div><div>In summary, there is = a tremendous amount of operational value in the 4-Byte LSR-ID actually = be announced/routed in a network's IGP -- let us not underestimate that. = All I'm saying is, let's not go out of our way to try to make a "new" = 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical = reasons.</div><div><br></div><div>-shane</div><div><br></div><div><br><blo= ckquote type=3D"cite"><div><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">Secondly, If there is a need to = define new =93LDP Identifier=94 in order to establish/maintain a = separate session for IPv6 AF, this should be a protocol change =97 i.e. = we should bump up LDP protocol version in LDP PDU header for this, and = possibly define new format for =93LDP Identifier=94 in the context of = new LDP protocol version. <br> <br> My 2 cents. <br> <br> On 12-02-29 8:11 PM, "Vishwas Manral" <<a = href=3D"x-msg://1083/vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</a>>= ; wrote:<br> <br> </span></font><blockquote type=3D"cite"><font face=3D"Calibri, Verdana, = Helvetica, Arial"><span style=3D"font-size:11pt">Hi Lizhong/ Pranjal/ = Mustapha,<br> <br> So the two main comments that have come after last call are:<br> <br> 1. Allow for separation of sessions along with the adjacency.<br> 2. Allow for an IPv6 based LSR-ID.<br> <br> The second could lead to changes required in both OSPF and IS-IS, as = well because the new LSR ID would then need to be exchanged. We could = treat it as an enhancement instead in my view. Do you agree?<br> <br> Thanks,<br> Vishwas<br> <br> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <<a = href=3D"x-msg://1083/pranjal.dutta@alcatel-lucent.com">pranjal.dutta@alcat= el-lucent.com</a>> wrote:<br> </span></font><blockquote type=3D"cite"><font color=3D"#000080"><font = size=3D"2"><font face=3D"Arial"><span style=3D"font-size:10pt">Yes, I = support that too. There would be network management issues with mapping = of 4 byte LSR-ID to an IPV6 remote address.<br> Most of the implementations I know off usually maps 4 byte of the LSR-ID = with a local ipv4 interface address in the system.<br>  <br> Thanks,<br> Pranjal<br>  <br> </span></font></font></font><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"> </span></font><div> <font face=3D"Times New Roman"><span = style=3D"font-size:12pt"></span></font><br = class=3D"webkit-block-placeholder"></div><hr align=3D"CENTER" size=3D"3" = width=3D"100%"><div> <font size=3D"2"><font face=3D"Tahoma, Verdana, Helvetica, Arial"><span = style=3D"font-size:10pt"><b>From:</b> Lizhong Jin [<a = href=3D"mailto:lizhong.jin@zte.com.cn">mailto:lizhong.jin@zte.com.cn</a>] = <br> <b>Sent:</b> Wednesday, February 29, 2012 4:57 PM<br> <b>To:</b> Aissaoui, Mustapha (Mustapha)<br> <b>Cc:</b> <a href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a>; = Dutta, Pranjal K (Pranjal); <a = href=3D"x-msg://1083/vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</a><br= > </span></font></font><font face=3D"Tahoma, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"><br> <b>Subject:</b> RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06<br> </span></font><font face=3D"Times New Roman"><span = style=3D"font-size:12pt"> <br> <br> </span></font><font size=3D"2"><font face=3D"Calibri, Verdana, = Helvetica, Arial"><span style=3D"font-size:10pt">Hi = Mustapha,</span></font></font><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">I agree, and I = also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my = first email.</span></font><span style=3D"font-size:11pt"> <br> <br> </span><font size=3D"2"><span = style=3D"font-size:10pt">Thanks</span></font><span = style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span = style=3D"font-size:10pt">Lizhong</span></font><span = style=3D"font-size:11pt"> <br> </span><font size=3D"1"><span = style=3D"font-size:7pt"> </span></font><span = style=3D"font-size:11pt"> <br> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">"Aissaoui, = Mustapha (Mustapha)" <<a = href=3D"x-msg://1083/mustapha.aissaoui@alcatel-lucent.com">mustapha.aissao= ui@alcatel-lucent.com</a>> wrote 2012/03/01 04:35:41:<br> <br> > Hi Lizhong,</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> I actually = think that we would need to define a new one which will <br> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions = in<br> > a all-IPv6 network will not be possible. I cannot see that = operators<br> > will start maintaining a mapping of some global non routable LSR-id = <br> > value to an IPv6 loopback interface on each router in the = network.</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> =  </span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> = Mustapha.</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> From: <a = href=3D"x-msg://1083/mpls-bounces@ietf.org">mpls-bounces@ietf.org</a> = [<a = href=3D"mailto:mpls-bounces@ietf.org">mailto:mpls-bounces@ietf.org</a>] = On Behalf Of <br> > Aissaoui, Mustapha (Mustapha)<br> > Sent: Tuesday, February 07, 2012 10:12 AM<br> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); <a = href=3D"x-msg://1083/vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</a><br= > > Cc: <a href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a><br> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06<br> </span></font><span style=3D"font-size:11pt"><br> </span><font size=3D"2"><span style=3D"font-size:10pt">> = Lizhong,</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> the existing = LSR-id will do the job and should be supported since <br> > the LSR-id need not be an IP address. Most implementations will = <br> > actually populate the field with a /32 address in IPv4 and thus If = <br> > necessary we could define a new format to allow the use of /128 = IPv6addresses.</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> =  </span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> = Mustapha.</span></font><span style=3D"font-size:11pt"> <br> </span><font size=3D"2"><span style=3D"font-size:10pt">> <br> > From: Lizhong Jin [<a = href=3D"mailto:lizhong.jin@zte.com.cn">mailto:lizhong.jin@zte.com.cn</a>] = <br> > Sent: Monday, February 06, 2012 10:23 PM<br> > To: Dutta, Pranjal K (Pranjal); <a = href=3D"x-msg://1083/vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</a>; = Aissaoui, <br> > Mustapha (Mustapha)<br> > Cc: <a href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a><br> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06<br> </span></font><span style=3D"font-size:11pt"><br> </span><font size=3D"2"><span style=3D"font-size:10pt">> <br> > Hi, <br> > I wonder if it is feasible to use LDP capability to advertise IPv6 = <br> > FEC without IPv6 adjacency, and only use one adjacency for LDP <br> > session in dual-stack network. LDP capability is per node <br> > capability, not per interface capability. But for LDP to choose the = <br> > correct downstream session and output interface for each FEC, it = <br> > should also check if the output interface is LDP enabled or not. = The<br> > link adjacency could be used to assist such kind of checking. <br> > <br> > However, IMO, it is valuable to allow two independent LDP sessions = <br> > for IPv4 and IPv6 as an option. Regarding the format definition in = <br> > RFC5036, we may need new LDP version number to identify IPv6 = LSR-ID.<br> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer = <br> > new format of LSR-ID. <br> > <br> > Regards <br> > Lizhong <br> > <br> > <br> > > = ----------------------------------------------------------------------<br>= > > <br> > > Message: 1<br> > > Date: Tue, 7 Feb 2012 05:28:21 +0530<br> > > From: "Dutta, Pranjal K (Pranjal)" <<a = href=3D"x-msg://1083/pranjal.dutta@alcatel-lucent.com">pranjal.dutta@alcat= el-lucent.com</a>><br> > > To: Vishwas Manral <<a = href=3D"x-msg://1083/vishwas.ietf@gmail.com">vishwas.ietf@gmail.com</a>>= ;<br> > > Cc: "Aissaoui, Mustapha \(Mustapha\)"<br> > >    <<a = href=3D"x-msg://1083/mustapha.aissaoui@alcatel-lucent.com">mustapha.aissao= ui@alcatel-lucent.com</a>>,   "<a = href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a>"<br> > >    <<a = href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a>><br> > > Subject: Re: [mpls] Comments on = draft-ietf-mpls-ldp-ipv6-06<br> > > Message-ID:<br> > >    <<a = href=3D"x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHM= BSA3.in">C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in</a>.= <br> > > <a href=3D"http://alcatel-lucent.com">alcatel-lucent.com</a> = <<a = href=3D"http://alcatel-lucent.com/">http://alcatel-lucent.com</a>> = ><br> > >    <br> > > Content-Type: text/plain; charset=3D"us-ascii"<br> > > <br> > > I would rather for complete separation with multiple lsr-id = because <br> > > having separate link adjacencies does not really solved any = problem.<br> > > Since hello adjacencies are associated with a link, still fate = <br> > > sharing would continue over the single ldp/tcp session for = IPV4 and IPV6.<br> > > Having IPV4 and IPV6 specific hello adjacencies over a link = would <br> > > only decide whether such a link is to be programmed for IPV4 = or IPV6<br> > > egress traffic but I see it as overkill and unnecessary = scalability impacts.<br> > > <br> > > Thanks,<br> > > Pranjal<br> > > <br> > --------------------------------------------------------<br> > ZTE Information Security Notice: The information contained in this = <br> > mail is solely property of the sender's organization. This mail = <br> > communication is confidential. Recipients named above are obligated = <br> > to maintain secrecy and are not permitted to disclose the contents = <br> > of this communication to others.<br> > This email and any files transmitted with it are confidential and = <br> > intended solely for the use of the individual or entity to whom = they<br> > are addressed. If you have received this email in error please <br> > notify the originator of the message. Any views expressed in this = <br> > message are those of the individual sender.<br> > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.<br> </span></font></font></div></blockquote><font face=3D"Calibri, Verdana, = Helvetica, Arial"><span style=3D"font-size:11pt"><br> <br> <hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><font = size=3D"2"><font face=3D"Consolas, Courier New, Courier"><span = style=3D"font-size:10pt">_______________________________________________<b= r> mpls mailing list<br> <a href=3D"x-msg://1083/mpls@ietf.org">mpls@ietf.org</a><br> <a = href=3D"https://www.ietf.org/mailman/listinfo/mpls">https://www.ietf.org/m= ailman/listinfo/mpls</a><br> </span></font></font></blockquote><font size=3D"2"><font face=3D"Consolas,= Courier New, Courier"><span style=3D"font-size:10pt"><br> </span></font></font><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">-- <br> </span></font><font size=3D"1"><font face=3D"Courier, Courier New"><span = style=3D"font-size:9pt">Syed Kamran Raza<br> Technical Leader, SPRSG IOS-XR Routing (MPLS)<br> Cisco Systems, Inc., <br> Kanata, ON, K2K 3E8, Canada <br> Ph: +1 (613) 254-4520<br> <font color=3D"#0F32EF"><u><a = href=3D"http://www.cisco.com/">http://www.cisco.com</a></u></font> <br> </span></font></font><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"><br> <br> <br> </span></font> </div> _______________________________________________<br>mpls mailing = list<br><a = href=3D"mailto:mpls@ietf.org">mpls@ietf.org</a><br>https://www.ietf.org/ma= ilman/listinfo/mpls<br></blockquote></div><br></div></body></html>= --Apple-Mail=_C83950B4-90E1-48FB-B416-8BD7B8C472FA-- From shane@castlepoint.net Thu Mar 1 07:51:35 2012 Return-Path: <shane@castlepoint.net> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D2721E81EC for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 07:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxJOAUU7jYmd for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 07:51:35 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6321E8067 for <mpls@ietf.org>; Thu, 1 Mar 2012 07:51:34 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id AB03A26806D; Thu, 1 Mar 2012 08:51:34 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 01 Mar 2012 08:51:34 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56068; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante <shane@castlepoint.net> In-Reply-To: <201203011203.12854.mtinka@globaltransit.net> Date: Thu, 1 Mar 2012 08:51:33 -0700 Content-Transfer-Encoding: 7bit Message-Id: <64E677AD-6ED5-488C-8FA3-90F81D411D04@castlepoint.net> References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <201203011203.12854.mtinka@globaltransit.net> To: mtinka@globaltransit.net X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" <mustapha.aissaoui@alcatel-lucent.com>, mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Mar 2012 15:51:35 -0000 On Feb 29, 2012, at 9:03 PM, Mark Tinka wrote: > On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva) > wrote: > >> Nonetheless, an implementation could choose to optimize, >> if needed, to keep both address-family related info in a >> single adjacency structure, but this is all >> implementation specific. :) > > I agree, and as mentioned earlier, as an operator, I'd > rather this isn't the default. If a default needs to be > implemented by a vendor, then AF separation would be my > preference. > > However, I'd support including knobs to allow operators to > consolidate, if they so wished. Well said, Mark. As an operator, as well, I concur with both points. -shane From skraza@cisco.com Thu Mar 1 09:57:53 2012 Return-Path: <skraza@cisco.com> X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446BA21E8108 for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 09:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.327 X-Spam-Level: X-Spam-Status: No, score=-8.327 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJMicWdc-Fvc for <mpls@ietfa.amsl.com>; Thu, 1 Mar 2012 09:57:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 288BC21E80F9 for <mpls@ietf.org>; Thu, 1 Mar 2012 09:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=26291; q=dns/txt; s=iport; t=1330624668; x=1331834268; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=+wu/luus0tQJvuZ6X+dJ5Ca38pa6XKcuwhgacexzFDY=; b=PSTTUe1txWWN3EtQmY9eDaYD6sLag/bCuTKmTMw3xJCG6cmgBnfToAfA 1DejvJSa1gDTLMVmIARskpEW/aA25BSxZUk5zcHt0ycNsTsi/+z19DHYG 9meZ44obzGXT4NFTGx7fFzmYz+qoqeAMv2EPV7wKhnaE/HS1qS4RImuxt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFa3T0+tJXG//2dsb2JhbAA5BwOCUaA1kBtugQeBfQEBAQMBAQEBDwEqGBEICwUNAQgRAwEBAQEgBygGHwkIAQEEDgUih18FC6BAAZcIiRtiCYJ4BwECAwIJAQQEAwEKAUEOAQaEXRQGAwUETwEKDgQCAQcQAQEJgycEiBwzjGyLG4d1gT4 X-IronPort-AV: E=Sophos;i="4.73,511,1325462400"; d="scan'208,217";a="63068203" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 01 Mar 2012 17:57:47 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q21HvlNJ032483; Thu, 1 Mar 2012 17:57:47 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 11:57:47 -0600 Received: from 10.86.250.44 ([10.86.250.44]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Mar 2012 17:57:46 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 01 Mar 2012 12:57:44 -0500 From: Kamran Raza <skraza@cisco.com> To: Shane Amante <shane@castlepoint.net> Message-ID: <CB7522C8.26B42%skraza@cisco.com> Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz31M2DM7ceawqxoUmQKkvmlXWNOA== In-Reply-To: <A7BFD490-F563-44BB-BD65-B8012CC34468@castlepoint.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413451464_4702060" X-OriginalArrivalTime: 01 Mar 2012 17:57:47.0165 (UTC) FILETIME=[CF66CCD0:01CCF7D4] Cc: "Aissaoui, Mustapha \(Mustapha\)" <mustapha.aissaoui@alcatel-lucent.com>, Lizhong Jin <lizhong.jin@zte.com.cn>, "mpls@ietf.org" <mpls@ietf.org> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 01 Mar 2012 17:57:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413451464_4702060 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Shane, Right, but the problem with =B3interpreting 4-byte LSR-Id as routeable=B2 is that it does not work for LDP IPv6 peering with existing base spec/extensions. To keep using this interpretation/usage for IPv6, one is forced to define 16-byte long LSR-Id (and LDP protocol change). As the side affect, this also =B3enforces=B2 (results in) 2 sessions with the same LSR when used in dual-stack scenarios. -- Kamran On 12-03-01 10:45 AM, "Shane Amante" <shane@castlepoint.net> wrote: > Kamran, >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >> Firstly, I don=B9t agree that LSR Id be made IPv6 (address) based and/or >> route-able; LSR Id, as defined in the base spec, is just a 4 octet uniqu= e id >> and need not be routable, though most implementations currently populate= it >> with /32 loopback address. Let=B9s not carry forward a wrong notion/usage. >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that in= the > networks I operate it is *always* routable. From a simple troubleshooting= PoV, > it's extremely easy to: > a) ping the /32 (4-octet) LSR-ID; or, > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > b) use traceroute and/or a routing table to learn the _topological_ locat= ion > of the /32 (4-octet) LSR-ID in the network ... >=20 > In summary, there is a tremendous amount of operational value in the 4-By= te > LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try= to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoreti= cal > reasons. >=20 > -shane >=20 >=20 >> Secondly, If there is a need to define new =B3LDP Identifier=B2 in order to >> establish/maintain a separate session for IPv6 AF, this should be a prot= ocol >> change =8B i.e. we should bump up LDP protocol version in LDP PDU header f= or >> this, and possibly define new format for =B3LDP Identifier=B2 in the context= of >> new LDP protocol version. >>=20 >> My 2 cents.=20 >>=20 >> On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com >> <x-msg://1083/vishwas.ietf@gmail.com> > wrote: >>=20 >>> Hi Lizhong/ Pranjal/ Mustapha, >>>=20 >>> So the two main comments that have come after last call are: >>>=20 >>> 1. Allow for separation of sessions along with the adjacency. >>> 2. Allow for an IPv6 based LSR-ID. >>>=20 >>> The second could lead to changes required in both OSPF and IS-IS, as we= ll >>> because the new LSR ID would then need to be exchanged. We could treat = it as >>> an enhancement instead in my view. Do you agree? >>>=20 >>> Thanks, >>> Vishwas >>>=20 >>> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) >>> <pranjal.dutta@alcatel-lucent.com >>> <x-msg://1083/pranjal.dutta@alcatel-lucent.com> > wrote: >>>> Yes, I support that too. There would be network management issues with >>>> mapping of 4 byte LSR-ID to an IPV6 remote address. >>>> Most of the implementations I know off usually maps 4 byte of the LSR-= ID >>>> with a local ipv4 interface address in the system. >>>> =20 >>>> Thanks, >>>> Pranjal >>>> =20 >>>>=20 >>>>=20 >>>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>>> Sent: Wednesday, February 29, 2012 4:57 PM >>>> To: Aissaoui, Mustapha (Mustapha) >>>> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; Dutta, Pranjal K >>>> (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com= > >>>>=20 >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> =20 >>>>=20 >>>> Hi Mustapha,=20 >>>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I po= inted >>>> out in my first email. >>>>=20 >>>> Thanks=20 >>>> Lizhong=20 >>>> =20 >>>>=20 >>>> "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com >>>> <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com> > wrote 2012/03/01 >>>> 04:35:41: >>>>=20 >>>>> > Hi Lizhong, >>>>> > I actually think that we would need to define a new one which will >>>>> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions i= n >>>>> > a all-IPv6 network will not be possible. I cannot see that operator= s >>>>> > will start maintaining a mapping of some global non routable LSR-id >>>>> > value to an IPv6 loopback interface on each router in the network. >>>>> > =20 >>>>> > Mustapha.=20 >>>>> > From: mpls-bounces@ietf.org <x-msg://1083/mpls-bounces@ietf.org> >>>>> [mailto:mpls-bounces@ietf.org] On Behalf Of >>>>> > Aissaoui, Mustapha (Mustapha) >>>>> > Sent: Tuesday, February 07, 2012 10:12 AM >>>>> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >>>>> <x-msg://1083/vishwas.ietf@gmail.com> >>>>> > Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> >>>>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>>> > Lizhong,=20 >>>>> > the existing LSR-id will do the job and should be supported since >>>>> > the LSR-id need not be an IP address. Most implementations will >>>>> > actually populate the field with a /32 address in IPv4 and thus If >>>>> > necessary we could define a new format to allow the use of /128 >>>>> IPv6addresses. >>>>> > =20 >>>>> > Mustapha.=20 >>>>> >=20 >>>>> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>>>> > Sent: Monday, February 06, 2012 10:23 PM >>>>> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >>>>> <x-msg://1083/vishwas.ietf@gmail.com> ; Aissaoui, >>>>> > Mustapha (Mustapha) >>>>> > Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> >>>>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>>> >=20 >>>>> > Hi,=20 >>>>> > I wonder if it is feasible to use LDP capability to advertise IPv6 >>>>> > FEC without IPv6 adjacency, and only use one adjacency for LDP >>>>> > session in dual-stack network. LDP capability is per node >>>>> > capability, not per interface capability. But for LDP to choose the >>>>> > correct downstream session and output interface for each FEC, it >>>>> > should also check if the output interface is LDP enabled or not. Th= e >>>>> > link adjacency could be used to assist such kind of checking. >>>>> >=20 >>>>> > However, IMO, it is valuable to allow two independent LDP sessions >>>>> > for IPv4 and IPv6 as an option. Regarding the format definition in >>>>> > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID= . >>>>> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer >>>>> > new format of LSR-ID. >>>>> >=20 >>>>> > Regards=20 >>>>> > Lizhong=20 >>>>> >=20 >>>>> >=20 >>>>>> > >=20 >>>>>> --------------------------------------------------------------------= -- >>>>>> > >=20 >>>>>> > > Message: 1 >>>>>> > > Date: Tue, 7 Feb 2012 05:28:21 +0530 >>>>>> > > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent= .com >>>>>> <x-msg://1083/pranjal.dutta@alcatel-lucent.com> > >>>>>> > > To: Vishwas Manral <vishwas.ietf@gmail.com >>>>>> <x-msg://1083/vishwas.ietf@gmail.com> > >>>>>> > > Cc: "Aissaoui, Mustapha \(Mustapha\)" >>>>>> > > <mustapha.aissaoui@alcatel-lucent.com >>>>>> <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.= org >>>>>> <x-msg://1083/mpls@ietf.org> " >>>>>> > > <mpls@ietf.org <x-msg://1083/mpls@ietf.org> > >>>>>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>>> > > Message-ID: >>>>>> > > <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in >>>>>>=20 <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.i>>= >>>> n> . >>>>>> > > alcatel-lucent.com <http://alcatel-lucent.com> >>>>>> <http://alcatel-lucent.com <http://alcatel-lucent.com/> > > >>>>>> > > =20 >>>>>> > > Content-Type: text/plain; charset=3D"us-ascii" >>>>>> > >=20 >>>>>> > > I would rather for complete separation with multiple lsr-id beca= use >>>>>> > > having separate link adjacencies does not really solved any prob= lem. >>>>>> > > Since hello adjacencies are associated with a link, still fate >>>>>> > > sharing would continue over the single ldp/tcp session for IPV4 = and >>>>>> IPV6. >>>>>> > > Having IPV4 and IPV6 specific hello adjacencies over a link woul= d >>>>>> > > only decide whether such a link is to be programmed for IPV4 or = IPV6 >>>>>> > > egress traffic but I see it as overkill and unnecessary scalabil= ity >>>>>> impacts. >>>>>> > >=20 >>>>>> > > Thanks, >>>>>> > > Pranjal >>>>>> > >=20 >>>>> > -------------------------------------------------------- >>>>> > ZTE Information Security Notice: The information contained in this >>>>> > mail is solely property of the sender's organization. This mail >>>>> > communication is confidential. Recipients named above are obligated >>>>> > to maintain secrecy and are not permitted to disclose the contents >>>>> > of this communication to others. >>>>> > This email and any files transmitted with it are confidential and >>>>> > intended solely for the use of the individual or entity to whom the= y >>>>> > are addressed. If you have received this email in error please >>>>> > notify the originator of the message. Any views expressed in this >>>>> > message are those of the individual sender. >>>>> > This message has been scanned for viruses and Spam by ZTE Anti-Spam >>>>> system. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org <x-msg://1083/mpls@ietf.org> >>> https://www.ietf.org/mailman/listinfo/mpls --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3413451464_4702060 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Shane,

Right, but the problem with “interpreting 4-byte LSR-Id as routeable&= #8221; is that it does not work for LDP IPv6 peering with existing base spec= /extensions. To keep using this interpretation/usage for IPv6, one is forced= to define 16-byte long LSR-Id (and LDP protocol change). As the side affect= , this also “enforces” (results in) 2 sessions with the same LSR= when used in dual-stack scenarios.

-- Kamran

On 12-03-01 10:45 AM, "Shane Amante" <shane@castlepoint.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Kamran,

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:
<= SPAN STYLE=3D'font-size:11pt'>Firstly, I don’t agree that LSR Id be made= IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec= , is just a 4 octet unique id and need not be routable, though most implemen= tations currently populate it with /32 loopback address. Let’s not car= ry forward a wrong notion/usage.
=
Although, in theory, the LSR-ID "need not be routable", I can say= that in the networks I operate it is *always* routable. From a simple troub= leshooting PoV, it's extremely easy to:
a) ping the /32 (4-octet) LSR-ID; or,
b) look at a routing table for the existence of a /32 (4-octet) LSR-ID
b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ...

In summary, there is a tremendous amount of operational value in the 4-Byte= LSR-ID actually be announced/routed in a network's IGP -- let us not undere= stimate that. All I'm saying is, let's not go out of our way to try to make = a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theore= tical reasons.

-shane


<= SPAN STYLE=3D'font-size:11pt'>Secondly, If there is a need to define new ̶= 0;LDP Identifier” in order to establish/maintain a separate session fo= r IPv6 AF, this should be a protocol change — i.e. we should bump up L= DP protocol version in LDP PDU header for this, and possibly define new form= at for “LDP Identifier” in the context of new LDP protocol versi= on.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com> > wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as = an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com <x-m= sg://1083/pranjal.dutta@al= catel-lucent.com> > wrote:
Yes, I support that too. There would be = network management issues with mapping of 4 byte LSR-ID to an IPV6 remote ad= dress.
Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

From= : Lizhong Jin [mailto:lizhong.ji= n@zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; Dutta, Pranjal K (Pranjal)= ; vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

I agree, and I also pref= er to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong


"Aissaoui, Mustapha= (Mustapha)" <mustaph= a.aissaoui@alcatel-lucent.com <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com> &g= t; wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think th= at we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-bounces@ietf.org <x-msg://1083/mpls-bounces@ietf.org>  [mailto:mpls-bounces@ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id= will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6ad= dresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizh= ong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishw= as.ietf@gmail.com <x-msg://10= 83/vishwas.ietf@gmail.com> ; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > -----------------------------------------------------------------= -----
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com <x-msg://1083/pranjal.dutta@alcatel= -lucent.com> >
> > To: Vishwas Manral <vishwas.i= etf@gmail.com <x-msg://1083/v= ishwas.ietf@gmail.com> >
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui@alcatel-lucent.com <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com= > >,   "mpls@ietf.org &= lt;x-msg://1083/mpls@ietf.org> "<= BR> > >    <mpls@ietf.org &= lt;x-msg://1083/mpls@ietf.org> > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBAN= SXCHMBSA3.in <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D6= 67@INBANSXCHMBSA3.in> .
> > alcatel-lucent.com <http:/= /alcatel-lucent.com>  <ht= tp://alcatel-lucent.com <http://= alcatel-lucent.com/> > >
> >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam sy= stem.


___________= ____________________________________
mpls mailing list
mpls@ietf.org <x-msg://1083/mpls@ietf.org>
https://www.ietf.org/m= ailman/listinfo/mpls
= --
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3413451464_4702060-- From pranjal.dutta@alcatel-lucent.com Thu Mar 1 10:04:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5A21F87EC for ; Thu, 1 Mar 2012 10:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.273 X-Spam-Level: X-Spam-Status: No, score=-7.273 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gfMX1vzROXg for ; Thu, 1 Mar 2012 10:04:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5B07321E8115 for ; Thu, 1 Mar 2012 10:04:19 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q21I3wbM014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 12:04:01 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21I3uBs026702 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 23:33:56 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 1 Mar 2012 23:33:56 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , Shane Amante Date: Thu, 1 Mar 2012 23:33:51 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz31M2DM7ceawqxoUmQKkvmlXWNOAAAKCpw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CA907INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:04:24 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CA907INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kamran, We were mentioning about multi-lsr sessions for fate sep= aration anyway. Having 16 byte long LSR-ID would automatically fall back t= o multi-lsr sessions in dual stack situations. Thanks, Pranjal ________________________________ From: Kamran Raza [mailto:skraza@cisco.com] Sent: Thursday, March 01, 2012 9:58 AM To: Shane Amante Cc: Vishwas Manral; Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustaph= a); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Shane, Right, but the problem with "interpreting 4-byte LSR-Id as routeable" is th= at it does not work for LDP IPv6 peering with existing base spec/extensions= . To keep using this interpretation/usage for IPv6, one is forced to define= 16-byte long LSR-Id (and LDP protocol change). As the side affect, this al= so "enforces" (results in) 2 sessions with the same LSR when used in dual-s= tack scenarios. -- Kamran On 12-03-01 10:45 AM, "Shane Amante" wrote: Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or rout= e-able; LSR Id, as defined in the base spec, is just a 4 octet unique id an= d need not be routable, though most implementations currently populate it w= ith /32 loopback address. Let's not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in t= he networks I operate it is *always* routable. From a simple troubleshootin= g PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the 4-Byte= LSR-ID actually be announced/routed in a network's IGP -- let us not under= estimate that. All I'm saying is, let's not go out of our way to try to mak= e a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical r= easons. -shane Secondly, If there is a need to define new "LDP Identifier" in order to est= ablish/maintain a separate session for IPv6 AF, this should be a protocol c= hange - i.e. we should bump up LDP protocol version in LDP PDU header for t= his, and possibly define new format for "LDP Identifier" in the context of = new LDP protocol version. My 2 cents. On 12-02-29 8:11 PM, "Vishwas Manral" > wrote: Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranjal)= ; vishwas.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com ; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org " > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > . > > alcatel-lucent.com > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --_000_C584046466ED224CA92C1BC3313B963E09F00CA907INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Kamran,

      &n= bsp;            We w= ere mentioning about multi-lsr sessions for fate separation anyway.  Having 16 byte l= ong LSR-ID would automatically fall back to multi-lsr sessions in dual stack situation= s.

 

Thanks,

Pranjal

 

From: Kamran R= aza [mailto:skraza@cisco.com]
Sent: Thursday, March 01, 20= 12 9:58 AM
To: Shane Amante
Cc: Vishwas Manral; Dutta, P= ranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

Shane,

Right, but the problem with “interpreting 4-byte LSR-Id as routeable&= #8221; is that it does not work for LDP IPv6 peering with existing base spec/extensions. T= o keep using this interpretation/usage for IPv6, one is forced to define 16-b= yte long LSR-Id (and LDP protocol change). As the side affect, this also “= ;enforces” (results in) 2 sessions with the same LSR when used in dual-stack scenarios= .

-- Kamran

On 12-03-01 10:45 AM, "Shane Amante" <shane@castlepoint.net> wrote:<= /font>

Kamran,

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:

Firstly, I don’t agree that LSR Id be made IPv6 = (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 o= ctet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wron= g notion/usage.


Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to:
a) ping the /32 (4-octet) LSR-ID; or,
b) look at a routing table for the existence of a /32 (4-octet) LSR-ID
b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ...

In summary, there is a tremendous amount of operational value in the 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us not underestimate that. All I'm saying is, let's not go out of our way to try t= o make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons.

-shane

Secondly, If there is a need= to define new “LDP Identifier” in order to establish/maintain a se= parate session for IPv6 AF, this should be a protocol change — i.e. we should bump u= p LDP protocol version in LDP PDU header for this, and possibly define new format= for “LDP Identifier” in the context of new LDP protocol version.
My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ; > wrote:

Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it a= s an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com<= /a> <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> > wrote:

= Yes, I support that too. There would be network management issues with mapping of = 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn] <= br> Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Must= apha)
Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; D= utta, Pranjal K (Pranjal); vishwas.ietf@gmail.= com <x-msg://1083/vishwas.ietf@gma= il.com>

Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong


"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-luc= ent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> > wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think that we would need to define a n= ew one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-boun= ces@ietf.org <x-msg://1083/mpls-bounces@ietf= .org>  [mailto:mpls-bounces@ietf.or= g] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ;
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:li= zhong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vis= hwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gma= il.com> ; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<= /a> <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> >
> > To: Vishwas Manral <vishwas= .ietf@gmail.com <x-msg://1083/vishwas.ietf@gma= il.com> >
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui@alcatel-lucent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> >,   "mpls@ietf.org <x-m= sg://1083/mpls@ietf.org> "
> >    <mpls@ietf.org <x-msg://1083/mpls@ietf.org> >= ;
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C5840= 46466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in&g= t; .
> > alcatel-lucent.com <http= ://alcatel-lucent.com>  <http://alcatel-lucent.com <http://alcatel-lucent.com/&g= t; > >
> >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

 

_______________________________________________
mpls mailing list
mpls@ietf.org <x-msg://1083/mpls@ietf.org>
https://www.ietf.org= /mailman/listinfo/mpls


--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com

--_000_C584046466ED224CA92C1BC3313B963E09F00CA907INBANSXCHMBSA_-- From rajiva@cisco.com Thu Mar 1 10:07:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1E21E812E for ; Thu, 1 Mar 2012 10:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.088 X-Spam-Level: X-Spam-Status: No, score=-9.088 tagged_above=-999 required=5 tests=[AWL=0.911, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZJbldRso6-R for ; Thu, 1 Mar 2012 10:07:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75F21E812B for ; Thu, 1 Mar 2012 10:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=7345; q=dns/txt; s=iport; t=1330625245; x=1331834845; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZjDMkAyjEnta2/cMSqoNXWr/EoLbpIvDQFWMi/5nQ5U=; b=Kfcq93CGKadPiIaBN5axildLcAMTVOAzNhFob5/Ncy9H8JmnwnR651Dq QGKyJFDFXCpJnvDNbN625Cyg9CGXGxqI953RuKfujNl9/f0UZ6scUtsVP M+7cF/H2M5fJ4WqUg2fETbFU1wawXCgwomPjIrbLY4HU35O0o5PK2XfeQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACm6T0+tJV2Y/2dsb2JhbAA5CrQCgQeBfQEBAQQSAR0KPwwEAgEIEQMBAQEBCgYXAQYBICUJCAEBBAESCBqHZJlYAZ5uiRtiCYJ4BwECAwIJAQQEAwEKAQMCPRiFTx8Ygk5jBIhPmAeHdoE9 X-IronPort-AV: E=Sophos;i="4.73,511,1325462400"; d="scan'208";a="63074384" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Mar 2012 18:07:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q21I7PLi011168; Thu, 1 Mar 2012 18:07:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 12:07:25 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 12:07:23 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE360@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3h+t1pocdfUrCSq6tiXLdLEPZMgATF64Q References: From: "Rajiv Asati (rajiva)" To: "Lizhong Jin" , "Vishwas Manral" X-OriginalArrivalTime: 01 Mar 2012 18:07:25.0127 (UTC) FILETIME=[27E4CD70:01CCF7D6] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:07:28 -0000 I agree. Based on the discussion & agreement, we will proceed with the document as it-is. It is worth noting that this (LSR ID) really relates to router-id, which is used by not only LDP, but also other protocols (e.g. BGP, OSPF). Of course, each protocol could use the common router-id or a different one. Strictly speaking, all these protocols define router-id to be not routable and leverage the same 4-octet number for IPv6 as well. For ex, One could look at RFC 6286, which updated the base BGP spec RFC4271, to ensure the usage of 4-octet as the BGP ID in the context of IPv6. There is no benefit & reason to change LSR ID definition 32-bit to 128-bit for LDP without considering the bigger picture having other protocols in the network. This specific issue has been visited before and closed.=20 Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Lizhong Jin > Sent: Thursday, March 01, 2012 3:46 AM > To: Vishwas Manral > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > > Hi Lizhong/ Pranjal/ Mustapha, > > > > So the two main comments that have come after last call are: > > > > 1. Allow for separation of sessions along with the adjacency. > > 2. Allow for an IPv6 based LSR-ID. > > > > The second could lead to changes required in both OSPF and IS-IS, as > > well because the new LSR ID would then need to be exchanged. We > > could treat it as an enhancement instead in my view. Do you agree? > [Lizhong] agree, but as Kamran pointed out also in another email, it is not > necessary to flood LSR-ID in routing protocol, the transport address in hello > message is required to be flooded. >=20 > Regards > Lizhong >=20 > > > > Thanks, > > Vishwas >=20 > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) < > > pranjal.dutta@alcatel-lucent.com> wrote: > > Yes, I support that too. There would be network management issues > > with mapping of 4 byte LSR-ID to an IPV6 remote address. > > Most of the implementations I know off usually maps 4 byte of the > > LSR-ID with a local ipv4 interface address in the system. > > > > Thanks, > > Pranjal > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Wednesday, February 29, 2012 4:57 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > > pointed out in my first email. > > > > Thanks > > Lizhong > > > > > > "Aissaoui, Mustapha (Mustapha)" > > wrote 2012/03/01 04:35:41: > > > > > Hi Lizhong, > > > I actually think that we would need to define a new one which will > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > > a all-IPv6 network will not be possible. I cannot see that operators > > > will start maintaining a mapping of some global non routable LSR-id > > > value to an IPv6 loopback interface on each router in the network. > > > > > > Mustapha. > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Lizhong, > > > the existing LSR-id will do the job and should be supported since > > > the LSR-id need not be an IP address. Most implementations will > > > actually populate the field with a /32 address in IPv4 and thus If > > > necessary we could define a new format to allow the use of /128 > > IPv6addresses. > > > > > > Mustapha. > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Monday, February 06, 2012 10:23 PM > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > > Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi, > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > session in dual-stack network. LDP capability is per node > > > capability, not per interface capability. But for LDP to choose the > > > correct downstream session and output interface for each FEC, it > > > should also check if the output interface is LDP enabled or not. The > > > link adjacency could be used to assist such kind of checking. > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > new format of LSR-ID. > > > > > > Regards > > > Lizhong > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > To: Vishwas Manral > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > , "mpls@ietf.org" > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Message-ID: > > > > > > > > alcatel-lucent.com> > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > I would rather for complete separation with multiple lsr-id because > > > > having separate link adjacencies does not really solved any problem. > > > > Since hello adjacencies are associated with a link, still fate > > > > sharing would continue over the single ldp/tcp session for IPV4 and > IPV6. > > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > > egress traffic but I see it as overkill and unnecessary > > scalability impacts. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. From pranjal.dutta@alcatel-lucent.com Thu Mar 1 10:09:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112BE21E8126 for ; Thu, 1 Mar 2012 10:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.175 X-Spam-Level: X-Spam-Status: No, score=-7.175 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrlZsr1fF0h1 for ; Thu, 1 Mar 2012 10:09:01 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB121E80CF for ; Thu, 1 Mar 2012 10:08:58 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q21I8Zbl015277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 12:08:38 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21I8Zhl026740 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 23:38:35 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 1 Mar 2012 23:38:35 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Shane Amante , Kamran Raza Date: Thu, 1 Mar 2012 23:38:32 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CA909INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:09:06 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CA909INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Esp. for T-LDP hellos we would always like to match destination IP of hello= packets to match 4 byte LSR-ID, so same is applicable for IPV6. TCP Transport address is an after affect - T-LDP hellos should be sent to t= he correct IPV6 address first before TCP transport address comes into play. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Thursday, March 01, 2012 7:45 AM To: Kamran Raza Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or rout= e-able; LSR Id, as defined in the base spec, is just a 4 octet unique id an= d need not be routable, though most implementations currently populate it w= ith /32 loopback address. Let's not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in t= he networks I operate it is *always* routable. From a simple troubleshootin= g PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the 4-Byte= LSR-ID actually be announced/routed in a network's IGP -- let us not under= estimate that. All I'm saying is, let's not go out of our way to try to mak= e a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical r= easons. -shane Secondly, If there is a need to define new "LDP Identifier" in order to est= ablish/maintain a separate session for IPv6 AF, this should be a protocol c= hange - i.e. we should bump up LDP protocol version in LDP PDU header for t= his, and possibly define new format for "LDP Identifier" in the context of = new LDP protocol version. My 2 cents. On 12-02-29 8:11 PM, "Vishwas Manral" > wrote: Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); = vishwas.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:m= pls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org" > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > . > > alcatel-lucent.com > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_C584046466ED224CA92C1BC3313B963E09F00CA909INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Esp. for T-LDP hellos we would always = like to match destination IP of hello packets to match 4 byte LSR-ID, so same is applicable for IPV6.

TCP Transport address is an after affe= ct – T-LDP hellos should be sent to the correct IPV6 address first before TCP transport address comes into play.

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Shane Amante
Sent: Thursday, March 01, 20= 12 7:45 AM
To: Kamran Raza
Cc: Aissaoui, Mustapha (Must= apha); Lizhong Jin; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

Kamran,

 

On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:

Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is = just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forw= ard a wrong notion/usage.

 

Although, in theory, the LSR-ID "need not be routable", I= can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to:

a) ping the /32 (4-octet) LSR-ID; or,

b) look at a routing table for the existence of a /32 (4-octet) LSR= -ID

b) use traceroute and/or a routing table to learn the _topological_ location of the /32 (4-octet) LSR-ID in the network ...

 

In summary, there is a tremendous amount of operational value in th= e 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us not underestimate that. All I'm saying is, let's not go out of our way to try t= o make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons.

 

-shane

 



Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv= 6 AF, this should be a protocol change — i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format= for “LDP Identifier” in the context of new LDP protocol version.
My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com> wrote:


Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it a= s an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcate= l-lucent.com> wrote:

Yes, I support that too. There would b= e network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

 

From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn] <= br> Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Must= apha)
Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gma= il.com

Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06
 

Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong
 

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaou= i@alcatel-lucent.com> wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think that we would need to define a n= ew one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]= On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:li= zhong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcate= l-lucent.com>
> > To: Vishwas Manral <vishwas.ietf@gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaou= i@alcatel-lucent.com>,   "mpls@ietf.org"=
> >    <mpls@ietf= .org>
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in. > > alcatel-lucent.com <= http://alcatel-lucent.com> ><= br> > >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls


--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com <= br>

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

 

--_000_C584046466ED224CA92C1BC3313B963E09F00CA909INBANSXCHMBSA_-- From ietfc@btconnect.com Thu Mar 1 10:18:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021DD21F8A10 for ; Thu, 1 Mar 2012 10:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtcD1ONt0rbI for ; Thu, 1 Mar 2012 10:17:58 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6AA21F8710 for ; Thu, 1 Mar 2012 10:17:57 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2beaomr10.btconnect.com with SMTP id GLA74600; Thu, 01 Mar 2012 18:17:26 +0000 (GMT) Message-ID: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Shane Amante" , "Kamran Raza" References: Date: Thu, 1 Mar 2012 18:16:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F4FBD35.00A7, actions=tag X-Junkmail-Premium-Raw: score=10/50, refid=2.7.2:2012.3.1.173616:17:10.433, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, __STOCK_PHRASE_24, __CP_URI_IN_BODY, __C230066_P5, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F4FBD37.0015,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:18:00 -0000 ----- Original Message ----- From: "Shane Amante" To: "Kamran Raza" Cc: "Aissaoui, Mustapha (Mustapha)" ; "Lizhong Jin" ; Sent: Thursday, March 01, 2012 4:45 PM Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, Had much experience lately of keying in a 128-bit IPv6 address with pinpoint accuracy in order to ping a device? Um, it stinks. Protocols like OSPF that decided that a 32 bit router ID was perfect for all address families got it absolutely right, IMO. The better organisations I know make a point of making the router ID an impossible address, so that regardless of context, it is immediately apparent whether a dotted decimal number is a routable address or an ID. Tom Petch b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ location of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us not underestimate that. All I'm saying is, let's not go out of our way to try to make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons. -shane > Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protocol change — i.e. we should bump up LDP protocol version in LDP PDU header for this, and possibly define new format for “LDP Identifier” in the context of new LDP protocol version. > > My 2 cents. > > On 12-02-29 8:11 PM, "Vishwas Manral" wrote: > >> Hi Lizhong/ Pranjal/ Mustapha, >> >> So the two main comments that have come after last call are: >> >> 1. Allow for separation of sessions along with the adjacency. >> 2. Allow for an IPv6 based LSR-ID. >> >> The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it as an enhancement instead in my view. Do you agree? >> >> Thanks, >> Vishwas >> >> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) wrote: >>> Yes, I support that too. There would be network management issues with mapping of 4 byte LSR-ID to an IPV6 remote address. >>> Most of the implementations I know off usually maps 4 byte of the LSR-ID with a local ipv4 interface address in the system. >>> >>> Thanks, >>> Pranjal >>> >>> >>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>> Sent: Wednesday, February 29, 2012 4:57 PM >>> To: Aissaoui, Mustapha (Mustapha) >>> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >>> >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> >>> Hi Mustapha, >>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email. >>> >>> Thanks >>> Lizhong >>> >>> >>> "Aissaoui, Mustapha (Mustapha)" wrote 2012/03/01 04:35:41: >>> >>> > Hi Lizhong, >>> > I actually think that we would need to define a new one which will >>> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in >>> > a all-IPv6 network will not be possible. I cannot see that operators >>> > will start maintaining a mapping of some global non routable LSR-id >>> > value to an IPv6 loopback interface on each router in the network. >>> > >>> > Mustapha. >>> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> > Aissaoui, Mustapha (Mustapha) >>> > Sent: Tuesday, February 07, 2012 10:12 AM >>> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >>> > Cc: mpls@ietf.org >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> > Lizhong, >>> > the existing LSR-id will do the job and should be supported since >>> > the LSR-id need not be an IP address. Most implementations will >>> > actually populate the field with a /32 address in IPv4 and thus If >>> > necessary we could define a new format to allow the use of /128 IPv6addresses. >>> > >>> > Mustapha. >>> > >>> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>> > Sent: Monday, February 06, 2012 10:23 PM >>> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, >>> > Mustapha (Mustapha) >>> > Cc: mpls@ietf.org >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> > >>> > Hi, >>> > I wonder if it is feasible to use LDP capability to advertise IPv6 >>> > FEC without IPv6 adjacency, and only use one adjacency for LDP >>> > session in dual-stack network. LDP capability is per node >>> > capability, not per interface capability. But for LDP to choose the >>> > correct downstream session and output interface for each FEC, it >>> > should also check if the output interface is LDP enabled or not. The >>> > link adjacency could be used to assist such kind of checking. >>> > >>> > However, IMO, it is valuable to allow two independent LDP sessions >>> > for IPv4 and IPv6 as an option. Regarding the format definition in >>> > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. >>> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer >>> > new format of LSR-ID. >>> > >>> > Regards >>> > Lizhong >>> > >>> > >>> > > ---------------------------------------------------------------------- >>> > > >>> > > Message: 1 >>> > > Date: Tue, 7 Feb 2012 05:28:21 +0530 >>> > > From: "Dutta, Pranjal K (Pranjal)" >>> > > To: Vishwas Manral >>> > > Cc: "Aissaoui, Mustapha \(Mustapha\)" >>> > > , "mpls@ietf.org" >>> > > >>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> > > Message-ID: >>> > > >> > > alcatel-lucent.com > >>> > > >>> > > Content-Type: text/plain; charset="us-ascii" >>> > > >>> > > I would rather for complete separation with multiple lsr-id because >>> > > having separate link adjacencies does not really solved any problem. >>> > > Since hello adjacencies are associated with a link, still fate >>> > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. >>> > > Having IPV4 and IPV6 specific hello adjacencies over a link would >>> > > only decide whether such a link is to be programmed for IPV4 or IPV6 >>> > > egress traffic but I see it as overkill and unnecessary scalability impacts. >>> > > >>> > > Thanks, >>> > > Pranjal >>> > > >>> > -------------------------------------------------------- >>> > ZTE Information Security Notice: The information contained in this >>> > mail is solely property of the sender's organization. This mail >>> > communication is confidential. Recipients named above are obligated >>> > to maintain secrecy and are not permitted to disclose the contents >>> > of this communication to others. >>> > This email and any files transmitted with it are confidential and >>> > intended solely for the use of the individual or entity to whom they >>> > are addressed. If you have received this email in error please >>> > notify the originator of the message. Any views expressed in this >>> > message are those of the individual sender. >>> > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > http://www.cisco.com > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -------------------------------------------------------------------------------- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From skraza@cisco.com Thu Mar 1 10:20:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9E21E8105 for ; Thu, 1 Mar 2012 10:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.382 X-Spam-Level: X-Spam-Status: No, score=-8.382 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KARAvlcjr7zs for ; Thu, 1 Mar 2012 10:20:21 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EBFC921E815B for ; Thu, 1 Mar 2012 10:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=31088; q=dns/txt; s=iport; t=1330626021; x=1331835621; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=IZN20lP3xDOgA0/hIwAhDjmtSlDuPMoOTDLHNSnG+II=; b=AxbWdstKtsjZhHqIAos6hcyFXdjYigFuir59H0fiYGw3P+sBKmbactEz gG1ewZ6yDg2S+ZTlTdB0OsJrfhogPDBEhULKUdhNd0yl7NtLMOKQCMTb/ 6LWtdHmBBFUVWy2heUvK7nHgW0zmlX8PGstjxKOO00iGu6EAi4r0T9e+y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAFG9T0+tJXG9/2dsb2JhbAA5BwOCRKA1kBtugQeBfQEBAQMBAQEBDwEqGBEICwUNAQgRAwEBAQEgBygGHwkIAQEEAQ0FIodfBQuZSAGeaokbYgmCeAYBAQICAQIJAQQEAwEKAUEOAQaEXRQGAwUETwEYBAIBBxEBCYMnBIgcM4xsixuHdYE+ X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208,217";a="63075920" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 01 Mar 2012 18:20:20 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q21IKJNO029947; Thu, 1 Mar 2012 18:20:19 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 12:20:19 -0600 Received: from 10.86.250.44 ([10.86.250.44]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Mar 2012 18:20:19 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 01 Mar 2012 13:20:16 -0500 From: Kamran Raza To: "Dutta, Pranjal K (Pranjal)" , Shane Amante Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAACLLo0= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413452816_4757405" X-OriginalArrivalTime: 01 Mar 2012 18:20:19.0834 (UTC) FILETIME=[F5A7B5A0:01CCF7D7] Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:20:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413452816_4757405 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >> Esp. for T-LDP hellos we would always like to match destination IP of he= llo packets to match 4 byte LSR-ID, Just a quick comment on the above statement: Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e. v4 loopback /32 in most impl), there are still some other cases where they do not _always_ use LSR-Id as the T-LDP destination. One such case will be when T-LDP session needs to be established/signaled with a remote PE that i= s discovered via BGP (AD). In this case, the BGP discovered remote PE=B9s /32 address **may not** match remote PE=B9s LDP /32 address (LSR Id). The same example can also be applied to BGP AD (for v6) and T-LDP v6. Thx. -- Kamran On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" wrote: > Esp. for T-LDP hellos we would always like to match destination IP of hel= lo > packets to match 4 byte LSR-ID, so same is applicable for IPV6. > TCP Transport address is an after affect =AD T-LDP hellos should be sent to= the > correct IPV6 address first before TCP transport address comes into play. > =20 >=20 >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of S= hane > Amante > Sent: Thursday, March 01, 2012 7:45 AM > To: Kamran Raza > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > =20 > Kamran, >=20 > =20 >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >>=20 >> Firstly, I don=B9t agree that LSR Id be made IPv6 (address) based and/or >> route-able; LSR Id, as defined in the base spec, is just a 4 octet uniqu= e id >> and need not be routable, though most implementations currently populate= it >> with /32 loopback address. Let=B9s not carry forward a wrong notion/usage. >=20 > =20 > Although, in theory, the LSR-ID "need not be routable", I can say that in= the > networks I operate it is *always* routable. From a simple troubleshooting= PoV, > it's extremely easy to: >=20 > a) ping the /32 (4-octet) LSR-ID; or, >=20 > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID >=20 > b) use traceroute and/or a routing table to learn the _topological_ locat= ion > of the /32 (4-octet) LSR-ID in the network ... >=20 > =20 >=20 > In summary, there is a tremendous amount of operational value in the 4-By= te > LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try= to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoreti= cal > reasons. >=20 > =20 >=20 > -shane >=20 > =20 >=20 >=20 >=20 > Secondly, If there is a need to define new =B3LDP Identifier=B2 in order to > establish/maintain a separate session for IPv6 AF, this should be a proto= col > change =8B i.e. we should bump up LDP protocol version in LDP PDU header fo= r > this, and possibly define new format for =B3LDP Identifier=B2 in the context = of > new LDP protocol version. >=20 > My 2 cents.=20 >=20 > On 12-02-29 8:11 PM, "Vishwas Manral" > wrote: >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it= as > an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > wrote: >=20 >=20 > Yes, I support that too. There would be network management issues with ma= pping > of 4 byte LSR-ID to an IPV6 remote address. > Most of the implementations I know off usually maps 4 byte of the LSR-ID = with > a local ipv4 interface address in the system. > =20 > Thanks, > Pranjal > =20 >=20 > =20 >=20 >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranja= l); > vishwas.ietf@gmail.com >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > =20 >=20 > Hi Mustapha,=20 > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I point= ed > out in my first email. >=20 > Thanks=20 > Lizhong=20 > =20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 > 04:35:41: >=20 >> > Hi Lizhong,=20 >> > I actually think that we would need to define a new one which will >> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in >> > a all-IPv6 network will not be possible. I cannot see that operators >> > will start maintaining a mapping of some global non routable LSR-id >> > value to an IPv6 loopback interface on each router in the network. >> > =20 >> > Mustapha.=20 >> > From: mpls-bounces@ietf.org >> [mailto:mpls-bounces@ietf.org] On Behalf Of >> > Aissaoui, Mustapha (Mustapha) >> > Sent: Tuesday, February 07, 2012 10:12 AM >> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >> >> > Cc: mpls@ietf.org >> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >> > Lizhong,=20 >> > the existing LSR-id will do the job and should be supported since >> > the LSR-id need not be an IP address. Most implementations will >> > actually populate the field with a /32 address in IPv4 and thus If >> > necessary we could define a new format to allow the use of /128 >> IPv6addresses.=20 >> > =20 >> > Mustapha.=20 >> >=20 >> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >> > Sent: Monday, February 06, 2012 10:23 PM >> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >> ; Aissaoui, >> > Mustapha (Mustapha) >> > Cc: mpls@ietf.org >> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >> >=20 >> > Hi,=20 >> > I wonder if it is feasible to use LDP capability to advertise IPv6 >> > FEC without IPv6 adjacency, and only use one adjacency for LDP >> > session in dual-stack network. LDP capability is per node >> > capability, not per interface capability. But for LDP to choose the >> > correct downstream session and output interface for each FEC, it >> > should also check if the output interface is LDP enabled or not. The >> > link adjacency could be used to assist such kind of checking. >> >=20 >> > However, IMO, it is valuable to allow two independent LDP sessions >> > for IPv4 and IPv6 as an option. Regarding the format definition in >> > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. >> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer >> > new format of LSR-ID. >> >=20 >> > Regards=20 >> > Lizhong=20 >> >=20 >> >=20 >>> > > -------------------------------------------------------------------= --- >>> > >=20 >>> > > Message: 1 >>> > > Date: Tue, 7 Feb 2012 05:28:21 +0530 >>> > > From: "Dutta, Pranjal K (Pranjal)" >> > >>> > > To: Vishwas Manral >> > >>> > > Cc: "Aissaoui, Mustapha \(Mustapha\)" >>> > > >> >, "mpls@ietf.org >>> " >>> > > > >>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> > > Message-ID: >>> > > >> . >>> > > alcatel-lucent.com >>> > > >>> > > =20 >>> > > Content-Type: text/plain; charset=3D"us-ascii" >>> > >=20 >>> > > I would rather for complete separation with multiple lsr-id because >>> > > having separate link adjacencies does not really solved any problem= . >>> > > Since hello adjacencies are associated with a link, still fate >>> > > sharing would continue over the single ldp/tcp session for IPV4 and= >>> IPV6. >>> > > Having IPV4 and IPV6 specific hello adjacencies over a link would >>> > > only decide whether such a link is to be programmed for IPV4 or IPV= 6 >>> > > egress traffic but I see it as overkill and unnecessary scalability >>> impacts. >>> > >=20 >>> > > Thanks, >>> > > Pranjal >>> > >=20 >> > -------------------------------------------------------- >> > ZTE Information Security Notice: The information contained in this >> > mail is solely property of the sender's organization. This mail >> > communication is confidential. Recipients named above are obligated >> > to maintain secrecy and are not permitted to disclose the contents >> > of this communication to others. >> > This email and any files transmitted with it are confidential and >> > intended solely for the use of the individual or entity to whom they >> > are addressed. If you have received this email in error please >> > notify the originator of the message. Any views expressed in this >> > message are those of the individual sender. >> > This message has been scanned for viruses and Spam by ZTE Anti-Spam sy= stem. > =20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > --=20 > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > http://www.cisco.com >=20 >=20 >=20 --B_3413452816_4757405 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>> Esp. for T-LDP hellos we would always like = to match destination IP of hello packets to match 4 byte LSR-ID,

Just a quick comment on the above statement:

Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e.= v4 loopback /32 in most impl), there are still some other cases where they = do not _always_ use LSR-Id as the T-LDP destination. One such case will be w= hen T-LDP session needs to be established/signaled with a remote PE that is = discovered via BGP (AD).  In this case, the BGP discovered remote PE= 217;s /32 address **may not** match remote PE’s LDP /32 address (LSR I= d).

The same example can also be applied to BGP AD (for v6) and T-LDP v6.

Thx.
-- Kamran

On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wro= te:

Esp. for T-LDP hellos we would always li= ke to match destination IP of hello packets to match 4 byte LSR-ID, so same = is applicable for IPV6.
TCP Transport address is an after affect – T-LDP hellos should be sen= t to the correct IPV6 address first before TCP transport address comes into = play.
 

From: mpls-bounces@ie= tf.org [mailto:mpls-bounces@ietf.= org] On Behalf Of Shane Amante
Sent: Thursday, March 01, 2012 7:45 AM
To: Kamran Raza
Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org
Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
Kamran,
On = Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:

<= SPAN STYLE=3D'font-size:11pt'>
Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/o= r route-able; LSR Id, as defined in the base spec, is just a 4 octet unique = id and need not be routable, though most implementations currently populate = it with /32 loopback address. Let’s not carry forward a wrong notion/u= sage.
=
Although, in theory, the LSR-ID "need not be routable", I can say= that in the networks I operate it is *always* routable. From a simple troub= leshooting PoV, it's extremely easy to:

a) = ping the /32 (4-octet) LSR-ID; or,

b) = look at a routing table for the existence of a /32 (4-octet) LSR-ID

b) = use traceroute and/or a routing table to learn the _topological_ location of= the /32 (4-octet) LSR-ID in the network ...
In = summary, there is a tremendous amount of operational value in the 4-Byte LSR= -ID actually be announced/routed in a network's IGP -- let us not underestim= ate that. All I'm saying is, let's not go out of our way to try to make a &q= uot;new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretica= l reasons.
-sh= ane

Secondly, If there is a need to define new “LDP Identi= fier” in order to establish/maintain a separate session for IPv6 AF, t= his should be a protocol change — i.e. we should bump up LDP protocol = version in LDP PDU header for this, and possibly define new format for ̶= 0;LDP Identifier” in the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com> > wrote:



Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as = an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com <x-m= sg://1083/pranjal.dutta@al= catel-lucent.com> > wrote:


Yes, I support that too. There would be network mana= gement issues with mapping of 4 byte LSR-ID to an IPV6 remote address.
Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 

=20


From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn]
Sent: Wednesday, February 29, 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; Dutta, Pranjal K (Pranjal)= ; vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

I agree, and I also pref= er to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong


"Aissaoui, Mustapha= (Mustapha)" <mustaph= a.aissaoui@alcatel-lucent.com <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com> &g= t; wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think th= at we would need to define a new one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-bounces@ietf.org <x-msg://1083/mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id= will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6ad= dresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:lizh= ong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vishw= as.ietf@gmail.com <x-msg://10= 83/vishwas.ietf@gmail.com> ; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > -----------------------------------------------------------------= -----
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com <x-msg://1083/pranjal.dutta@alcatel= -lucent.com> >
> > To: Vishwas Manral <vishwas.i= etf@gmail.com <x-msg://1083/v= ishwas.ietf@gmail.com> >
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui@alcatel-lucent.com <x-msg://1083/mustapha.aissaoui@alcatel-lucent.com= > >,   "mpls@ietf.org &= lt;x-msg://1083/mpls@ietf.org> "<= BR> > >    <mpls@ietf.org &= lt;x-msg://1083/mpls@ietf.org> > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBAN= SXCHMBSA3.in <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D6= 67@INBANSXCHMBSA3.in> .
> > alcatel-lucent.com <http:/= /alcatel-lucent.com>  <ht= tp://alcatel-lucent.com <http://= alcatel-lucent.com/> > >
> >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam sy= stem.
=20


_______________________________________________ mpls mailing list
mpls@ietf.org <x-msg://1083/mpls@ietf.org>
https://www.ietf.org/m= ailman/listinfo/mpls


--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3413452816_4757405-- From rajiva@cisco.com Thu Mar 1 10:54:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA021F899E for ; Thu, 1 Mar 2012 10:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.123 X-Spam-Level: X-Spam-Status: No, score=-9.123 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thJUvGqyBn8R for ; Thu, 1 Mar 2012 10:54:22 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C521E8080 for ; Thu, 1 Mar 2012 10:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=10682; q=dns/txt; s=iport; t=1330628062; x=1331837662; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QZqnV6YDqgIo3Hi4Fhk8OPbqH6fyvynwoGCOIfF0XOw=; b=G+kOtmoSydGZITxYVNuKLpI954ZZ01UeNdlc06Vf0o2edA2mIxrhEUJd jTidJJVbBsIU5SvhdKXbGILyBr+50QzQy+wir14EvZlVoU31tBtZOm60s ojgK3BpKJHgUaLnw27Y3LGoG8xAHo1Peuw9c/M2L89LvA3709Gn4Nl/pO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGPFT0+tJV2Z/2dsb2JhbAA5BwO0D4EHgX0BAQEEAQEBDwEdChsRCAsMBAIBCAcKAwEBAQEKBhcBBgEgBh8JCAEBBAESCBqHZAugPwGXBIkbYgmCeAgCAwIFBAUEAwEKAQMCPRiFSAYBAQQIBwQEAgEHBgsBCYJEYwSIT5gHh3aBPQ X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208";a="63083959" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 01 Mar 2012 18:54:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q21IsLMO002674; Thu, 1 Mar 2012 18:54:21 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 12:54:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 12:54:19 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE3CA@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlqEuQI9l6MATcuT4Zse3rvnvAAFA+Bg References: From: "Rajiv Asati (rajiva)" To: "Shane Amante" , "Kamran Raza (skraza)" X-OriginalArrivalTime: 01 Mar 2012 18:54:21.0627 (UTC) FILETIME=[B6A898B0:01CCF7DC] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:54:26 -0000 Having 4-octet LSR ID for IPv6 is good enough, IMO.=20 AFAIK, It is good enough for BGP, OSPF etc. One could look at RFC 6286, which updated the base BGP spec RFC4271, to ensure the usage of 4-octet as the BGP ID in the context of IPv6. One could also look at RFC5340 - OSPF for IPv6. BGP RFC6286 // The BGP Identifier is a 4-octet, unsigned, non-zero integer that should be unique within an AS. The value of the BGP Identifier // OSPF RFC5340 // o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32 bits. They can no longer be assigned as (IPv6) addresses. // o On all link types (e.g., broadcast, NBMA, point-to-point, etc.), neighbors are identified solely by their OSPF Router ID. For all o The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address. // Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Thursday, March 01, 2012 10:45 AM > To: Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Kamran, >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >=20 > Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or > route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and > need not be routable, though most implementations currently populate it > with /32 loopback address. Let's not carry forward a wrong notion/usage. >=20 >=20 >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that in the > networks I operate it is *always* routable. From a simple troubleshooting > PoV, it's extremely easy to: > a) ping the /32 (4-octet) LSR-ID; or, > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > b) use traceroute and/or a routing table to learn the _topological_ location of > the /32 (4-octet) LSR-ID in the network ... >=20 > In summary, there is a tremendous amount of operational value in the 4- > Byte LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical > reasons. >=20 > -shane >=20 >=20 >=20 > Secondly, If there is a need to define new "LDP Identifier" in order to > establish/maintain a separate session for IPv6 AF, this should be a protocol > change - i.e. we should bump up LDP protocol version in LDP PDU header > for this, and possibly define new format for "LDP Identifier" in the context of > new LDP protocol version. >=20 > My 2 cents. >=20 > On 12-02-29 8:11 PM, "Vishwas Manral" msg://1083/vishwas.ietf@gmail.com> > wrote: >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and > IS-IS, as well because the new LSR ID would then need to be exchanged. We > could treat it as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > lucent.com> > wrote: >=20 >=20 > Yes, I support that too. There would be network > management issues with mapping of 4 byte LSR-ID to an IPV6 remote > address. > Most of the implementations I know off usually maps > 4 byte of the LSR-ID with a local ipv4 interface address in the system. >=20 > Thanks, > Pranjal >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org ; > Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com msg://1083/vishwas.ietf@gmail.com> >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp- > ipv6-06 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated > LSR-ID, as I pointed out in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > msg://1083/mustapha.aissaoui@alcatel-lucent.com> > wrote 2012/03/01 > 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new > one which will > > accomodate an IPv6 /128 address. Otherwise, > targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see > that operators > > will start maintaining a mapping of some global non > routable LSR-id > > value to an IPv6 loopback interface on each router > in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls- > ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be > supported since > > the LSR-id need not be an IP address. Most > implementations will > > actually populate the field with a /32 address in IPv4 > and thus If > > necessary we could define a new format to allow > the use of /128 IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com ; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls- > ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to > advertise IPv6 > > FEC without IPv6 adjacency, and only use one > adjacency for LDP > > session in dual-stack network. LDP capability is per > node > > capability, not per interface capability. But for LDP > to choose the > > correct downstream session and output interface > for each FEC, it > > should also check if the output interface is LDP > enabled or not. The > > link adjacency could be used to assist such kind of > checking. > > > > However, IMO, it is valuable to allow two > independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the > format definition in > > RFC5036, we may need new LDP version number to > identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, > but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ------------------------------------------------------------ > ---------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > lucent.com> > > > > To: Vishwas Manral msg://1083/vishwas.ietf@gmail.com> > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.org msg://1083/mpls@ietf.org> " > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls- > ldp-ipv6-06 > > > Message-ID: > > > > msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH > MBSA3.in> . > > > alcatel-lucent.com > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with > multiple lsr-id because > > > having separate link adjacencies does not really > solved any problem. > > > Since hello adjacencies are associated with a link, > still fate > > > sharing would continue over the single ldp/tcp > session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies > over a link would > > > only decide whether such a link is to be > programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and > unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information > contained in this > > mail is solely property of the sender's organization. > This mail > > communication is confidential. Recipients named > above are obligated > > to maintain secrecy and are not permitted to > disclose the contents > > of this communication to others. > > This email and any files transmitted with it are > confidential and > > intended solely for the use of the individual or > entity to whom they > > are addressed. If you have received this email in > error please > > notify the originator of the message. Any views > expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and > Spam by ZTE Anti-Spam system. >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > http://www.cisco.com >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From rajiva@cisco.com Thu Mar 1 11:17:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4021E8252 for ; Thu, 1 Mar 2012 11:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.155 X-Spam-Level: X-Spam-Status: No, score=-9.155 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzsIBIAYFPms for ; Thu, 1 Mar 2012 11:17:45 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7221E824D for ; Thu, 1 Mar 2012 11:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=10219; q=dns/txt; s=iport; t=1330629465; x=1331839065; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yHpnB0pGwqTP36/6zQuJ3C6kgnikuj1wewG7CmKlCGg=; b=SS3iaIcVNi+17Cv/il/Igs9S3Hpg0WTws8EyRCRtQjupk++rZj/2qynQ VMAnBtHHpqgpiUQjdXfISGwxd2vJW/pn3E2BQNRr865OopgddMfEbY/8+ F55OZuq/J0VJZLvHDjMfbCClz0J4cGVR9aEhvLNllXbgfgiPxuN6M9GVf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEHKT0+tJV2a/2dsb2JhbAA5BwO0A4EHgX0BAQEDAQEBAQ8BHQobEQgLBQcEAgEIBwoDAQEBAQoGFwEGASAGHwkIAQEEARIIGodfBQuZVwGeaokbYgmCeAcBAgMKAQEEBAMLAQMCPRiFSAYBAQQIBwQEAgEHBgsBCYJEYwSIT5gHh3aBPQ X-IronPort-AV: E=Sophos;i="4.73,512,1325462400"; d="scan'208";a="63082948" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 01 Mar 2012 19:17:44 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q21JHi1t011121; Thu, 1 Mar 2012 19:17:44 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 13:17:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 13:17:42 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE3F8@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAAJjiyA= References: From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" , "Kamran Raza (skraza)" X-OriginalArrivalTime: 01 Mar 2012 19:17:44.0485 (UTC) FILETIME=[FAD3BD50:01CCF7DF] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 19:17:46 -0000 Pranjal, > Esp. for T-LDP hellos we would always like to match destination IP of hello > packets to match 4 byte LSR-ID, so same is applicable for IPV6. Really ! Could you please point to the right RFC5036 section that says the above? Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Thursday, March 01, 2012 1:09 PM > To: Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Esp. for T-LDP hellos we would always like to match destination IP of hello > packets to match 4 byte LSR-ID, so same is applicable for IPV6. >=20 > TCP Transport address is an after affect - T-LDP hellos should be sent to the > correct IPV6 address first before TCP transport address comes into play. >=20 >=20 >=20 > ________________________________ >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Thursday, March 01, 2012 7:45 AM > To: Kamran Raza > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Kamran, >=20 >=20 >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >=20 > Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or > route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and > need not be routable, though most implementations currently populate it > with /32 loopback address. Let's not carry forward a wrong notion/usage. >=20 >=20 >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that in the > networks I operate it is *always* routable. From a simple troubleshooting > PoV, it's extremely easy to: >=20 > a) ping the /32 (4-octet) LSR-ID; or, >=20 > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID >=20 > b) use traceroute and/or a routing table to learn the _topological_ location of > the /32 (4-octet) LSR-ID in the network ... >=20 >=20 >=20 > In summary, there is a tremendous amount of operational value in the 4- > Byte LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical > reasons. >=20 >=20 >=20 > -shane >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Secondly, If there is a need to define new "LDP Identifier" in order to > establish/maintain a separate session for IPv6 AF, this should be a protocol > change - i.e. we should bump up LDP protocol version in LDP PDU header > for this, and possibly define new format for "LDP Identifier" in the context of > new LDP protocol version. >=20 > My 2 cents. >=20 > On 12-02-29 8:11 PM, "Vishwas Manral" msg://1083/vishwas.ietf@gmail.com> > wrote: >=20 >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > lucent.com> > wrote: >=20 >=20 >=20 > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address. > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system. >=20 > Thanks, > Pranjal >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out > in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 > 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] On Behalf Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com msg://1083/vishwas.ietf@gmail.com> > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com msg://1083/vishwas.ietf@gmail.com> ; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" msg://1083/pranjal.dutta@alcatel-lucent.com> > > > > To: Vishwas Manral msg://1083/vishwas.ietf@gmail.com> > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.org msg://1083/mpls@ietf.org> " > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH > MBSA3.in> . > > > alcatel-lucent.com lucent.com/> > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 >=20 > ________________________________ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > http://www.cisco.com >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From pranjal.dutta@alcatel-lucent.com Thu Mar 1 13:42:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70521E8217 for ; Thu, 1 Mar 2012 13:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.091 X-Spam-Level: X-Spam-Status: No, score=-7.091 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH82UDdcAduD for ; Thu, 1 Mar 2012 13:42:08 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 00AF621E8261 for ; Thu, 1 Mar 2012 13:42:07 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q21Lfo4X025614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 15:41:53 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21LfmQB032207 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 03:11:49 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 2 Mar 2012 03:11:48 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante , "Kamran Raza (skraza)" Date: Fri, 2 Mar 2012 03:11:45 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAAJjiyAABSASkA== Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C078BE3F8@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE3F8@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:42:09 -0000 I never claimed that it is stated by RFC 5036! Did I? It's what we "like" to do in most cases..whereas cases do exists where it i= s not so (Kamran's last reply).=20 -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Thursday, March 01, 2012 11:18 AM To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > Esp. for T-LDP hellos we would always like to match destination IP of hello > packets to match 4 byte LSR-ID, so same is applicable for IPV6. Really ! Could you please point to the right RFC5036 section that says the above? Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Thursday, March 01, 2012 1:09 PM > To: Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Esp. for T-LDP hellos we would always like to match destination IP of hello > packets to match 4 byte LSR-ID, so same is applicable for IPV6. >=20 > TCP Transport address is an after affect - T-LDP hellos should be sent to the > correct IPV6 address first before TCP transport address comes into play. >=20 >=20 >=20 > ________________________________ >=20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Thursday, March 01, 2012 7:45 AM > To: Kamran Raza > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Kamran, >=20 >=20 >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >=20 > Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or > route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and > need not be routable, though most implementations currently populate it > with /32 loopback address. Let's not carry forward a wrong notion/usage. >=20 >=20 >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that in the > networks I operate it is *always* routable. From a simple troubleshooting > PoV, it's extremely easy to: >=20 > a) ping the /32 (4-octet) LSR-ID; or, >=20 > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID >=20 > b) use traceroute and/or a routing table to learn the _topological_ location of > the /32 (4-octet) LSR-ID in the network ... >=20 >=20 >=20 > In summary, there is a tremendous amount of operational value in the 4- > Byte LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical > reasons. >=20 >=20 >=20 > -shane >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Secondly, If there is a need to define new "LDP Identifier" in order to > establish/maintain a separate session for IPv6 AF, this should be a protocol > change - i.e. we should bump up LDP protocol version in LDP PDU header > for this, and possibly define new format for "LDP Identifier" in the context of > new LDP protocol version. >=20 > My 2 cents. >=20 > On 12-02-29 8:11 PM, "Vishwas Manral" msg://1083/vishwas.ietf@gmail.com> > wrote: >=20 >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > lucent.com> > wrote: >=20 >=20 >=20 > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address. > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system. >=20 > Thanks, > Pranjal >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out > in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 > 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org] On Behalf Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com msg://1083/vishwas.ietf@gmail.com> > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com msg://1083/vishwas.ietf@gmail.com> ; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" msg://1083/pranjal.dutta@alcatel-lucent.com> > > > > To: Vishwas Manral msg://1083/vishwas.ietf@gmail.com> > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.org msg://1083/mpls@ietf.org> " > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH > MBSA3.in> . > > > alcatel-lucent.com lucent.com/> > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 >=20 > ________________________________ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > -- > Syed Kamran Raza > Technical Leader, SPRSG IOS-XR Routing (MPLS) > Cisco Systems, Inc., > Kanata, ON, K2K 3E8, Canada > Ph: +1 (613) 254-4520 > http://www.cisco.com >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From pranjal.dutta@alcatel-lucent.com Thu Mar 1 15:09:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7049D21F88D9 for ; Thu, 1 Mar 2012 15:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.018 X-Spam-Level: X-Spam-Status: No, score=-9.018 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+oc4rh9v3a8 for ; Thu, 1 Mar 2012 15:09:44 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2666321F88D7 for ; Thu, 1 Mar 2012 15:09:34 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q21N9HmU028348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 17:09:19 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21N9FlB001669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 04:39:16 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 2 Mar 2012 04:39:15 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , Shane Amante Date: Fri, 2 Mar 2012 04:39:10 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAACLLo0ACgIPAA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CA92AINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:09:50 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CA92AINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kamran, Agreed that there are cases with BGP-AD for v6 etc but that's not the key p= oint that Shane has raised from an operator's point of view. We need to add= ress all concerns from operational point of view apart from existing theory= . Cheers, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kam= ran Raza Sent: Thursday, March 01, 2012 10:20 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> Esp. for T-LDP hellos we would always like to match destination IP of he= llo packets to match 4 byte LSR-ID, Just a quick comment on the above statement: Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e.= v4 loopback /32 in most impl), there are still some other cases where they= do not _always_ use LSR-Id as the T-LDP destination. One such case will be= when T-LDP session needs to be established/signaled with a remote PE that = is discovered via BGP (AD). In this case, the BGP discovered remote PE's /= 32 address **may not** match remote PE's LDP /32 address (LSR Id). The same example can also be applied to BGP AD (for v6) and T-LDP v6. Thx. -- Kamran On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" wrote: Esp. for T-LDP hellos we would always like to match destination IP of hello= packets to match 4 byte LSR-ID, so same is applicable for IPV6. TCP Transport address is an after affect - T-LDP hellos should be sent to t= he correct IPV6 address first before TCP transport address comes into play. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Thursday, March 01, 2012 7:45 AM To: Kamran Raza Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or rout= e-able; LSR Id, as defined in the base spec, is just a 4 octet unique id an= d need not be routable, though most implementations currently populate it w= ith /32 loopback address. Let's not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in t= he networks I operate it is *always* routable. From a simple troubleshootin= g PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the 4-Byte= LSR-ID actually be announced/routed in a network's IGP -- let us not under= estimate that. All I'm saying is, let's not go out of our way to try to mak= e a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical r= easons. -shane Secondly, If there is a need to define new "LDP Identifier" in order to est= ablish/maintain a separate session for IPv6 AF, this should be a protocol c= hange - i.e. we should bump up LDP protocol version in LDP PDU header for t= his, and possibly define new format for "LDP Identifier" in the context of = new LDP protocol version. My 2 cents. On 12-02-29 8:11 PM, "Vishwas Manral" > wrote: Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranjal)= ; vishwas.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com ; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org " > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > . > > alcatel-lucent.com > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --_000_C584046466ED224CA92C1BC3313B963E09F00CA92AINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Kamran,

 

Agreed that there are cases with BGP-A= D for v6 etc but that’s not the key point that Shane has raised from an= operator’s point of view. We need to address all concerns from operational point of vi= ew apart from existing theory.

      &n= bsp;      

Cheers,

Pranjal

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kamran Raza
Sent: Thursday, March 01, 20= 12 10:20 AM
To: Dutta, Pranjal K (Pranja= l); Shane Amante
Cc: Aissaoui, Mustapha (Must= apha); mpls@ietf.org; Lizhong Jin
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 


>> Esp. for T-LDP h= ellos we would always like to match destination IP of hello packets to match 4 by= te LSR-ID,

Just a quick comment on the above statement:

Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e.= v4 loopback /32 in most impl), there are still some other cases where they do = not _always_ use LSR-Id as the T-LDP destination. One such case will be when T-= LDP session needs to be established/signaled with a remote PE that is discovere= d via BGP (AD).  In this case, the BGP discovered remote PE’s /32 = address **may not** match remote PE’s LDP /32 address (LSR Id).

The same example can also be applied to BGP AD (for v6) and T-LDP v6.

Thx.
-- Kamran

On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<= /a>> wrote:

Esp. for T-LDP hellos we would always = like to match destination IP of hello packets to match 4 byte LSR-ID, so same is applicable for IPV6.
TCP Transport address is an after affect – T-LDP hellos should be sen= t to the correct IPV6 address first before TCP transport address comes into play.  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]= On Behalf Of Shane Amante
Sent: Thursday, March 01, 20= 12 7:45 AM
To: Kamran Raza
Cc: Aissaoui, Mustapha (Must= apha); Lizhong Jin; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

Kamran,



On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote:


Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/o= r route-able; LSR Id, as defined in the base spec, is just a 4 octet unique i= d and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usa= ge.



Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to:

a) ping the /32 (4-octet) LSR-ID; or,

b) look at a routing table for the existence of a /32 (4-octe= t) LSR-ID

b) use traceroute and/or a routing table to learn the _topological_ location of the /32 (4-octet) LSR-ID in the network ...



In summary, there is a tremendous amount of operational value= in the 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us= not underestimate that. All I'm saying is, let's not go out of our way to try t= o make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons.



-shane





Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protoco= l change — i.e. we should bump up LDP protocol version in LDP PDU heade= r for this, and possibly define new format for “LDP Identifier” in th= e context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ; > wrote:



Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it a= s an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com<= /a> <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> > wrote:


Yes, I support that too. There would be netwo= rk management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.<= br> Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 


From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn] <= br> Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Must= apha)
Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; D= utta, Pranjal K (Pranjal); vishwas.ietf@gmail.= com <x-msg://1083/vishwas.ietf@gma= il.com>

Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong


"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-luc= ent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> > wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think that we would need to define a n= ew one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-boun= ces@ietf.org <x-msg://1083/mpls-bounces@ietf= .org> [mailto:mpls-bounces@ietf.org]= On Behalf Of
> Aissaoui, Mustapha (Mustapha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ;
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:li= zhong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pranjal); vis= hwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gma= il.com> ; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<= /a> <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> >
> > To: Vishwas Manral <vishwas= .ietf@gmail.com <x-msg://1083/vishwas.ietf@gma= il.com> >
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui@alcatel-lucent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> >,   "mpls@ietf.org <x-m= sg://1083/mpls@ietf.org> "
> >    <mpls@ietf.org <x-msg://1083/mpls@ietf.org> >= ;
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C5840= 46466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in&g= t; .
> > alcatel-lucent.com <http= ://alcatel-lucent.com>  <http://alcatel-lucent.com <http://alcatel-lucent.com/&g= t; > >
> >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


_______________________________________________
mpls mailing list
mpls@ietf.org <x-msg://1083/mpls@ietf.org>
https://www.ietf.org= /mailman/listinfo/mpls


--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com

--_000_C584046466ED224CA92C1BC3313B963E09F00CA92AINBANSXCHMBSA_-- From mustapha.aissaoui@alcatel-lucent.com Thu Mar 1 15:25:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD95E21E8369 for ; Thu, 1 Mar 2012 15:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.73 X-Spam-Level: X-Spam-Status: No, score=-6.73 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTM-OUT6VO4u for ; Thu, 1 Mar 2012 15:25:10 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9628E21E8046 for ; Thu, 1 Mar 2012 15:25:10 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q21NP5U1027943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 17:25:05 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q21NP5MT021739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Mar 2012 17:25:05 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 1 Mar 2012 17:25:05 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "'rajiva@cisco.com'" , "'lizhong.jin@zte.com.cn'" , "'vishwas.ietf@gmail.com'" Date: Thu, 1 Mar 2012 17:25:05 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3h+t1pocdfUrCSq6tiXLdLEPZMgATF64QAAuPoBY= Message-ID: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 23:25:11 -0000 UmFqaXYsDQpZb3UgaGF2ZSBoZWFyZCB0aGUgcmVxdWlyZW1lbnRzIGZyb20gb3BlcmF0b3JzIG9u IHRoaXMgbWFpbGluZyBsaXN0IGFza2luZyBmb3Igc2VwYXJhdGUgTERQIHNlc3Npb25zIGZvciBJ UHY0IGFuZCBJUHY2LiANCg0KVGhlIGRyYWZ0IGluIGl0cyBjdXJyZW50IGZvcm0gZG9lcyBub3Qg bWVldCB0aGlzIHJlcXVpcmVtZW50IGFuZCB5ZXQgaXQgYWRkcyBjb25zdHJhaW50cyB3aGljaCBt YWtlcyBpdCBpbmNvbXBhdGlibGUgd2l0aCBSRkM1MDM2LiBJdCBhbHNvIGRvdWJsZXMgdGhlIG51 bWJlciBvZiBIZWxsbyBhZGphY2VuY2llcyBmb3Igbm8gZ2Fpbi4NCg0KV2hhdCBpcyB0aGUgcG9p bnQgb2YgY2FycnlpbmcgZm9yd2FyZCB0aGlzIGRyYWZ0IGFzIGlzPw0KDQpNdXN0YXBoYS4NClNl bnQgZnJvbSBteSBCbGFja2JlcnJ5IQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG cm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKSA8cmFqaXZhQGNpc2NvLmNvbT4NClRvOiBMaXpob25n IEppbiA8bGl6aG9uZy5qaW5AenRlLmNvbS5jbj47IFZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmll dGZAZ21haWwuY29tPg0KQ2M6IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBtcGxzQGll dGYub3JnIDxtcGxzQGlldGYub3JnPg0KU2VudDogVGh1IE1hciAwMSAxMjowNzoyMyAyMDEyClN1 YmplY3Q6IFJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2 DQoNCkkgYWdyZWUuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uICYgYWdyZWVtZW50LCB3ZSB3aWxs IHByb2NlZWQgd2l0aCB0aGUNCmRvY3VtZW50IGFzIGl0LWlzLg0KDQpJdCBpcyB3b3J0aCBub3Rp bmcgdGhhdCB0aGlzIChMU1IgSUQpIHJlYWxseSByZWxhdGVzIHRvIHJvdXRlci1pZCwgd2hpY2gN CmlzIHVzZWQgYnkgbm90IG9ubHkgTERQLCBidXQgYWxzbyBvdGhlciBwcm90b2NvbHMgKGUuZy4g QkdQLCBPU1BGKS4gT2YNCmNvdXJzZSwgZWFjaCBwcm90b2NvbCBjb3VsZCB1c2UgdGhlIGNvbW1v biByb3V0ZXItaWQgb3IgYSBkaWZmZXJlbnQgb25lLg0KU3RyaWN0bHkgc3BlYWtpbmcsIGFsbCB0 aGVzZSBwcm90b2NvbHMgZGVmaW5lIHJvdXRlci1pZCB0byBiZSBub3QNCnJvdXRhYmxlIGFuZCBs ZXZlcmFnZSB0aGUgc2FtZSA0LW9jdGV0IG51bWJlciBmb3IgSVB2NiBhcyB3ZWxsLg0KDQpGb3Ig ZXgsIE9uZSBjb3VsZCBsb29rIGF0IFJGQyA2Mjg2LCB3aGljaCB1cGRhdGVkIHRoZSBiYXNlIEJH UCBzcGVjDQpSRkM0MjcxLCB0byBlbnN1cmUgdGhlIHVzYWdlIG9mIDQtb2N0ZXQgYXMgdGhlIEJH UCBJRCBpbiB0aGUgY29udGV4dCBvZg0KSVB2Ni4NCg0KVGhlcmUgaXMgbm8gYmVuZWZpdCAmIHJl YXNvbiB0byBjaGFuZ2UgTFNSIElEIGRlZmluaXRpb24gMzItYml0IHRvDQoxMjgtYml0IGZvciBM RFAgd2l0aG91dCBjb25zaWRlcmluZyB0aGUgYmlnZ2VyIHBpY3R1cmUgaGF2aW5nIG90aGVyDQpw cm90b2NvbHMgaW4gdGhlIG5ldHdvcmsuIFRoaXMgc3BlY2lmaWMgaXNzdWUgaGFzIGJlZW4gdmlz aXRlZCBiZWZvcmUNCmFuZCBjbG9zZWQuIA0KDQpDaGVlcnMsDQpSYWppdg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpPZg0KPiBMaXpob25nIEppbg0KPiBT ZW50OiBUaHVyc2RheSwgTWFyY2ggMDEsIDIwMTIgMzo0NiBBTQ0KPiBUbzogVmlzaHdhcyBNYW5y YWwNCj4gQ2M6IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBtcGxzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2 LTA2DQo+IA0KPiANCj4gDQo+ID4gSGkgTGl6aG9uZy8gUHJhbmphbC8gTXVzdGFwaGEsDQo+ID4N Cj4gPiBTbyB0aGUgdHdvIG1haW4gY29tbWVudHMgdGhhdCBoYXZlIGNvbWUgYWZ0ZXIgbGFzdCBj YWxsIGFyZToNCj4gPg0KPiA+IDEuIEFsbG93IGZvciBzZXBhcmF0aW9uIG9mIHNlc3Npb25zIGFs b25nIHdpdGggdGhlIGFkamFjZW5jeS4NCj4gPiAyLiBBbGxvdyBmb3IgYW4gSVB2NiBiYXNlZCBM U1ItSUQuDQo+ID4NCj4gPiBUaGUgc2Vjb25kIGNvdWxkIGxlYWQgdG8gY2hhbmdlcyByZXF1aXJl ZCBpbiBib3RoIE9TUEYgYW5kIElTLUlTLCBhcw0KPiA+IHdlbGwgYmVjYXVzZSB0aGUgbmV3IExT UiBJRCB3b3VsZCB0aGVuIG5lZWQgdG8gYmUgZXhjaGFuZ2VkLiBXZQ0KPiA+IGNvdWxkIHRyZWF0 IGl0IGFzIGFuIGVuaGFuY2VtZW50IGluc3RlYWQgaW4gbXkgdmlldy4gRG8geW91IGFncmVlPw0K PiBbTGl6aG9uZ10gYWdyZWUsIGJ1dCBhcyBLYW1yYW4gcG9pbnRlZCBvdXQgYWxzbyBpbiBhbm90 aGVyIGVtYWlsLCBpdA0KaXMgbm90DQo+IG5lY2Vzc2FyeSB0byBmbG9vZCBMU1ItSUQgaW4gcm91 dGluZyBwcm90b2NvbCwgdGhlIHRyYW5zcG9ydCBhZGRyZXNzDQppbiBoZWxsbw0KPiBtZXNzYWdl IGlzIHJlcXVpcmVkIHRvIGJlIGZsb29kZWQuDQo+IA0KPiBSZWdhcmRzDQo+IExpemhvbmcNCj4g DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gVmlzaHdhcw0KPiANCj4gPiBPbiBXZWQsIEZlYiAyOSwg MjAxMiBhdCA1OjAzIFBNLCBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKSA8DQo+ID4gcHJhbmph bC5kdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPiA+IFllcywgSSBzdXBwb3J0IHRo YXQgdG9vLiBUaGVyZSB3b3VsZCBiZSBuZXR3b3JrIG1hbmFnZW1lbnQgaXNzdWVzDQo+ID4gd2l0 aCBtYXBwaW5nIG9mIDQgYnl0ZSBMU1ItSUQgdG8gYW4gSVBWNiByZW1vdGUgYWRkcmVzcy4NCj4g PiBNb3N0IG9mIHRoZSBpbXBsZW1lbnRhdGlvbnMgSSBrbm93IG9mZiB1c3VhbGx5IG1hcHMgNCBi eXRlIG9mIHRoZQ0KPiA+IExTUi1JRCB3aXRoIGEgbG9jYWwgaXB2NCBpbnRlcmZhY2UgYWRkcmVz cyBpbiB0aGUgc3lzdGVtLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFByYW5qYWwNCj4gPg0KPiA+ DQo+ID4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6dGUuY29tLmNuXQ0K PiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjksIDIwMTIgNDo1NyBQTQ0KPiA+IFRvOiBB aXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKQ0KPiA+IENjOiBtcGxzQGlldGYub3JnOyBEdXR0 YSwgUHJhbmphbCBLIChQcmFuamFsKTsNCnZpc2h3YXMuaWV0ZkBnbWFpbC5jb20NCj4gPg0KPiA+ IFN1YmplY3Q6IFJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2 LTA2DQo+ID4NCj4gPg0KPiA+IEhpIE11c3RhcGhhLA0KPiA+IEkgYWdyZWUsIGFuZCBJIGFsc28g cHJlZmVyIHRvIGRlZmluaW5nIGEgSVB2NiBmb3JtYXRlZCBMU1ItSUQsIGFzIEkNCj4gPiBwb2lu dGVkIG91dCBpbiBteSBmaXJzdCBlbWFpbC4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+IExpemhvbmcN Cj4gPg0KPiA+DQo+ID4gIkFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpIg0KPG11c3RhcGhh LmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiA+ID4gd3JvdGUgMjAxMi8wMy8wMSAwNDoz NTo0MToNCj4gPg0KPiA+ID4gSGkgTGl6aG9uZywNCj4gPiA+IEkgYWN0dWFsbHkgdGhpbmsgdGhh dCB3ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSBhIG5ldyBvbmUgd2hpY2ggd2lsbA0KPiA+ID4gYWNj b21vZGF0ZSBhbiBJUHY2IC8xMjggYWRkcmVzcy4gT3RoZXJ3aXNlLCB0YXJnZXRlZCBMRFAgc2Vz c2lvbnMNCmluDQo+ID4gPiBhIGFsbC1JUHY2IG5ldHdvcmsgd2lsbCBub3QgYmUgcG9zc2libGUu IEkgY2Fubm90IHNlZSB0aGF0DQpvcGVyYXRvcnMNCj4gPiA+IHdpbGwgc3RhcnQgbWFpbnRhaW5p bmcgYSBtYXBwaW5nIG9mIHNvbWUgZ2xvYmFsIG5vbiByb3V0YWJsZQ0KTFNSLWlkDQo+ID4gPiB2 YWx1ZSB0byBhbiBJUHY2IGxvb3BiYWNrIGludGVyZmFjZSBvbiBlYWNoIHJvdXRlciBpbiB0aGUg bmV0d29yay4NCj4gPiA+DQo+ID4gPiBNdXN0YXBoYS4NCj4gPiA+IEZyb206IG1wbHMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCkJlaGFsZg0KPiBP Zg0KPiA+ID4gQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkNCj4gPiA+IFNlbnQ6IFR1ZXNk YXksIEZlYnJ1YXJ5IDA3LCAyMDEyIDEwOjEyIEFNDQo+ID4gPiBUbzogTGl6aG9uZyBKaW47IER1 dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOw0KdmlzaHdhcy5pZXRmQGdtYWlsLmNvbQ0KPiA+ID4g Q2M6IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQo+ID4NCj4gPiA+IExpemhvbmcsDQo+ID4gPiB0 aGUgZXhpc3RpbmcgTFNSLWlkIHdpbGwgZG8gdGhlIGpvYiBhbmQgc2hvdWxkIGJlIHN1cHBvcnRl ZCBzaW5jZQ0KPiA+ID4gdGhlIExTUi1pZCBuZWVkIG5vdCBiZSBhbiBJUCBhZGRyZXNzLiBNb3N0 IGltcGxlbWVudGF0aW9ucyB3aWxsDQo+ID4gPiBhY3R1YWxseSBwb3B1bGF0ZSB0aGUgZmllbGQg d2l0aCBhIC8zMiBhZGRyZXNzIGluIElQdjQgYW5kIHRodXMgSWYNCj4gPiA+IG5lY2Vzc2FyeSB3 ZSBjb3VsZCBkZWZpbmUgYSBuZXcgZm9ybWF0IHRvIGFsbG93IHRoZSB1c2Ugb2YgLzEyOA0KPiA+ IElQdjZhZGRyZXNzZXMuDQo+ID4gPg0KPiA+ID4gTXVzdGFwaGEuDQo+ID4gPg0KPiA+ID4gRnJv bTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6dGUuY29tLmNuXQ0KPiA+ID4gU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAwNiwgMjAxMiAxMDoyMyBQTQ0KPiA+ID4gVG86IER1dHRhLCBQ cmFuamFsIEsgKFByYW5qYWwpOyB2aXNod2FzLmlldGZAZ21haWwuY29tOyBBaXNzYW91aSwNCj4g PiA+IE11c3RhcGhhIChNdXN0YXBoYSkNCj4gPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4gPiBT dWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0w Ng0KPiA+DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPiBJIHdvbmRlciBpZiBpdCBpcyBmZWFzaWJs ZSB0byB1c2UgTERQIGNhcGFiaWxpdHkgdG8gYWR2ZXJ0aXNlIElQdjYNCj4gPiA+IEZFQyB3aXRo b3V0IElQdjYgYWRqYWNlbmN5LCBhbmQgb25seSB1c2Ugb25lIGFkamFjZW5jeSBmb3IgTERQDQo+ ID4gPiBzZXNzaW9uIGluIGR1YWwtc3RhY2sgbmV0d29yay4gTERQIGNhcGFiaWxpdHkgaXMgcGVy IG5vZGUNCj4gPiA+IGNhcGFiaWxpdHksIG5vdCBwZXIgaW50ZXJmYWNlIGNhcGFiaWxpdHkuIEJ1 dCBmb3IgTERQIHRvIGNob29zZQ0KdGhlDQo+ID4gPiBjb3JyZWN0IGRvd25zdHJlYW0gc2Vzc2lv biBhbmQgb3V0cHV0IGludGVyZmFjZSBmb3IgZWFjaCBGRUMsIGl0DQo+ID4gPiBzaG91bGQgYWxz byBjaGVjayBpZiB0aGUgb3V0cHV0IGludGVyZmFjZSBpcyBMRFAgZW5hYmxlZCBvciBub3QuDQpU aGUNCj4gPiA+IGxpbmsgYWRqYWNlbmN5IGNvdWxkIGJlIHVzZWQgdG8gYXNzaXN0IHN1Y2gga2lu ZCBvZiBjaGVja2luZy4NCj4gPiA+DQo+ID4gPiBIb3dldmVyLCBJTU8sIGl0IGlzIHZhbHVhYmxl IHRvIGFsbG93IHR3byBpbmRlcGVuZGVudCBMRFAgc2Vzc2lvbnMNCj4gPiA+IGZvciBJUHY0IGFu ZCBJUHY2IGFzIGFuIG9wdGlvbi4gUmVnYXJkaW5nIHRoZSBmb3JtYXQgZGVmaW5pdGlvbiBpbg0K PiA+ID4gUkZDNTAzNiwgd2UgbWF5IG5lZWQgbmV3IExEUCB2ZXJzaW9uIG51bWJlciB0byBpZGVu dGlmeSBJUHY2DQpMU1ItSUQuDQo+ID4gPiBPciB3ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1J RCBmb3IgSVB2NiB3aXRoIElQdjQsIGJ1dCBJIHByZWZlcg0KPiA+ID4gbmV3IGZvcm1hdCBvZiBM U1ItSUQuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcw0KPiA+ID4gTGl6aG9uZw0KPiA+ID4NCj4gPiA+ DQo+ID4gPiA+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+DQo+ID4gPiA+IE1lc3NhZ2U6IDENCj4g PiA+ID4gRGF0ZTogVHVlLCA3IEZlYiAyMDEyIDA1OjI4OjIxICswNTMwDQo+ID4gPiA+IEZyb206 ICJEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKSINCjxwcmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVj ZW50LmNvbT4NCj4gPiA+ID4gVG86IFZpc2h3YXMgTWFucmFsIDx2aXNod2FzLmlldGZAZ21haWwu Y29tPg0KPiA+ID4gPiBDYzogIkFpc3Nhb3VpLCBNdXN0YXBoYSBcKE11c3RhcGhhXCkiDQo+ID4g PiA+ICAgIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+LCAgICJtcGxzQGll dGYub3JnIg0KPiA+ID4gPiAgICA8bXBsc0BpZXRmLm9yZz4NCj4gPiA+ID4gU3ViamVjdDogUmU6 IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYNCj4gPiA+ID4g TWVzc2FnZS1JRDoNCj4gPiA+ID4NCj4gPEM1ODQwNDY0NjZFRDIyNENBOTJDMUJDMzMxM0I5NjNF MDlFRkU4RDY2N0BJTkJBTlNYQ0hNQlNBMy5pbi4NCj4gPiA+ID4gYWxjYXRlbC1sdWNlbnQuY29t Pg0KPiA+ID4gPg0KPiA+ID4gPiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVz LWFzY2lpIg0KPiA+ID4gPg0KPiA+ID4gPiBJIHdvdWxkIHJhdGhlciBmb3IgY29tcGxldGUgc2Vw YXJhdGlvbiB3aXRoIG11bHRpcGxlIGxzci1pZA0KYmVjYXVzZQ0KPiA+ID4gPiBoYXZpbmcgc2Vw YXJhdGUgbGluayBhZGphY2VuY2llcyBkb2VzIG5vdCByZWFsbHkgc29sdmVkIGFueQ0KcHJvYmxl bS4NCj4gPiA+ID4gU2luY2UgaGVsbG8gYWRqYWNlbmNpZXMgYXJlIGFzc29jaWF0ZWQgd2l0aCBh IGxpbmssIHN0aWxsIGZhdGUNCj4gPiA+ID4gc2hhcmluZyB3b3VsZCBjb250aW51ZSBvdmVyIHRo ZSBzaW5nbGUgbGRwL3RjcCBzZXNzaW9uIGZvciBJUFY0DQphbmQNCj4gSVBWNi4NCj4gPiA+ID4g SGF2aW5nIElQVjQgYW5kIElQVjYgc3BlY2lmaWMgaGVsbG8gYWRqYWNlbmNpZXMgb3ZlciBhIGxp bmsNCndvdWxkDQo+ID4gPiA+IG9ubHkgZGVjaWRlIHdoZXRoZXIgc3VjaCBhIGxpbmsgaXMgdG8g YmUgcHJvZ3JhbW1lZCBmb3IgSVBWNCBvcg0KSVBWNg0KPiA+ID4gPiBlZ3Jlc3MgdHJhZmZpYyBi dXQgSSBzZWUgaXQgYXMgb3ZlcmtpbGwgYW5kIHVubmVjZXNzYXJ5DQo+ID4gc2NhbGFiaWxpdHkg aW1wYWN0cy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiBQcmFuamFsDQo+ID4g PiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+ID4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo+ID4gPiBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwNCj4gPiA+IGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZQ0Kb2JsaWdh dGVkDQo+ID4gPiB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMNCj4gPiA+IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQo+ID4gPiBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZA0KPiA+ID4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tDQp0aGV5DQo+ID4gPiBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZQ0KPiA+ ID4gbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVz c2VkIGluIHRoaXMNCj4gPiA+IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNl bmRlci4NCj4gPiA+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURQ0KQW50aS1TcGFtDQo+IHN5c3RlbS4NCg== From he.wenjuan1@zte.com.cn Thu Mar 1 17:23:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C888821E83E6 for ; Thu, 1 Mar 2012 17:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.824 X-Spam-Level: X-Spam-Status: No, score=-98.824 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpUgXVAPON2E for ; Thu, 1 Mar 2012 17:23:15 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0921E83E1 for ; Thu, 1 Mar 2012 17:23:14 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Fri, 2 Mar 2012 08:52:24 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 49094.1509035444; Fri, 2 Mar 2012 09:22:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q221N1S9042595; Fri, 2 Mar 2012 09:23:01 +0800 (GMT-8) (envelope-from he.wenjuan1@zte.com.cn) To: thomas.nadeau@ca.com, kkoushik@cisco.com, riza.cetin@alcatel.be MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.4 June 01, 2004 Message-ID: From: he.wenjuan1@zte.com.cn Date: Fri, 2 Mar 2012 09:22:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-02 09:23:02, Serialize complete at 2012-03-02 09:23:02 Content-Type: multipart/alternative; boundary="=_alternative 000804B6482579B5_=" X-MAIL: mse02.zte.com.cn q221N1S9042595 Cc: mpls@ietf.org Subject: [mpls] questions on RFC6445 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 01:23:15 -0000 This is a multipart message in MIME format. --=_alternative 000804B6482579B5_= Content-Type: text/plain; charset="US-ASCII" Hi authors & others, I have some questions on RFC6445, see below, 1,In section 4.2.3: " mplsFrrOne2OnePlrTunnelDetourInstance = 6553601, -- -- (100 << 16 | 1) == 6553601 -- 1 is mplsTunnelInstance for the detour LSP -- from mplsTunnelTable. Marked by AAA below. -- Shift 16 to put this into the high-order bits -- 100 is mplsTunnelInstance for the protected tunnel -- from the mplsTunnelTable. Marked by BBB below. -- Need to OR the index value into low-order bits)" [Wenjuan]This description is confusing, which is not consistent with definition of the mplsFrrOne2OnePlrTunnelDetourInstance((100 << 16 | 1) == 6553601). In the section below, the mplsTunnelInstance (100) for the protected tunnel is marked by AAA in mplsTunnelTable(protected tunnel entry), which should be in the high-order bits. 2,In mplsTunnelTable (detour LSP entry): " mplsTunnelIndex = 1, mplsTunnelInstance = 1, -- Indicating detour LSP (higher 16 bits) -- BBB " [Wenjuan]The detour lsp and the protected lsp have the same IngressLSRId,EgressLSRId,TunnelIndex and the mplsTunnelInstance, see the path-specific method in the RFC4090. In this document, the mplsTunnelInstance for the detour lsp is different with protected tunnel instance.I did not find any other description about this instance in the draft. Could you make some clarifications about this mplsTunnelInstance for the detour lsp? 3, "mplsTunnelIngressLSRId = 192.0.2.1, mplsTunnelEgressLSRId = 192.0.2.3, " [Wenjuan]:in this document,the detour lsp's EgressLSRId is the address of the merged point(R3). This description is not consistent with the section 6.3 of the RFC4090. The EgressLSRId of the detour lsp is same with the protected tunnel in the RFC4090. Thanks Wenjuan --=_alternative 000804B6482579B5_= Content-Type: text/html; charset="US-ASCII"
Hi authors & others,

I have some questions on RFC6445, see below,


1,In section 4.2.3:
      " mplsFrrOne2OnePlrTunnelDetourInstance  = 6553601,
       --
       -- (100 << 16 | 1) == 6553601

       -- 1 is mplsTunnelInstance for the detour LSP
       -- from mplsTunnelTable.  Marked by AAA below.
       -- Shift 16 to put this into the high-order bits
 
       -- 100 is mplsTunnelInstance for the protected tunnel
       -- from the mplsTunnelTable.  Marked by BBB below.
       -- Need to OR the index value into low-order bits)"
   
[Wenjuan]This description is confusing, which is not consistent with definition of the mplsFrrOne2OnePlrTunnelDetourInstance((100 << 16 | 1) == 6553601).
In the section below, the mplsTunnelInstance (100) for the protected tunnel is marked by AAA in mplsTunnelTable(protected tunnel entry), which should be in
the high-order bits.  
             

2,In mplsTunnelTable (detour LSP entry):

     " mplsTunnelIndex              = 1,
      mplsTunnelInstance           = 1,
                             -- Indicating detour LSP (higher 16 bits)
                             -- BBB "

[Wenjuan]The detour lsp and the protected lsp have the same IngressLSRId,EgressLSRId,TunnelIndex and the mplsTunnelInstance, see the path-specific method in the RFC4090.
In this document, the mplsTunnelInstance for the detour lsp is different with protected tunnel instance.I did not find any other description about this instance in the draft.
Could you make some clarifications about this mplsTunnelInstance for the detour lsp?

3,        
      "mplsTunnelIngressLSRId       = 192.0.2.1,
       mplsTunnelEgressLSRId        = 192.0.2.3, "

[Wenjuan]:in this document,the detour lsp's EgressLSRId is the address of the merged point(R3). This description is not consistent with the section 6.3 of the RFC4090.
The EgressLSRId of the detour lsp is same with the protected tunnel in the RFC4090.


Thanks
Wenjuan --=_alternative 000804B6482579B5_=-- From rajiva@cisco.com Thu Mar 1 18:44:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFFE21F8A06 for ; Thu, 1 Mar 2012 18:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.185 X-Spam-Level: X-Spam-Status: No, score=-9.185 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzQy6WJXgz8h for ; Thu, 1 Mar 2012 18:44:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4A21F8A02 for ; Thu, 1 Mar 2012 18:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=12444; q=dns/txt; s=iport; t=1330656245; x=1331865845; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Ni4VI3j8cxbVeZ3MBtYpf0hhW7NIIM0cXvEm9eOVt9E=; b=fy317tH/9W9sTA8EVIS1iMo9lp6VL+FlfBl/5hFKDCrmbH4I/I+ClXhk Xx8F6Zst/42VLo8+l4BSjsrGKe6zvtCpaeGcRW8Tfb3d+Xj0EBnbPQ2l+ 8AOTIIGQQ2mg0UDTvPLEBEWmobJRCy1Raob6lRkK9VwmsaPY8PgzBg/gk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANsyUE+tJXHA/2dsb2JhbAA5CoUyrWx4gQeBfQEBAQQSARANBDgCCAMMBAIBCBEDAQEBAQICBgYXAQICAgEBHyUJCAEBBAESCBqHZJsBAYxlkXWBL4dsYgmCKgUCAQIDAgkBBAQBAQEBCgECBTsYhUgHAQ0RBBSCGzNjBIhPmAeHdoE9 X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="63190492" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 02 Mar 2012 02:44:04 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q222i4c0010576; Fri, 2 Mar 2012 02:44:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 20:44:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 1 Mar 2012 20:44:02 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3h+t1pocdfUrCSq6tiXLdLEPZMgATF64QAAuPoBYABtb58A== References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , , X-OriginalArrivalTime: 02 Mar 2012 02:44:04.0699 (UTC) FILETIME=[55141AB0:01CCF81E] Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 02:44:06 -0000 SGkgTXVzdGFwaGEsDQoNCkkgd2FzIHJlZmVycmluZyB0byBMU1IgSUQgYW5kIHJvdXRlci1pZCBk aXNjdXNzaW9uIGluIG15IHJlc3BvbnNlLg0KUm91dGVyLWlkIHNlbGVjdGlvbiBoYXMgbm90aGlu ZyB0byBkbyB3aXRoIHNlcGFyYXRlIExEUCBzZXNzaW9uIHBlciBBRkkuDQoNCkRvIHlvdSBkaXNh Z3JlZSB0byB3aGF0IEkgZGVzY3JpYmVkIHdydCBMU1IgSUQgYmVpbmcgNC1vY3RldD8gDQoNCkNo ZWVycywNClJhaml2DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWlz c2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkgW21haWx0bzptdXN0YXBoYS5haXNzYW91aUBhbGNh dGVsLQ0KPiBsdWNlbnQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMDEsIDIwMTIgNjoy NSBQTQ0KPiBUbzogUmFqaXYgQXNhdGkgKHJhaml2YSk7ICdsaXpob25nLmppbkB6dGUuY29tLmNu JzsgJ3Zpc2h3YXMuaWV0ZkBnbWFpbC5jb20nDQo+IENjOiAnbXBsc0BpZXRmLm9yZycNCj4gU3Vi amVjdDogUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYN Cj4gDQo+IFJhaml2LA0KPiBZb3UgaGF2ZSBoZWFyZCB0aGUgcmVxdWlyZW1lbnRzIGZyb20gb3Bl cmF0b3JzIG9uIHRoaXMgbWFpbGluZyBsaXN0IGFza2luZw0KPiBmb3Igc2VwYXJhdGUgTERQIHNl c3Npb25zIGZvciBJUHY0IGFuZCBJUHY2Lg0KPiANCj4gVGhlIGRyYWZ0IGluIGl0cyBjdXJyZW50 IGZvcm0gZG9lcyBub3QgbWVldCB0aGlzIHJlcXVpcmVtZW50IGFuZCB5ZXQgaXQgYWRkcw0KPiBj b25zdHJhaW50cyB3aGljaCBtYWtlcyBpdCBpbmNvbXBhdGlibGUgd2l0aCBSRkM1MDM2LiBJdCBh bHNvIGRvdWJsZXMgdGhlDQo+IG51bWJlciBvZiBIZWxsbyBhZGphY2VuY2llcyBmb3Igbm8gZ2Fp bi4NCj4gDQo+IFdoYXQgaXMgdGhlIHBvaW50IG9mIGNhcnJ5aW5nIGZvcndhcmQgdGhpcyBkcmFm dCBhcyBpcz8NCj4gDQo+IE11c3RhcGhhLg0KPiBTZW50IGZyb20gbXkgQmxhY2tiZXJyeSENCj4g DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogUmFqaXYgQXNhdGkgKHJh aml2YSkgPHJhaml2YUBjaXNjby5jb20+DQo+IFRvOiBMaXpob25nIEppbiA8bGl6aG9uZy5qaW5A enRlLmNvbS5jbj47IFZpc2h3YXMgTWFucmFsDQo+IDx2aXNod2FzLmlldGZAZ21haWwuY29tPg0K PiBDYzogQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IG1wbHNAaWV0Zi5vcmcgPG1wbHNA aWV0Zi5vcmc+DQo+IFNlbnQ6IFRodSBNYXIgMDEgMTI6MDc6MjMgMjAxMg0KPiBTdWJqZWN0OiBS RTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNg0KPiANCj4g SSBhZ3JlZS4gQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gJiBhZ3JlZW1lbnQsIHdlIHdpbGwgcHJv Y2VlZCB3aXRoIHRoZQ0KPiBkb2N1bWVudCBhcyBpdC1pcy4NCj4gDQo+IEl0IGlzIHdvcnRoIG5v dGluZyB0aGF0IHRoaXMgKExTUiBJRCkgcmVhbGx5IHJlbGF0ZXMgdG8gcm91dGVyLWlkLCB3aGlj aA0KPiBpcyB1c2VkIGJ5IG5vdCBvbmx5IExEUCwgYnV0IGFsc28gb3RoZXIgcHJvdG9jb2xzIChl LmcuIEJHUCwgT1NQRikuIE9mDQo+IGNvdXJzZSwgZWFjaCBwcm90b2NvbCBjb3VsZCB1c2UgdGhl IGNvbW1vbiByb3V0ZXItaWQgb3IgYSBkaWZmZXJlbnQgb25lLg0KPiBTdHJpY3RseSBzcGVha2lu ZywgYWxsIHRoZXNlIHByb3RvY29scyBkZWZpbmUgcm91dGVyLWlkIHRvIGJlIG5vdA0KPiByb3V0 YWJsZSBhbmQgbGV2ZXJhZ2UgdGhlIHNhbWUgNC1vY3RldCBudW1iZXIgZm9yIElQdjYgYXMgd2Vs bC4NCj4gDQo+IEZvciBleCwgT25lIGNvdWxkIGxvb2sgYXQgUkZDIDYyODYsIHdoaWNoIHVwZGF0 ZWQgdGhlIGJhc2UgQkdQIHNwZWMNCj4gUkZDNDI3MSwgdG8gZW5zdXJlIHRoZSB1c2FnZSBvZiA0 LW9jdGV0IGFzIHRoZSBCR1AgSUQgaW4gdGhlIGNvbnRleHQgb2YNCj4gSVB2Ni4NCj4gDQo+IFRo ZXJlIGlzIG5vIGJlbmVmaXQgJiByZWFzb24gdG8gY2hhbmdlIExTUiBJRCBkZWZpbml0aW9uIDMy LWJpdCB0bw0KPiAxMjgtYml0IGZvciBMRFAgd2l0aG91dCBjb25zaWRlcmluZyB0aGUgYmlnZ2Vy IHBpY3R1cmUgaGF2aW5nIG90aGVyDQo+IHByb3RvY29scyBpbiB0aGUgbmV0d29yay4gVGhpcyBz cGVjaWZpYyBpc3N1ZSBoYXMgYmVlbiB2aXNpdGVkIGJlZm9yZQ0KPiBhbmQgY2xvc2VkLg0KPiAN Cj4gQ2hlZXJzLA0KPiBSYWppdg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4gTGl6aG9uZyBKaW4NCj4gPiBTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMDEsIDIwMTIgMzo0NiBBTQ0KPiA+IFRvOiBWaXNod2FzIE1hbnJhbA0KPiA+IENj OiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQo+ ID4NCj4gPg0KPiA+DQo+ID4gPiBIaSBMaXpob25nLyBQcmFuamFsLyBNdXN0YXBoYSwNCj4gPiA+ DQo+ID4gPiBTbyB0aGUgdHdvIG1haW4gY29tbWVudHMgdGhhdCBoYXZlIGNvbWUgYWZ0ZXIgbGFz dCBjYWxsIGFyZToNCj4gPiA+DQo+ID4gPiAxLiBBbGxvdyBmb3Igc2VwYXJhdGlvbiBvZiBzZXNz aW9ucyBhbG9uZyB3aXRoIHRoZSBhZGphY2VuY3kuDQo+ID4gPiAyLiBBbGxvdyBmb3IgYW4gSVB2 NiBiYXNlZCBMU1ItSUQuDQo+ID4gPg0KPiA+ID4gVGhlIHNlY29uZCBjb3VsZCBsZWFkIHRvIGNo YW5nZXMgcmVxdWlyZWQgaW4gYm90aCBPU1BGIGFuZCBJUy1JUywgYXMNCj4gPiA+IHdlbGwgYmVj YXVzZSB0aGUgbmV3IExTUiBJRCB3b3VsZCB0aGVuIG5lZWQgdG8gYmUgZXhjaGFuZ2VkLiBXZQ0K PiA+ID4gY291bGQgdHJlYXQgaXQgYXMgYW4gZW5oYW5jZW1lbnQgaW5zdGVhZCBpbiBteSB2aWV3 LiBEbyB5b3UgYWdyZWU/DQo+ID4gW0xpemhvbmddIGFncmVlLCBidXQgYXMgS2FtcmFuIHBvaW50 ZWQgb3V0IGFsc28gaW4gYW5vdGhlciBlbWFpbCwgaXQNCj4gaXMgbm90DQo+ID4gbmVjZXNzYXJ5 IHRvIGZsb29kIExTUi1JRCBpbiByb3V0aW5nIHByb3RvY29sLCB0aGUgdHJhbnNwb3J0IGFkZHJl c3MNCj4gaW4gaGVsbG8NCj4gPiBtZXNzYWdlIGlzIHJlcXVpcmVkIHRvIGJlIGZsb29kZWQuDQo+ ID4NCj4gPiBSZWdhcmRzDQo+ID4gTGl6aG9uZw0KPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0K PiA+ID4gVmlzaHdhcw0KPiA+DQo+ID4gPiBPbiBXZWQsIEZlYiAyOSwgMjAxMiBhdCA1OjAzIFBN LCBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKSA8DQo+ID4gPiBwcmFuamFsLmR1dHRhQGFsY2F0 ZWwtbHVjZW50LmNvbT4gd3JvdGU6DQo+ID4gPiBZZXMsIEkgc3VwcG9ydCB0aGF0IHRvby4gVGhl cmUgd291bGQgYmUgbmV0d29yayBtYW5hZ2VtZW50IGlzc3Vlcw0KPiA+ID4gd2l0aCBtYXBwaW5n IG9mIDQgYnl0ZSBMU1ItSUQgdG8gYW4gSVBWNiByZW1vdGUgYWRkcmVzcy4NCj4gPiA+IE1vc3Qg b2YgdGhlIGltcGxlbWVudGF0aW9ucyBJIGtub3cgb2ZmIHVzdWFsbHkgbWFwcyA0IGJ5dGUgb2Yg dGhlDQo+ID4gPiBMU1ItSUQgd2l0aCBhIGxvY2FsIGlwdjQgaW50ZXJmYWNlIGFkZHJlc3MgaW4g dGhlIHN5c3RlbS4NCj4gPiA+DQo+ID4gPiBUaGFua3MsDQo+ID4gPiBQcmFuamFsDQo+ID4gPg0K PiA+ID4NCj4gPiA+IEZyb206IExpemhvbmcgSmluIFttYWlsdG86bGl6aG9uZy5qaW5AenRlLmNv bS5jbl0NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjksIDIwMTIgNDo1NyBQTQ0K PiA+ID4gVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpDQo+ID4gPiBDYzogbXBsc0Bp ZXRmLm9yZzsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7DQo+IHZpc2h3YXMuaWV0ZkBnbWFp bC5jb20NCj4gPiA+DQo+ID4gPiBTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtbXBscy1sZHAtaXB2Ni0wNg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIaSBNdXN0YXBoYSwN Cj4gPiA+IEkgYWdyZWUsIGFuZCBJIGFsc28gcHJlZmVyIHRvIGRlZmluaW5nIGEgSVB2NiBmb3Jt YXRlZCBMU1ItSUQsIGFzIEkNCj4gPiA+IHBvaW50ZWQgb3V0IGluIG15IGZpcnN0IGVtYWlsLg0K PiA+ID4NCj4gPiA+IFRoYW5rcw0KPiA+ID4gTGl6aG9uZw0KPiA+ID4NCj4gPiA+DQo+ID4gPiAi QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkiDQo+IDxtdXN0YXBoYS5haXNzYW91aUBhbGNh dGVsLWx1Y2VudC5jb20NCj4gPiA+ID4gd3JvdGUgMjAxMi8wMy8wMSAwNDozNTo0MToNCj4gPiA+ DQo+ID4gPiA+IEhpIExpemhvbmcsDQo+ID4gPiA+IEkgYWN0dWFsbHkgdGhpbmsgdGhhdCB3ZSB3 b3VsZCBuZWVkIHRvIGRlZmluZSBhIG5ldyBvbmUgd2hpY2ggd2lsbA0KPiA+ID4gPiBhY2NvbW9k YXRlIGFuIElQdjYgLzEyOCBhZGRyZXNzLiBPdGhlcndpc2UsIHRhcmdldGVkIExEUCBzZXNzaW9u cw0KPiBpbg0KPiA+ID4gPiBhIGFsbC1JUHY2IG5ldHdvcmsgd2lsbCBub3QgYmUgcG9zc2libGUu IEkgY2Fubm90IHNlZSB0aGF0DQo+IG9wZXJhdG9ycw0KPiA+ID4gPiB3aWxsIHN0YXJ0IG1haW50 YWluaW5nIGEgbWFwcGluZyBvZiBzb21lIGdsb2JhbCBub24gcm91dGFibGUNCj4gTFNSLWlkDQo+ ID4gPiA+IHZhbHVlIHRvIGFuIElQdjYgbG9vcGJhY2sgaW50ZXJmYWNlIG9uIGVhY2ggcm91dGVy IGluIHRoZSBuZXR3b3JrLg0KPiA+ID4gPg0KPiA+ID4gPiBNdXN0YXBoYS4NCj4gPiA+ID4gRnJv bTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSBP bg0KPiBCZWhhbGYNCj4gPiBPZg0KPiA+ID4gPiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhh KQ0KPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwNywgMjAxMiAxMDoxMiBBTQ0KPiA+ ID4gPiBUbzogTGl6aG9uZyBKaW47IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOw0KPiB2aXNo d2FzLmlldGZAZ21haWwuY29tDQo+ID4gPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1 YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2 DQo+ID4gPg0KPiA+ID4gPiBMaXpob25nLA0KPiA+ID4gPiB0aGUgZXhpc3RpbmcgTFNSLWlkIHdp bGwgZG8gdGhlIGpvYiBhbmQgc2hvdWxkIGJlIHN1cHBvcnRlZCBzaW5jZQ0KPiA+ID4gPiB0aGUg TFNSLWlkIG5lZWQgbm90IGJlIGFuIElQIGFkZHJlc3MuIE1vc3QgaW1wbGVtZW50YXRpb25zIHdp bGwNCj4gPiA+ID4gYWN0dWFsbHkgcG9wdWxhdGUgdGhlIGZpZWxkIHdpdGggYSAvMzIgYWRkcmVz cyBpbiBJUHY0IGFuZCB0aHVzIElmDQo+ID4gPiA+IG5lY2Vzc2FyeSB3ZSBjb3VsZCBkZWZpbmUg YSBuZXcgZm9ybWF0IHRvIGFsbG93IHRoZSB1c2Ugb2YgLzEyOA0KPiA+ID4gSVB2NmFkZHJlc3Nl cy4NCj4gPiA+ID4NCj4gPiA+ID4gTXVzdGFwaGEuDQo+ID4gPiA+DQo+ID4gPiA+IEZyb206IExp emhvbmcgSmluIFttYWlsdG86bGl6aG9uZy5qaW5AenRlLmNvbS5jbl0NCj4gPiA+ID4gU2VudDog TW9uZGF5LCBGZWJydWFyeSAwNiwgMjAxMiAxMDoyMyBQTQ0KPiA+ID4gPiBUbzogRHV0dGEsIFBy YW5qYWwgSyAoUHJhbmphbCk7IHZpc2h3YXMuaWV0ZkBnbWFpbC5jb207IEFpc3Nhb3VpLA0KPiA+ ID4gPiBNdXN0YXBoYSAoTXVzdGFwaGEpDQo+ID4gPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4g PiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1p cHY2LTA2DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBIaSwNCj4gPiA+ID4gSSB3b25kZXIgaWYg aXQgaXMgZmVhc2libGUgdG8gdXNlIExEUCBjYXBhYmlsaXR5IHRvIGFkdmVydGlzZSBJUHY2DQo+ ID4gPiA+IEZFQyB3aXRob3V0IElQdjYgYWRqYWNlbmN5LCBhbmQgb25seSB1c2Ugb25lIGFkamFj ZW5jeSBmb3IgTERQDQo+ID4gPiA+IHNlc3Npb24gaW4gZHVhbC1zdGFjayBuZXR3b3JrLiBMRFAg Y2FwYWJpbGl0eSBpcyBwZXIgbm9kZQ0KPiA+ID4gPiBjYXBhYmlsaXR5LCBub3QgcGVyIGludGVy ZmFjZSBjYXBhYmlsaXR5LiBCdXQgZm9yIExEUCB0byBjaG9vc2UNCj4gdGhlDQo+ID4gPiA+IGNv cnJlY3QgZG93bnN0cmVhbSBzZXNzaW9uIGFuZCBvdXRwdXQgaW50ZXJmYWNlIGZvciBlYWNoIEZF QywgaXQNCj4gPiA+ID4gc2hvdWxkIGFsc28gY2hlY2sgaWYgdGhlIG91dHB1dCBpbnRlcmZhY2Ug aXMgTERQIGVuYWJsZWQgb3Igbm90Lg0KPiBUaGUNCj4gPiA+ID4gbGluayBhZGphY2VuY3kgY291 bGQgYmUgdXNlZCB0byBhc3Npc3Qgc3VjaCBraW5kIG9mIGNoZWNraW5nLg0KPiA+ID4gPg0KPiA+ ID4gPiBIb3dldmVyLCBJTU8sIGl0IGlzIHZhbHVhYmxlIHRvIGFsbG93IHR3byBpbmRlcGVuZGVu dCBMRFAgc2Vzc2lvbnMNCj4gPiA+ID4gZm9yIElQdjQgYW5kIElQdjYgYXMgYW4gb3B0aW9uLiBS ZWdhcmRpbmcgdGhlIGZvcm1hdCBkZWZpbml0aW9uIGluDQo+ID4gPiA+IFJGQzUwMzYsIHdlIG1h eSBuZWVkIG5ldyBMRFAgdmVyc2lvbiBudW1iZXIgdG8gaWRlbnRpZnkgSVB2Ng0KPiBMU1ItSUQu DQo+ID4gPiA+IE9yIHdlIHVzZSBkaWZmZXJlbnQgMzJiaXQgTFNSLUlEIGZvciBJUHY2IHdpdGgg SVB2NCwgYnV0IEkgcHJlZmVyDQo+ID4gPiA+IG5ldyBmb3JtYXQgb2YgTFNSLUlELg0KPiA+ID4g Pg0KPiA+ID4gPiBSZWdhcmRzDQo+ID4gPiA+IExpemhvbmcNCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBNZXNzYWdlOiAx DQo+ID4gPiA+ID4gRGF0ZTogVHVlLCA3IEZlYiAyMDEyIDA1OjI4OjIxICswNTMwDQo+ID4gPiA+ ID4gRnJvbTogIkR1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpIg0KPiA8cHJhbmphbC5kdXR0YUBh bGNhdGVsLWx1Y2VudC5jb20+DQo+ID4gPiA+ID4gVG86IFZpc2h3YXMgTWFucmFsIDx2aXNod2Fz LmlldGZAZ21haWwuY29tPg0KPiA+ID4gPiA+IENjOiAiQWlzc2FvdWksIE11c3RhcGhhIFwoTXVz dGFwaGFcKSINCj4gPiA+ID4gPiAgICA8bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQu Y29tPiwgICAibXBsc0BpZXRmLm9yZyINCj4gPiA+ID4gPiAgICA8bXBsc0BpZXRmLm9yZz4NCj4g PiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1s ZHAtaXB2Ni0wNg0KPiA+ID4gPiA+IE1lc3NhZ2UtSUQ6DQo+ID4gPiA+ID4NCj4gPg0KPiA8QzU4 NDA0NjQ2NkVEMjI0Q0E5MkMxQkMzMzEzQjk2M0UwOUVGRThENjY3QElOQkFOU1hDSE1CU0EzLmlu Lg0KPiA+ID4gPiA+IGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IENv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBJIHdvdWxkIHJhdGhlciBmb3IgY29tcGxldGUgc2VwYXJhdGlvbiB3aXRoIG11bHRp cGxlIGxzci1pZA0KPiBiZWNhdXNlDQo+ID4gPiA+ID4gaGF2aW5nIHNlcGFyYXRlIGxpbmsgYWRq YWNlbmNpZXMgZG9lcyBub3QgcmVhbGx5IHNvbHZlZCBhbnkNCj4gcHJvYmxlbS4NCj4gPiA+ID4g PiBTaW5jZSBoZWxsbyBhZGphY2VuY2llcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGEgbGluaywgc3Rp bGwgZmF0ZQ0KPiA+ID4gPiA+IHNoYXJpbmcgd291bGQgY29udGludWUgb3ZlciB0aGUgc2luZ2xl IGxkcC90Y3Agc2Vzc2lvbiBmb3IgSVBWNA0KPiBhbmQNCj4gPiBJUFY2Lg0KPiA+ID4gPiA+IEhh dmluZyBJUFY0IGFuZCBJUFY2IHNwZWNpZmljIGhlbGxvIGFkamFjZW5jaWVzIG92ZXIgYSBsaW5r DQo+IHdvdWxkDQo+ID4gPiA+ID4gb25seSBkZWNpZGUgd2hldGhlciBzdWNoIGEgbGluayBpcyB0 byBiZSBwcm9ncmFtbWVkIGZvciBJUFY0IG9yDQo+IElQVjYNCj4gPiA+ID4gPiBlZ3Jlc3MgdHJh ZmZpYyBidXQgSSBzZWUgaXQgYXMgb3ZlcmtpbGwgYW5kIHVubmVjZXNzYXJ5DQo+ID4gPiBzY2Fs YWJpbGl0eSBpbXBhY3RzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLA0KPiA+ID4gPiA+ IFByYW5qYWwNCj4gPiA+ID4gPg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiBaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCj4gPiA+ID4g bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsDQo+ID4gPiA+IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZQ0KPiBvYmxpZ2F0ZWQNCj4gPiA+ID4gdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzDQo+ID4gPiA+ IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+ID4gPiA+IFRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQo+ID4g PiA+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hvbQ0KPiB0aGV5DQo+ID4gPiA+IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlDQo+ID4gPiA+IG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzDQo+ID4g PiA+IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4gPiA+ID4g VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRF DQo+IEFudGktU3BhbQ0KPiA+IHN5c3RlbS4NCg== From mtinka@globaltransit.net Thu Mar 1 19:09:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84BC21E8012 for ; Thu, 1 Mar 2012 19:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwV08FL4MDhZ for ; Thu, 1 Mar 2012 19:09:08 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 14C1821E800E for ; Thu, 1 Mar 2012 19:09:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3Iri-0002YJ-72; Fri, 02 Mar 2012 11:09:06 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Fri, 2 Mar 2012 11:09:02 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1570772.LKULfF7hFl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021109.05568.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:09:09 -0000 --nextPart1570772.LKULfF7hFl Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 10:44:02 AM Rajiv Asati (rajiva)=20 wrote: > I was referring to LSR ID and router-id discussion in my > response. Router-id selection has nothing to do with > separate LDP session per AFI. >=20 > Do you disagree to what I described wrt LSR ID being > 4-octet? Speaking operationally, we have experience (as all operators=20 would) with 4-byte Router ID's being used for IPv6=20 implementation of MP-BGP and OSPFv3 (we use IS-IS in our=20 network, but having ran OSPFv3 in a previous life, that=20 counts). So technically, I would not be opposed to having a 4-byte=20 LSR-ID which conforms to how BGP for IPv6, OSPFv3 and=20 friends do it. However, I would like to be able to setup=20 IPv4 LDP-based LSP's using a /32 IPv4 destination address,=20 and do the same for IPv6 LDP-based LSP's using a /128 IPv6=20 destination address. I would not be overly inclined to wanting a 16-byte LSR-ID=20 for LDPv6. The LSR-ID issue should be decoupled from the LSP=20 session AF issue. Of course, for some implementations that allow you to=20 manually specify which interface the router should choose=20 for the LDP LSR-ID (defining the Loopback interface tends to=20 be typical), they would need to take dual-stack interfaces=20 into account, and do the right thing in IPv6-aware LDP code,=20 based on what is finally agreed on on this mailing list. Mark. --nextPart1570772.LKULfF7hFl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUDnRAAoJEGcZuYTeKm+GfxcQAMK7pnXaLT3hADFbhOqlKEY4 7sxcF3+eZUxAi63n982K0ZhINCDE6/V826CAjSlL41wE8zWfx+10VhCBPSa9tj5i Kc+1OMmUGwgazoYyX5kMxO2fDkrDiYP0LfRTpvF0T+6shgbL/E/44OVJrlA42fcZ aqrL5ElbVMS7w5jIpAvtVxQejQLu77Y91lfxRZXkmCQE6IqCcNP6RhADfqLuZxaK 6yw/GPeP+t6VKnjq0bX9tohdOFzAoF74kCrFNCBYhWB/q+YBcDIM9kXGKnPmY54k WuhoacHmieKX7NcAmE7v8+yBfXpgPTZ+eXIBZcif+YB7dRoYnGhATEUmCP8TaBeF lyUvgOKbkqDA/KaytO0u8gR1zSnQMR99VPWT6Nc/WAuqDaxNGDthxKAt0KjVjPcP ujTU9BB/9UZ8VfXaF9WSCjtSL5VQSj0OpVKBGcP+4Dae6iz7FexqIEN64kh4eogC on2FHNqRaN7I+b+c+nfrpg12U7xT9DY/UjL4RWGVyDxsDOfqOoCzGjc9qo42noI9 77YyadziX5vBYD51x6hL4cdtnU/hH1BEV0AvBLpdbZdrzgZPGKypKegHy1gHEd92 t3zT0sYegdIZPAuTbNFVcopeGHePaAi1ByOQP/boWj2X3Io9q8mQGpTLt/CgWEC3 mJR2MIKq2NKb8LuSlxjT =wMYu -----END PGP SIGNATURE----- --nextPart1570772.LKULfF7hFl-- From rajiva@cisco.com Thu Mar 1 19:35:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CBD21E807F for ; Thu, 1 Mar 2012 19:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.514 X-Spam-Level: X-Spam-Status: No, score=-9.514 tagged_above=-999 required=5 tests=[AWL=1.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUpS5ZNeaP5A for ; Thu, 1 Mar 2012 19:35:28 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57221E8032 for ; Thu, 1 Mar 2012 19:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3801; q=dns/txt; s=iport; t=1330659328; x=1331868928; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1JcYKzNFAP+9Pl/zdc93q/kageTb522vb0UJ7gliKJ0=; b=GgN8JZ0ROLsjBU6TCRUNuHZ9/m3fG/BIjTM6QG6zQCKQi52YIP0a1af1 A3DOYOiG2EvmcIW6Dk7J7/Zw/t8XZypFP64Q/wIcUB3NbQ04xuYgwdELn L9obinMzMmgtmS+HExDpdlcpsPavZLI6jH2DxBt/jkkhTheuExL4pHbwy M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGE/UE+tJV2Y/2dsb2JhbABDtB2BB4F9AQEBAwESAR0KNAsFBwQCAQgRBAEBAQoGBRIBBgEgJQkIAQEEARIIEQmHXwWbGwGeW4kbgxoTBQUBEAI9GAuFRAoVFwEDgktjBIhPmAeHdg X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="63204754" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 02 Mar 2012 03:35:27 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q223ZRMa018928; Fri, 2 Mar 2012 03:35:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 21:35:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 21:35:26 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com> In-Reply-To: <201203021109.05568.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4IdYZUfvBOt7RQWieeR5GG6AvGQAAIbCA References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> <201203021109.05568.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 02 Mar 2012 03:35:27.0668 (UTC) FILETIME=[82ABD740:01CCF825] Cc: "Aissaoui, Mustapha \(Mustapha\)" , lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:35:29 -0000 Hi Mark, Thanks for the response. Pls see inline, > So technically, I would not be opposed to having a 4-byte > LSR-ID which conforms to how BGP for IPv6, OSPFv3 and > friends do it.=20 Thanks for sharing that.=20 Thankfully, this puts LDP inline with other protocols and eliminates any guess-work.=20 I am always told that such consistency (where applicable) is proven to be operationally beneficial. > However, I would like to be able to setup > IPv4 LDP-based LSP's using a /32 IPv4 destination address, > and do the same for IPv6 LDP-based LSP's using a /128 IPv6 > destination address. Absolutely. This is an important point and well covered in section 3. > I would not be overly inclined to wanting a 16-byte LSR-ID > for LDPv6. The LSR-ID issue should be decoupled from the LSP > session AF issue. I agree. IMO, it is indeed decoupled.=20 > Of course, for some implementations that allow you to > manually specify which interface the router should choose > for the LDP LSR-ID (defining the Loopback interface tends to > be typical), they would need to take dual-stack interfaces > into account, and do the right thing in IPv6-aware LDP code, > based on what is finally agreed on on this mailing list. In the past, implementations provided the router-id CLI for any interface IPv4 address to be chosen as router-id for various protocols including LDP. However, many implementations already evolved the CLI to not even give an "interface" IP address for router-id, to accommodate IPv6. Almost all deployed networks already accommodated that. Now that LDP is being enhanced to use IPv6, implementations could evolve LDP router-id as well to accommodate IPv6. This would make LDP router-id to be consistent with other protocols delving with IPv6. And this can certainly be operationally beneficial from IPv6 POV. In fact, one of the implementations allow the router-id to be configured just once and let all protocols just use it, if they wanted. =20 Cheers, Rajiv > -----Original Message----- > From: Mark Tinka [mailto:mtinka@globaltransit.net] > Sent: Thursday, March 01, 2012 10:09 PM > To: mpls@ietf.org > Cc: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); > lizhong.jin@zte.com.cn; vishwas.ietf@gmail.com > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Friday, March 02, 2012 10:44:02 AM Rajiv Asati (rajiva) > wrote: >=20 > > I was referring to LSR ID and router-id discussion in my > > response. Router-id selection has nothing to do with > > separate LDP session per AFI. > > > > Do you disagree to what I described wrt LSR ID being > > 4-octet? >=20 > Speaking operationally, we have experience (as all operators > would) with 4-byte Router ID's being used for IPv6 > implementation of MP-BGP and OSPFv3 (we use IS-IS in our > network, but having ran OSPFv3 in a previous life, that > counts). >=20 > So technically, I would not be opposed to having a 4-byte > LSR-ID which conforms to how BGP for IPv6, OSPFv3 and > friends do it. However, I would like to be able to setup > IPv4 LDP-based LSP's using a /32 IPv4 destination address, > and do the same for IPv6 LDP-based LSP's using a /128 IPv6 > destination address. >=20 > I would not be overly inclined to wanting a 16-byte LSR-ID > for LDPv6. The LSR-ID issue should be decoupled from the LSP > session AF issue. >=20 > Of course, for some implementations that allow you to > manually specify which interface the router should choose > for the LDP LSR-ID (defining the Loopback interface tends to > be typical), they would need to take dual-stack interfaces > into account, and do the right thing in IPv6-aware LDP code, > based on what is finally agreed on on this mailing list. >=20 > Mark. From rajiva@cisco.com Thu Mar 1 19:36:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BAB21E806B for ; Thu, 1 Mar 2012 19:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDckL3lClPCs for ; Thu, 1 Mar 2012 19:36:34 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2521E8090 for ; Thu, 1 Mar 2012 19:36:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=11599; q=dns/txt; s=iport; t=1330659394; x=1331868994; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=xscfSfbzaUXxBGTPpfpHYpptNCcd10C9KYp8rkp1szw=; b=G5DidC0tMtKczMX9AVjNlwr5rJ4kII/sI4cGAQItRuJ+5C8HTPeXIe1G AaOF/rwPm4gCP6pJ8OBCKIiIbFz4fkbUlcRnld5uHyl21yPBhDivuvlJ2 +kc2hGd3QkOg9FbdJTfGgBqo/Hj0qM/MLOJIL2pxK+XEnrdoz1oM3l+hD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGE/UE+tJXG//2dsb2JhbAA5BwO0HYEHgX0BAQEDAQEBAQ8BHQobEQgLBQcEAgEIBwoDAQEBAQoGFwEGASAGHwkIAQEEARIIGodfBQubEAGeW4kbYgmCKgcBAgMKAQEEBAMBCgEDAj2FYAYBAQQIAQYEBAIBBwYLAQmCRGMEiE+YB4d2gT0 X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="63194220" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 02 Mar 2012 03:36:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q223aX2A030056; Fri, 2 Mar 2012 03:36:33 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 21:36:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 21:36:31 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE5CC@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAAJjiyAABSASkAAMbLTw References: <067E6CE33034954AAC05C9EC85E2577C078BE3F8@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" , "Kamran Raza (skraza)" X-OriginalArrivalTime: 02 Mar 2012 03:36:33.0203 (UTC) FILETIME=[A9BBB030:01CCF825] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:36:35 -0000 Pranjal, Thanks for confirming. We are in sync. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Thursday, March 01, 2012 4:42 PM > To: Rajiv Asati (rajiva); Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > I never claimed that it is stated by RFC 5036! Did I? > It's what we "like" to do in most cases..whereas cases do exists where it is > not so (Kamran's last reply). >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Thursday, March 01, 2012 11:18 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > Esp. for T-LDP hellos we would always like to match destination IP of > hello > > packets to match 4 byte LSR-ID, so same is applicable for IPV6. >=20 > Really ! >=20 > Could you please point to the right RFC5036 section that says the above? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Thursday, March 01, 2012 1:09 PM > > To: Shane Amante; Kamran Raza (skraza) > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Esp. for T-LDP hellos we would always like to match destination IP of > hello > > packets to match 4 byte LSR-ID, so same is applicable for IPV6. > > > > TCP Transport address is an after affect - T-LDP hellos should be sent > to the > > correct IPV6 address first before TCP transport address comes into > play. > > > > > > > > ________________________________ > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Shane Amante > > Sent: Thursday, March 01, 2012 7:45 AM > > To: Kamran Raza > > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Kamran, > > > > > > > > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > > > > Firstly, I don't agree that LSR Id be made IPv6 (address) based > and/or > > route-able; LSR Id, as defined in the base spec, is just a 4 octet > unique id and > > need not be routable, though most implementations currently populate > it > > with /32 loopback address. Let's not carry forward a wrong > notion/usage. > > > > > > > > Although, in theory, the LSR-ID "need not be routable", I can say that > in the > > networks I operate it is *always* routable. From a simple > troubleshooting > > PoV, it's extremely easy to: > > > > a) ping the /32 (4-octet) LSR-ID; or, > > > > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > > > > b) use traceroute and/or a routing table to learn the _topological_ > location of > > the /32 (4-octet) LSR-ID in the network ... > > > > > > > > In summary, there is a tremendous amount of operational value in the > 4- > > Byte LSR-ID actually be announced/routed in a network's IGP -- let us > not > > underestimate that. All I'm saying is, let's not go out of our way to > try to > > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely > theoretical > > reasons. > > > > > > > > -shane > > > > > > > > > > > > > > > > Secondly, If there is a need to define new "LDP Identifier" in order > to > > establish/maintain a separate session for IPv6 AF, this should be a > protocol > > change - i.e. we should bump up LDP protocol version in LDP PDU header > > for this, and possibly define new format for "LDP Identifier" in the > context of > > new LDP protocol version. > > > > My 2 cents. > > > > On 12-02-29 8:11 PM, "Vishwas Manral" > msg://1083/vishwas.ietf@gmail.com> > wrote: > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > So the two main comments that have come after last call are: > > > > 1. Allow for separation of sessions along with the adjacency. > > 2. Allow for an IPv6 based LSR-ID. > > > > The second could lead to changes required in both OSPF and IS-IS, as > well > > because the new LSR ID would then need to be exchanged. We could treat > it > > as an enhancement instead in my view. Do you agree? > > > > Thanks, > > Vishwas > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > lucent.com> > wrote: > > > > > > > > Yes, I support that too. There would be network management issues with > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > Most of the implementations I know off usually maps 4 byte of the > LSR-ID > > with a local ipv4 interface address in the system. > > > > Thanks, > > Pranjal > > > > > > > > > > ________________________________ > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Wednesday, February 29, 2012 4:57 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org ; Dutta, Pranjal K > (Pranjal); > > vishwas.ietf@gmail.com > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out > > in my first email. > > > > Thanks > > Lizhong > > > > > > "Aissaoui, Mustapha (Mustapha)" > > wrote > 2012/03/01 > > 04:35:41: > > > > > Hi Lizhong, > > > I actually think that we would need to define a new one which will > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > > a all-IPv6 network will not be possible. I cannot see that operators > > > will start maintaining a mapping of some global non routable LSR-id > > > value to an IPv6 loopback interface on each router in the network. > > > > > > Mustapha. > > > From: mpls-bounces@ietf.org > > [mailto:mpls-bounces@ietf.org] On Behalf Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > msg://1083/vishwas.ietf@gmail.com> > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Lizhong, > > > the existing LSR-id will do the job and should be supported since > > > the LSR-id need not be an IP address. Most implementations will > > > actually populate the field with a /32 address in IPv4 and thus If > > > necessary we could define a new format to allow the use of /128 > > IPv6addresses. > > > > > > Mustapha. > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Monday, February 06, 2012 10:23 PM > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > msg://1083/vishwas.ietf@gmail.com> ; Aissaoui, > > > Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi, > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > session in dual-stack network. LDP capability is per node > > > capability, not per interface capability. But for LDP to choose the > > > correct downstream session and output interface for each FEC, it > > > should also check if the output interface is LDP enabled or not. The > > > link adjacency could be used to assist such kind of checking. > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > new format of LSR-ID. > > > > > > Regards > > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > From: "Dutta, Pranjal K (Pranjal)" > > msg://1083/pranjal.dutta@alcatel-lucent.com> > > > > > To: Vishwas Manral > msg://1083/vishwas.ietf@gmail.com> > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.org > > msg://1083/mpls@ietf.org> " > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Message-ID: > > > > > > > > > msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH > > MBSA3.in> . > > > > alcatel-lucent.com > lucent.com/> > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > I would rather for complete separation with multiple lsr-id > because > > > > having separate link adjacencies does not really solved any > problem. > > > > Since hello adjacencies are associated with a link, still fate > > > > sharing would continue over the single ldp/tcp session for IPV4 > and IPV6. > > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > > only decide whether such a link is to be programmed for IPV4 or > IPV6 > > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > > > > > ________________________________ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > -- > > Syed Kamran Raza > > Technical Leader, SPRSG IOS-XR Routing (MPLS) > > Cisco Systems, Inc., > > Kanata, ON, K2K 3E8, Canada > > Ph: +1 (613) 254-4520 > > http://www.cisco.com > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > From rajiva@cisco.com Thu Mar 1 19:43:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E7121E80BC for ; Thu, 1 Mar 2012 19:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.974 X-Spam-Level: X-Spam-Status: No, score=-8.974 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fea56fkopZ5d for ; Thu, 1 Mar 2012 19:43:07 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E44E621E8099 for ; Thu, 1 Mar 2012 19:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=10878; q=dns/txt; s=iport; t=1330659787; x=1331869387; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7Ujd3PXnfg9WNq7tmlQ7RPXThnIIRpzn4fqQC+X08Iw=; b=hrpHuufi6OeqcKqwcq9/ePjMQtxeggObJ6zVbpeeL5k+YWIO0TFNIhmR mPgZlTTVbK4I6KZxhwpWdMgBn7BidBDq+iJVwz7mPtNQv/cQFPVJ2NbyP CIxzPuAM4qZXR7QX12IzFJG/z2vr1anvVeFD0tHoRX8tIzHS71lxPZTPO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ5AUE+tJV2c/2dsb2JhbAA5BwO0HYEHgX0BAQEDAQEBAQ8BHQobEQgLBQcEAgEIEQMBAQEBCgYXAQYBIAYfCQgBAQQBEggah18FC5sMAZ5biRtiCYIqBwECAwsBBAQDAQMHAQMCPYVgBgEBCQQKBAIBBAMQAQEJgkRjBIhPmAeHdoE9 X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="63196534" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 02 Mar 2012 03:43:06 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q223h6cf012609; Fri, 2 Mar 2012 03:43:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 21:43:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 21:43:04 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE5D0@XMB-RCD-111.cisco.com> In-Reply-To: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz316bQvF+0i3/qQu+O54SgcYIrKQATmH0A References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> From: "Rajiv Asati (rajiva)" To: "t.petch" , "Shane Amante" , "Kamran Raza (skraza)" X-OriginalArrivalTime: 02 Mar 2012 03:43:06.0054 (UTC) FILETIME=[93E3FE60:01CCF826] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:43:08 -0000 Hi Tom, Appreciate you sharing your view. Pls see inline, > Protocols like OSPF that decided that a 32 bit router ID was perfect for all > address families got it absolutely right, IMO. The better organisations I know > make a point of making the router ID an impossible address, so that > regardless of context, it is immediately apparent whether a dotted decimal=20 > number is a routable address or an ID. Well put. The same is true for BGP as well. > Had much experience lately of keying in a 128-bit IPv6 address with pinpoint > accuracy in order to ping a device? Um, it stinks. It certainly does. Not to mention the usage of shift : after every 3-4 numerals. :-) All of sudden, pinging the devices via their hostnames (even if having lower and upper cases) seems easier. =20 Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > t.petch > Sent: Thursday, March 01, 2012 12:17 PM > To: Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > ----- Original Message ----- > From: "Shane Amante" > To: "Kamran Raza" > Cc: "Aissaoui, Mustapha (Mustapha)" lucent.com>; > "Lizhong Jin" ; > Sent: Thursday, March 01, 2012 4:45 PM >=20 > Kamran, >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > > Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or > route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and > need not be routable, though most implementations currently populate it > with /32 > loopback address. Let's not carry forward a wrong notion/usage. >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that in the > networks I operate it is *always* routable. From a simple troubleshooting > PoV, > it's extremely easy to: > a) ping the /32 (4-octet) LSR-ID; or, >=20 > > Had much experience lately of keying in a 128-bit IPv6 address with pinpoint > accuracy in order to ping a device? Um, it stinks. >=20 > Protocols like OSPF that decided that a 32 bit router ID was perfect for all > address families got it absolutely right, IMO. The better organisations I know > make a point of making the router ID an impossible address, so that > regardless > of context, it is immediately apparent whether a dotted decimal number is a > routable address or an ID. >=20 > Tom Petch >=20 > >=20 >=20 >=20 >=20 >=20 > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > b) use traceroute and/or a routing table to learn the _topological_ location of > the /32 (4-octet) LSR-ID in the network ... >=20 > In summary, there is a tremendous amount of operational value in the 4- > Byte > LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to try to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical > reasons. >=20 > -shane >=20 >=20 > > Secondly, If there is a need to define new "LDP Identifier" in order to > establish/maintain a separate session for IPv6 AF, this should be a protocol > change - i.e. we should bump up LDP protocol version in LDP PDU header > for this, > and possibly define new format for "LDP Identifier" in the context of new > LDP > protocol version. > > > > My 2 cents. > > > > On 12-02-29 8:11 PM, "Vishwas Manral" wrote: > > > >> Hi Lizhong/ Pranjal/ Mustapha, > >> > >> So the two main comments that have come after last call are: > >> > >> 1. Allow for separation of sessions along with the adjacency. > >> 2. Allow for an IPv6 based LSR-ID. > >> > >> The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an > enhancement instead in my view. Do you agree? > >> > >> Thanks, > >> Vishwas > >> > >> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: > >>> Yes, I support that too. There would be network management issues > with > mapping of 4 byte LSR-ID to an IPV6 remote address. > >>> Most of the implementations I know off usually maps 4 byte of the LSR- > ID > with a local ipv4 interface address in the system. > >>> > >>> Thanks, > >>> Pranjal > >>> > >>> > >>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > >>> Sent: Wednesday, February 29, 2012 4:57 PM > >>> To: Aissaoui, Mustapha (Mustapha) > >>> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > >>> > >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>> > >>> > >>> Hi Mustapha, > >>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed > out in my first email. > >>> > >>> Thanks > >>> Lizhong > >>> > >>> > >>> "Aissaoui, Mustapha (Mustapha)" lucent.com> wrote > 2012/03/01 04:35:41: > >>> > >>> > Hi Lizhong, > >>> > I actually think that we would need to define a new one which will > >>> > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > >>> > a all-IPv6 network will not be possible. I cannot see that operators > >>> > will start maintaining a mapping of some global non routable LSR-id > >>> > value to an IPv6 loopback interface on each router in the network. > >>> > > >>> > Mustapha. > >>> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > >>> > Aissaoui, Mustapha (Mustapha) > >>> > Sent: Tuesday, February 07, 2012 10:12 AM > >>> > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > >>> > Cc: mpls@ietf.org > >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>> > >>> > Lizhong, > >>> > the existing LSR-id will do the job and should be supported since > >>> > the LSR-id need not be an IP address. Most implementations will > >>> > actually populate the field with a /32 address in IPv4 and thus If > >>> > necessary we could define a new format to allow the use of /128 > IPv6addresses. > >>> > > >>> > Mustapha. > >>> > > >>> > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > >>> > Sent: Monday, February 06, 2012 10:23 PM > >>> > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > >>> > Mustapha (Mustapha) > >>> > Cc: mpls@ietf.org > >>> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>> > >>> > > >>> > Hi, > >>> > I wonder if it is feasible to use LDP capability to advertise IPv6 > >>> > FEC without IPv6 adjacency, and only use one adjacency for LDP > >>> > session in dual-stack network. LDP capability is per node > >>> > capability, not per interface capability. But for LDP to choose the > >>> > correct downstream session and output interface for each FEC, it > >>> > should also check if the output interface is LDP enabled or not. The > >>> > link adjacency could be used to assist such kind of checking. > >>> > > >>> > However, IMO, it is valuable to allow two independent LDP sessions > >>> > for IPv4 and IPv6 as an option. Regarding the format definition in > >>> > RFC5036, we may need new LDP version number to identify IPv6 LSR- > ID. > >>> > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > >>> > new format of LSR-ID. > >>> > > >>> > Regards > >>> > Lizhong > >>> > > >>> > > >>> > > ---------------------------------------------------------------------- > >>> > > > >>> > > Message: 1 > >>> > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > >>> > > From: "Dutta, Pranjal K (Pranjal)" lucent.com> > >>> > > To: Vishwas Manral > >>> > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > >>> > > , "mpls@ietf.org" > >>> > > > >>> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>> > > Message-ID: > >>> > > > >>> > > alcatel-lucent.com > > >>> > > > >>> > > Content-Type: text/plain; charset=3D"us-ascii" > >>> > > > >>> > > I would rather for complete separation with multiple lsr-id because > >>> > > having separate link adjacencies does not really solved any problem. > >>> > > Since hello adjacencies are associated with a link, still fate > >>> > > sharing would continue over the single ldp/tcp session for IPV4 and > IPV6. > >>> > > Having IPV4 and IPV6 specific hello adjacencies over a link would > >>> > > only decide whether such a link is to be programmed for IPV4 or IPV6 > >>> > > egress traffic but I see it as overkill and unnecessary scalability > impacts. > >>> > > > >>> > > Thanks, > >>> > > Pranjal > >>> > > > >>> > -------------------------------------------------------- > >>> > ZTE Information Security Notice: The information contained in this > >>> > mail is solely property of the sender's organization. This mail > >>> > communication is confidential. Recipients named above are obligated > >>> > to maintain secrecy and are not permitted to disclose the contents > >>> > of this communication to others. > >>> > This email and any files transmitted with it are confidential and > >>> > intended solely for the use of the individual or entity to whom they > >>> > are addressed. If you have received this email in error please > >>> > notify the originator of the message. Any views expressed in this > >>> > message are those of the individual sender. > >>> > This message has been scanned for viruses and Spam by ZTE Anti- > Spam > system. > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > -- > > Syed Kamran Raza > > Technical Leader, SPRSG IOS-XR Routing (MPLS) > > Cisco Systems, Inc., > > Kanata, ON, K2K 3E8, Canada > > Ph: +1 (613) 254-4520 > > http://www.cisco.com > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ -------- >=20 >=20 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Thu Mar 1 19:47:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6F821E80F2 for ; Thu, 1 Mar 2012 19:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLXB-ZayTU29 for ; Thu, 1 Mar 2012 19:47:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC721E80EB for ; Thu, 1 Mar 2012 19:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1454; q=dns/txt; s=iport; t=1330660061; x=1331869661; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GZtKfojJZRgZeeUnlfY172y8Cr1YeF9JuJ6P4ot3s0c=; b=f17KGr3FNUp9NNn/pc7bdI8BVG1mdJvrWRk9/zUhzN8e2bitSsxlevQG NGdxtvg1EEh5niFSK4YwPNf4w19D0Jfb4CVdrqXpGwSfHZU8fHh3P1WW6 pqiHWdnIskjQ00HO6PTRNRAd9mhtyzBJTZo1DYLlY0y8gEqZ7DAM0guRU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKtBUE+tJV2Y/2dsb2JhbABDtCqBB4F9AQEBAwESAR0KPwwEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggah18FoSEBlnWMVA8CPRgGAwKFRAosgk9jBIhPn32BPQ X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="63208208" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 02 Mar 2012 03:47:41 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q223leou028916; Fri, 2 Mar 2012 03:47:40 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 21:47:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 21:47:39 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE5D1@XMB-RCD-111.cisco.com> In-Reply-To: <64E677AD-6ED5-488C-8FA3-90F81D411D04@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wy6CUZrmFXW2Q8uE1Z85QK9oRgAY4N5w References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <201203011203.12854.mtinka@globaltransit.net> <64E677AD-6ED5-488C-8FA3-90F81D411D04@castlepoint.net> From: "Rajiv Asati (rajiva)" To: "Shane Amante" , X-OriginalArrivalTime: 02 Mar 2012 03:47:40.0698 (UTC) FILETIME=[379757A0:01CCF827] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 03:47:41 -0000 Hi Mark, Shane, > > rather this isn't the default. If a default needs to be > > implemented by a vendor, then AF separation would be my > > preference. I agree with you.=20 IPv4 and IPv6 info should be kept separate (my preference as well as I alluded to it in my previous email), but we can't mandate the implementation specifics in the RFC. Would you disagree?=20 Cheers, Rajiv > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Thursday, March 01, 2012 10:52 AM > To: mtinka@globaltransit.net > Cc: mpls@ietf.org; Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha) > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > On Feb 29, 2012, at 9:03 PM, Mark Tinka wrote: > > On Thursday, March 01, 2012 11:27:56 AM Rajiv Asati (rajiva) > > wrote: > > > >> Nonetheless, an implementation could choose to optimize, > >> if needed, to keep both address-family related info in a > >> single adjacency structure, but this is all > >> implementation specific. :) > > > > I agree, and as mentioned earlier, as an operator, I'd > > rather this isn't the default. If a default needs to be > > implemented by a vendor, then AF separation would be my > > preference. > > > > However, I'd support including knobs to allow operators to > > consolidate, if they so wished. >=20 > Well said, Mark. As an operator, as well, I concur with both points. >=20 > -shane From shane@castlepoint.net Thu Mar 1 21:45:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE421E8124 for ; Thu, 1 Mar 2012 21:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcsSdVOGl3qN for ; Thu, 1 Mar 2012 21:45:19 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B18B021E8115 for ; Thu, 1 Mar 2012 21:45:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 2A1E726806D; Thu, 1 Mar 2012 22:45:15 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 01 Mar 2012 22:45:14 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=60758; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Shane Amante X-Priority: 3 In-Reply-To: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> Date: Thu, 1 Mar 2012 22:44:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2A789A-D8C6-47C6-9B09-85038B949E67@castlepoint.net> References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 05:45:36 -0000 Tom, On Mar 1, 2012, at 10:16 AM, t.petch wrote: > ----- Original Message ----- > From: "Shane Amante" > To: "Kamran Raza" > Cc: "Aissaoui, Mustapha (Mustapha)" = ; > "Lizhong Jin" ; > Sent: Thursday, March 01, 2012 4:45 PM >=20 > Kamran, >=20 > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: >> Firstly, I don=92t agree that LSR Id be made IPv6 (address) based = and/or > route-able; LSR Id, as defined in the base spec, is just a 4 octet = unique id and > need not be routable, though most implementations currently populate = it with /32 > loopback address. Let=92s not carry forward a wrong notion/usage. >=20 > Although, in theory, the LSR-ID "need not be routable", I can say that = in the > networks I operate it is *always* routable. =46rom a simple = troubleshooting PoV, > it's extremely easy to: > a) ping the /32 (4-octet) LSR-ID; or, >=20 > > Had much experience lately of keying in a 128-bit IPv6 address with = pinpoint > accuracy in order to ping a device? Yes. > Um, it stinks. Um, not really. Again, we're talking about Loopback IP addresses used as = "Router ID's" in protocols. Specifically, here's a real world example = difference between an IPv4 /32 and IPv6 /128 Loopback assigned to a = live, production box (slightly obsfucated to protect the innocent): interface Loopback0 ip address A.BB.CCC.16 255.255.255.255 ipv6 address 2001:XXXX::Y:Z/128 ... in reality, it's a difference of 3-digits. OTOH, if the IPv4 = address was assigned out of traditional IPv4 Class C space, (192/3), = then the difference would have been a single digit. (OK, yes, I'll = concede that if someone is not fortunate enough or properly planned = ahead, then they could end up with a substantially larger number of = digits ... but, that's typically not the case given the ease at which = nearly anyone can get a PIv6 block today). > Protocols like OSPF that decided that a 32 bit router ID was perfect = for all > address families got it absolutely right, IMO. The better = organisations I know > make a point of making the router ID an impossible address, so that = regardless > of context, it is immediately apparent whether a dotted decimal number = is a > routable address or an ID. The larger point I'm trying to bring attention to is that, shockingly, = the world really is moving toward IPv6. Yay! At some point in the future = (certainly not next year, maybe not in 3 - 5 years), we're all going to = want to run IPv6-only networks to reduce OpEx. So, the question I ask = is: what then? a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I can = transport IPv4 "Router ID's" around my network? Or, b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the = purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the = operational reasons I outlined in my previous e-mail? (If so, then I = think it's a moot point if you're typing a IPv4-mapped IPv6 address or a = Native IPv6 address for a Router ID -- they're likely roughly of the = same length). Either approach seems a bit "kludgy" to me. Then again, I'm willing to = be told that I'm the one being the purist. Perhaps, (b) is "the answer" = and I just hadn't gotten the memo. :-) Regardless, I'm suggesting that if we're looking at making a change to = any protocol to support IPv6, let's make sure we briefly, but carefully, = look at what the roadmap holds for the future and weigh the costs of = making a single change to LDP, now, to future-proof LDP (and, other = protocols) for IPv6, rather than make yet more changes down the road ... Just my $0.02, -shane > Tom Petch >=20 > >=20 >=20 >=20 >=20 >=20 > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > b) use traceroute and/or a routing table to learn the _topological_ = location of > the /32 (4-octet) LSR-ID in the network ... >=20 > In summary, there is a tremendous amount of operational value in the = 4-Byte > LSR-ID actually be announced/routed in a network's IGP -- let us not > underestimate that. All I'm saying is, let's not go out of our way to = try to > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely = theoretical > reasons. >=20 > -shane >=20 >=20 >> Secondly, If there is a need to define new =93LDP Identifier=94 in = order to > establish/maintain a separate session for IPv6 AF, this should be a = protocol > change =97 i.e. we should bump up LDP protocol version in LDP PDU = header for this, > and possibly define new format for =93LDP Identifier=94 in the context = of new LDP > protocol version. >>=20 >> My 2 cents. >>=20 >> On 12-02-29 8:11 PM, "Vishwas Manral" wrote: >>=20 >>> Hi Lizhong/ Pranjal/ Mustapha, >>>=20 >>> So the two main comments that have come after last call are: >>>=20 >>> 1. Allow for separation of sessions along with the adjacency. >>> 2. Allow for an IPv6 based LSR-ID. >>>=20 >>> The second could lead to changes required in both OSPF and IS-IS, as = well > because the new LSR ID would then need to be exchanged. We could treat = it as an > enhancement instead in my view. Do you agree? >>>=20 >>> Thanks, >>> Vishwas >>>=20 >>> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: >>>> Yes, I support that too. There would be network management issues = with > mapping of 4 byte LSR-ID to an IPV6 remote address. >>>> Most of the implementations I know off usually maps 4 byte of the = LSR-ID > with a local ipv4 interface address in the system. >>>>=20 >>>> Thanks, >>>> Pranjal >>>>=20 >>>>=20 >>>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>>> Sent: Wednesday, February 29, 2012 4:57 PM >>>> To: Aissaoui, Mustapha (Mustapha) >>>> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); = vishwas.ietf@gmail.com >>>>=20 >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>>=20 >>>> Hi Mustapha, >>>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I = pointed > out in my first email. >>>>=20 >>>> Thanks >>>> Lizhong >>>>=20 >>>>=20 >>>> "Aissaoui, Mustapha (Mustapha)" = wrote > 2012/03/01 04:35:41: >>>>=20 >>>>> Hi Lizhong, >>>>> I actually think that we would need to define a new one which will >>>>> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions = in >>>>> a all-IPv6 network will not be possible. I cannot see that = operators >>>>> will start maintaining a mapping of some global non routable = LSR-id >>>>> value to an IPv6 loopback interface on each router in the network. >>>>>=20 >>>>> Mustapha. >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On = Behalf Of >>>>> Aissaoui, Mustapha (Mustapha) >>>>> Sent: Tuesday, February 07, 2012 10:12 AM >>>>> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); = vishwas.ietf@gmail.com >>>>> Cc: mpls@ietf.org >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>>> Lizhong, >>>>> the existing LSR-id will do the job and should be supported since >>>>> the LSR-id need not be an IP address. Most implementations will >>>>> actually populate the field with a /32 address in IPv4 and thus If >>>>> necessary we could define a new format to allow the use of /128 > IPv6addresses. >>>>>=20 >>>>> Mustapha. >>>>>=20 >>>>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] >>>>> Sent: Monday, February 06, 2012 10:23 PM >>>>> To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, >>>>> Mustapha (Mustapha) >>>>> Cc: mpls@ietf.org >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>>>=20 >>>>> Hi, >>>>> I wonder if it is feasible to use LDP capability to advertise IPv6 >>>>> FEC without IPv6 adjacency, and only use one adjacency for LDP >>>>> session in dual-stack network. LDP capability is per node >>>>> capability, not per interface capability. But for LDP to choose = the >>>>> correct downstream session and output interface for each FEC, it >>>>> should also check if the output interface is LDP enabled or not. = The >>>>> link adjacency could be used to assist such kind of checking. >>>>>=20 >>>>> However, IMO, it is valuable to allow two independent LDP sessions >>>>> for IPv4 and IPv6 as an option. Regarding the format definition in >>>>> RFC5036, we may need new LDP version number to identify IPv6 = LSR-ID. >>>>> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer >>>>> new format of LSR-ID. >>>>>=20 >>>>> Regards >>>>> Lizhong >>>>>=20 >>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> Message: 1 >>>>>> Date: Tue, 7 Feb 2012 05:28:21 +0530 >>>>>> From: "Dutta, Pranjal K (Pranjal)" = >>>>>> To: Vishwas Manral >>>>>> Cc: "Aissaoui, Mustapha \(Mustapha\)" >>>>>> , "mpls@ietf.org" >>>>>> >>>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>>> Message-ID: >>>>>> >>>>> alcatel-lucent.com > >>>>>>=20 >>>>>> Content-Type: text/plain; charset=3D"us-ascii" >>>>>>=20 >>>>>> I would rather for complete separation with multiple lsr-id = because >>>>>> having separate link adjacencies does not really solved any = problem. >>>>>> Since hello adjacencies are associated with a link, still fate >>>>>> sharing would continue over the single ldp/tcp session for IPV4 = and > IPV6. >>>>>> Having IPV4 and IPV6 specific hello adjacencies over a link would >>>>>> only decide whether such a link is to be programmed for IPV4 or = IPV6 >>>>>> egress traffic but I see it as overkill and unnecessary = scalability > impacts. >>>>>>=20 >>>>>> Thanks, >>>>>> Pranjal >>>>>>=20 >>>>> -------------------------------------------------------- >>>>> ZTE Information Security Notice: The information contained in this >>>>> mail is solely property of the sender's organization. This mail >>>>> communication is confidential. Recipients named above are = obligated >>>>> to maintain secrecy and are not permitted to disclose the contents >>>>> of this communication to others. >>>>> This email and any files transmitted with it are confidential and >>>>> intended solely for the use of the individual or entity to whom = they >>>>> are addressed. If you have received this email in error please >>>>> notify the originator of the message. Any views expressed in this >>>>> message are those of the individual sender. >>>>> This message has been scanned for viruses and Spam by ZTE = Anti-Spam > system. >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> -- >> Syed Kamran Raza >> Technical Leader, SPRSG IOS-XR Routing (MPLS) >> Cisco Systems, Inc., >> Kanata, ON, K2K 3E8, Canada >> Ph: +1 (613) 254-4520 >> http://www.cisco.com >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 > = --------------------------------------------------------------------------= ------ >=20 >=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 From rajiva@cisco.com Thu Mar 1 22:02:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270EE21F8B9D for ; Thu, 1 Mar 2012 22:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.018 X-Spam-Level: X-Spam-Status: No, score=-9.018 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBq5njUhuKCa for ; Thu, 1 Mar 2012 22:02:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3D221F8B9C for ; Thu, 1 Mar 2012 22:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=13786; q=dns/txt; s=iport; t=1330668174; x=1331877774; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3rvktpZ0I2BRdoB7W/3M3ssSQifnlQecN4/rxr8vRbY=; b=SEV6ZwZ2D++Qghfjfn6nW1pYvUV1Mn8jJXqzItsTUnQau1OB/0ZfWFSI /DyMd7jIB6o6/MHtm9HNblpmGe/Am+5pg6QzDa6m99HIWJhH6fYeqxiLA 64nTDpxdGTmYk5YNUKIKS6A/BIX8LJfd4z3SUT5bewlY9A7SOVuAIoAzU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEhhUE+tJXG9/2dsb2JhbAA5BwO0HoEHgX0BAQEDAQEBAQ8BHQobEQgLBQcEAgEIEQMBAQEBCgYXAQYBIAYfCQgBAQQBEggah18FC5sqAZ5hiRtiCYIqAQYBAgMLAQQEAwEKAQMCPYVgBgEBCQQKBAIBBAMQAQEJgkRjBIhPmAeHdoE9 X-IronPort-AV: E=Sophos;i="4.73,516,1325462400"; d="scan'208";a="63231629" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 02 Mar 2012 06:02:53 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2262ruv025305; Fri, 2 Mar 2012 06:02:53 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 00:02:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 00:02:51 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE609@XMB-RCD-111.cisco.com> In-Reply-To: <7F2A789A-D8C6-47C6-9B09-85038B949E67@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4N9LLPfB2C9N+RZGsauDjeAza4wAAQ1vg References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> <7F2A789A-D8C6-47C6-9B09-85038B949E67@castlepoint.net> From: "Rajiv Asati (rajiva)" To: "Shane Amante" , "t.petch" X-OriginalArrivalTime: 02 Mar 2012 06:02:53.0472 (UTC) FILETIME=[1B2E6A00:01CCF83A] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:02:58 -0000 Hi Shane, Thankfully, neither approaches are embraced/recommended/considered. > a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I can > transport IPv4 "Router ID's" around my network? Or, No.=20 Router-ID is no longer a routable entity in IPv6 networks. Please refer to BGP (RFC6286) & OSPF (RFC5340). In fact, OSPF (RFC5340) explicitly prohibits Router ID to be any IPv6 address. BGP RFC6286 // The BGP Identifier is a 4-octet, unsigned, non-zero integer that should be unique within an AS. The value of the BGP Identifier // OSPF RFC5340 // o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32 bits. They can no longer be assigned as (IPv6) addresses. // > b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the > purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the > operational reasons I outlined in my previous e-mail? No. It wouldn't make any sense, nor would it help.=20 v4-mapped v6 address is still a v6 address, after all and it wouldn't do any good for 32-bit router-id. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Friday, March 02, 2012 12:45 AM > To: t.petch > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Tom, >=20 > On Mar 1, 2012, at 10:16 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Shane Amante" > > To: "Kamran Raza" > > Cc: "Aissaoui, Mustapha (Mustapha)" lucent.com>; > > "Lizhong Jin" ; > > Sent: Thursday, March 01, 2012 4:45 PM > > > > Kamran, > > > > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > >> Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or > > route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id > and > > need not be routable, though most implementations currently populate it > with /32 > > loopback address. Let's not carry forward a wrong notion/usage. > > > > Although, in theory, the LSR-ID "need not be routable", I can say that in the > > networks I operate it is *always* routable. From a simple troubleshooting > PoV, > > it's extremely easy to: > > a) ping the /32 (4-octet) LSR-ID; or, > > > > > > Had much experience lately of keying in a 128-bit IPv6 address with > pinpoint > > accuracy in order to ping a device? >=20 > Yes. >=20 >=20 > > Um, it stinks. >=20 > Um, not really. Again, we're talking about Loopback IP addresses used as > "Router ID's" in protocols. Specifically, here's a real world example difference > between an IPv4 /32 and IPv6 /128 Loopback assigned to a live, production > box (slightly obsfucated to protect the innocent): >=20 > interface Loopback0 > ip address A.BB.CCC.16 255.255.255.255 > ipv6 address 2001:XXXX::Y:Z/128 >=20 > ... in reality, it's a difference of 3-digits. OTOH, if the IPv4 address was > assigned out of traditional IPv4 Class C space, (192/3), then the difference > would have been a single digit. (OK, yes, I'll concede that if someone is not > fortunate enough or properly planned ahead, then they could end up with a > substantially larger number of digits ... but, that's typically not the case given > the ease at which nearly anyone can get a PIv6 block today). >=20 >=20 > > Protocols like OSPF that decided that a 32 bit router ID was perfect for all > > address families got it absolutely right, IMO. The better organisations I > know > > make a point of making the router ID an impossible address, so that > regardless > > of context, it is immediately apparent whether a dotted decimal number is > a > > routable address or an ID. >=20 > The larger point I'm trying to bring attention to is that, shockingly, the world > really is moving toward IPv6. Yay! At some point in the future (certainly not > next year, maybe not in 3 - 5 years), we're all going to want to run IPv6-only > networks to reduce OpEx. So, the question I ask is: what then? > a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I can > transport IPv4 "Router ID's" around my network? Or, > b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the > purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the > operational reasons I outlined in my previous e-mail? (If so, then I think it's a > moot point if you're typing a IPv4-mapped IPv6 address or a Native IPv6 > address for a Router ID -- they're likely roughly of the same length). >=20 > Either approach seems a bit "kludgy" to me. Then again, I'm willing to be told > that I'm the one being the purist. Perhaps, (b) is "the answer" and I just > hadn't gotten the memo. :-) >=20 > Regardless, I'm suggesting that if we're looking at making a change to any > protocol to support IPv6, let's make sure we briefly, but carefully, look at > what the roadmap holds for the future and weigh the costs of making a > single change to LDP, now, to future-proof LDP (and, other protocols) for > IPv6, rather than make yet more changes down the road ... >=20 > Just my $0.02, >=20 > -shane >=20 >=20 > > Tom Petch > > > > > > > > > > > > > > > > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > > b) use traceroute and/or a routing table to learn the _topological_ location > of > > the /32 (4-octet) LSR-ID in the network ... > > > > In summary, there is a tremendous amount of operational value in the 4- > Byte > > LSR-ID actually be announced/routed in a network's IGP -- let us not > > underestimate that. All I'm saying is, let's not go out of our way to try to > > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely > theoretical > > reasons. > > > > -shane > > > > > >> Secondly, If there is a need to define new "LDP Identifier" in order to > > establish/maintain a separate session for IPv6 AF, this should be a protocol > > change - i.e. we should bump up LDP protocol version in LDP PDU header > for this, > > and possibly define new format for "LDP Identifier" in the context of new > LDP > > protocol version. > >> > >> My 2 cents. > >> > >> On 12-02-29 8:11 PM, "Vishwas Manral" wrote: > >> > >>> Hi Lizhong/ Pranjal/ Mustapha, > >>> > >>> So the two main comments that have come after last call are: > >>> > >>> 1. Allow for separation of sessions along with the adjacency. > >>> 2. Allow for an IPv6 based LSR-ID. > >>> > >>> The second could lead to changes required in both OSPF and IS-IS, as > well > > because the new LSR ID would then need to be exchanged. We could treat > it as an > > enhancement instead in my view. Do you agree? > >>> > >>> Thanks, > >>> Vishwas > >>> > >>> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > wrote: > >>>> Yes, I support that too. There would be network management issues > with > > mapping of 4 byte LSR-ID to an IPV6 remote address. > >>>> Most of the implementations I know off usually maps 4 byte of the LSR- > ID > > with a local ipv4 interface address in the system. > >>>> > >>>> Thanks, > >>>> Pranjal > >>>> > >>>> > >>>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > >>>> Sent: Wednesday, February 29, 2012 4:57 PM > >>>> To: Aissaoui, Mustapha (Mustapha) > >>>> Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > >>>> > >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>>> > >>>> > >>>> Hi Mustapha, > >>>> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed > > out in my first email. > >>>> > >>>> Thanks > >>>> Lizhong > >>>> > >>>> > >>>> "Aissaoui, Mustapha (Mustapha)" lucent.com> wrote > > 2012/03/01 04:35:41: > >>>> > >>>>> Hi Lizhong, > >>>>> I actually think that we would need to define a new one which will > >>>>> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions > in > >>>>> a all-IPv6 network will not be possible. I cannot see that operators > >>>>> will start maintaining a mapping of some global non routable LSR-id > >>>>> value to an IPv6 loopback interface on each router in the network. > >>>>> > >>>>> Mustapha. > >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of > >>>>> Aissaoui, Mustapha (Mustapha) > >>>>> Sent: Tuesday, February 07, 2012 10:12 AM > >>>>> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > >>>>> Cc: mpls@ietf.org > >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>>> > >>>>> Lizhong, > >>>>> the existing LSR-id will do the job and should be supported since > >>>>> the LSR-id need not be an IP address. Most implementations will > >>>>> actually populate the field with a /32 address in IPv4 and thus If > >>>>> necessary we could define a new format to allow the use of /128 > > IPv6addresses. > >>>>> > >>>>> Mustapha. > >>>>> > >>>>> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > >>>>> Sent: Monday, February 06, 2012 10:23 PM > >>>>> To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > >>>>> Mustapha (Mustapha) > >>>>> Cc: mpls@ietf.org > >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>>> > >>>>> > >>>>> Hi, > >>>>> I wonder if it is feasible to use LDP capability to advertise IPv6 > >>>>> FEC without IPv6 adjacency, and only use one adjacency for LDP > >>>>> session in dual-stack network. LDP capability is per node > >>>>> capability, not per interface capability. But for LDP to choose the > >>>>> correct downstream session and output interface for each FEC, it > >>>>> should also check if the output interface is LDP enabled or not. The > >>>>> link adjacency could be used to assist such kind of checking. > >>>>> > >>>>> However, IMO, it is valuable to allow two independent LDP sessions > >>>>> for IPv4 and IPv6 as an option. Regarding the format definition in > >>>>> RFC5036, we may need new LDP version number to identify IPv6 LSR- > ID. > >>>>> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > >>>>> new format of LSR-ID. > >>>>> > >>>>> Regards > >>>>> Lizhong > >>>>> > >>>>> > >>>>>> ---------------------------------------------------------------------- > >>>>>> > >>>>>> Message: 1 > >>>>>> Date: Tue, 7 Feb 2012 05:28:21 +0530 > >>>>>> From: "Dutta, Pranjal K (Pranjal)" lucent.com> > >>>>>> To: Vishwas Manral > >>>>>> Cc: "Aissaoui, Mustapha \(Mustapha\)" > >>>>>> , "mpls@ietf.org" > >>>>>> > >>>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >>>>>> Message-ID: > >>>>>> > >>>>>> alcatel-lucent.com > > >>>>>> > >>>>>> Content-Type: text/plain; charset=3D"us-ascii" > >>>>>> > >>>>>> I would rather for complete separation with multiple lsr-id because > >>>>>> having separate link adjacencies does not really solved any problem. > >>>>>> Since hello adjacencies are associated with a link, still fate > >>>>>> sharing would continue over the single ldp/tcp session for IPV4 and > > IPV6. > >>>>>> Having IPV4 and IPV6 specific hello adjacencies over a link would > >>>>>> only decide whether such a link is to be programmed for IPV4 or > IPV6 > >>>>>> egress traffic but I see it as overkill and unnecessary scalability > > impacts. > >>>>>> > >>>>>> Thanks, > >>>>>> Pranjal > >>>>>> > >>>>> -------------------------------------------------------- > >>>>> ZTE Information Security Notice: The information contained in this > >>>>> mail is solely property of the sender's organization. This mail > >>>>> communication is confidential. Recipients named above are obligated > >>>>> to maintain secrecy and are not permitted to disclose the contents > >>>>> of this communication to others. > >>>>> This email and any files transmitted with it are confidential and > >>>>> intended solely for the use of the individual or entity to whom they > >>>>> are addressed. If you have received this email in error please > >>>>> notify the originator of the message. Any views expressed in this > >>>>> message are those of the individual sender. > >>>>> This message has been scanned for viruses and Spam by ZTE Anti- > Spam > > system. > >>> > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> > >> -- > >> Syed Kamran Raza > >> Technical Leader, SPRSG IOS-XR Routing (MPLS) > >> Cisco Systems, Inc., > >> Kanata, ON, K2K 3E8, Canada > >> Ph: +1 (613) 254-4520 > >> http://www.cisco.com > >> > >> > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > ------------------------------------------------------------------------ -------- > > > > > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > >> > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mustapha.aissaoui@alcatel-lucent.com Thu Mar 1 22:09:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D873521F8A77 for ; Thu, 1 Mar 2012 22:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdoX1OXaB3xS for ; Thu, 1 Mar 2012 22:09:13 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 95F7721F8A7C for ; Thu, 1 Mar 2012 22:09:13 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2269Bmc008115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 00:09:11 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2269B98014919 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 00:09:11 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 2 Mar 2012 00:09:11 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" Date: Fri, 2 Mar 2012 00:09:09 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdAB0mgbIA== Message-ID: <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:09:16 -0000 Hi Rajiv, See some follow-up inline. Regards, Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Wednesday, February 29, 2012 10:28 PM To: Aissaoui, Mustapha (Mustapha); Shane Amante Cc: mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, Thanks for the review of the document and the feedback. It is never too lat= e. :) Sorry about the delay in getting back to you. Please see inline, > > below are comments on this draft. I realize this draft passed WG last call but I > think the issues are significant enough in my view. I apologize if some of these > comments were already raised on this mailing list. Yes, they were discussed in the past and closed. > > 1. Section 3 - LSP Mapping; second paragraph. > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring to a > loopback interface of the egress router, not any other interface. That is why > RFC 5036 explicitly states /32 for IPv4. In my view, we should explicitly refer to > /128 for IPv6. No. While it is a common practice to assign a host route to the loopback interf= ace, and it is a common practice to use loopback interface as the next-hop,= we must not assume the common practice to be the norm for the protocol. In= fact, there is NO technical argument against using the non-host route on a= loopback interface. In fact, almost every implementation allows the next-hop to be a non-host r= oute, and I am aware of at least one implementation that allows LDP to corr= ectly resolve the next-hop when it uses a non-host route. > > 2. Section 3 - LSP Mapping; last Paragraph: > > " > > Additionally, it is desirable that a packet is forwarded to an LSP of an egress > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches with that of > the LDP hello adjacency on the next-hop interface. > > " > > MA> RFC 5036 makes no tie, and there should not be, between the type of > resolved FEC and the adjacency to the next-hop. I think this statement should be > removed. RFC5036 actually does make a tie in section 2.5.5 in the sense that if hell= o adj ceases to exist on an interface, then LDP concludes the lack of MPLS = forwarding on that interface. So, if IPv6 hello adj failed, then stop the I= Pv6 MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of bl= indly stopping MPLS forwarding altogether. That wouldn't make sense. // when it receives a Hello that matches the adjacency. If the timer expires without receipt of a matching Hello from the peer, LDP concludes that the peer no longer wishes to label switch using that label space for that link (or target, in the case of Targeted Hellos) or that the peer has failed. The LSR then deletes the Hello // MA> Not really. The "matching" has nothing to do with the type of FEC. It h= as to do with the parameters of the adjacency (LSRid, label space) over tha= t link. > > 3. Section 4 - LDP identifiers; third paragraph: > > " > > This document qualifies the first sentence of last paragraph of > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > updates that sentence to the following: "For a given address family > > over which a Hello is sent, and a given label space, an LSR MUST > > advertise the same transport address." This rightly enables the per- > > platform label space to be shared between IPv4 and IPv6. > > " > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has anything > to do with the address family. It only requires that an LSR advertises the same > transport address in all Hello adjacencies that advertise the same label space. I agree. It doesn't have anything to do with the address family, but it bec= omes restrictive when having to accommodate transport of two different addr= ess families (IPv4 and IPv6). Pls see more details on this later on. > In fact the intent as explained in the second sentence of that same paragraph > was to make sure that if two LSRs are establishing multiple Hello adjacencies > that they play the same active/passive role for establishing the TCP connection. > > > > In practice though, most implementations allow Hello adjacencies over > parallel links with different IPv4 transport addresses and it works just fine. I > think we should remove this restriction from RFC 5036 and not refer to it in this > draft. That's not correct (and the implementation is in violation of RFC5036). We had good discussion on this early on. In fact, we had an editor's note o= n this in initial versions of this document to solicit discussion on that. The last para of section 2.5.2, as stated, would result in a particular IP = address (1.1.1.1, say) being encoded in the transport address in both IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared (which = is what the WG agreed to during IETF 80), then it prohibits IPv6 hello from= carrying IPv6 transport address (or IPv4 hello from carrying IPv4 transport address). It would not make sense. In other words, we wouldn't want IPv4 Hello to carry IPv6 transport address= and vice versa. It wouldn't make sense and would be incorrect. That's why the change was needed. MA> When parallel links exist between two LSRs, the TCP connection is boots= trapped by one of the hello adjacencies. An implementation compliant to RFC= 5036 will not accept two TCP connections between the same two LSRs and thu= s the fact that the transport addresses exchanged are different has no impa= ct. In fact take the simple case of a link LDP and a T-LDP sessions for dir= ectly connected LSRs. The T-LDP can use a loopback address as the transport= address while the link LDP can use the link address as the transport addre= ss and they will both share the same TCP connection which was bootstrapped = first. It becomes an issue of association of multiple Hello adjacencies wit= h a single TCP connection. That is why I am saying the last paragraph of se= ction 2.5.2 should be removed from RFC 5036. > > 4. Section 5.1 - Basic Discovery mechanism > > MA> I understand the need to send both IPv4 and IPv6 Hello messages over a > dual-stack interface since there could be both IPv4 and IPv6 LSRs on the same > subnet. However, this does not justify the need to maintain two separate Hello > ajacencies per peer. In practice, each router can send both IPv4 and IPv6 hellos > but only a single Hello adjacency must be allowed with each peer (LSR-id, label- > space} over a given interface, whichever came up first. Over a P2P interface, it > is up to the user to configure which adjacency they want to form which means > there is only a need to send one type of hello. We thought so too, but we uncovered various corner cases in which this beco= mes problematic, not to mention that the indeterminism it would bring into = the picture. The easiest was to maintain hello adj per address-family per p= eer. For ex, consider three LDP enabled interfaces between R1 and R2, where two = are dual-stack, whereas the 3rd is single-stack (v4). If they maintain only= single adj, then they would have hello adj of one transport (v6, say) on d= ual-stack interfaces, and another transport (v4, say) on 3rd interface. Hello adj is tightly coupled with the functional LDP peering. If (the last) hello adj is lost, then LDP peering must be brought down. Additionally, if hello adj is gone from an interface, then LDP should prohi= bit MPLS forwarding from using that interface. Another way to think about it is - if IPv4 stops functioning on an interfac= e, but IPv6 keeps functioning, then IPv6 MPLS forwarding should not be pena= lized. And vice versa. Having separate hello adj maintenance is much cleaner/simpler and provides = deterministic behavior. Nonetheless, an implementation could choose to optimize, if needed, to keep= both address-family related info in a single adjacency structure, but this= is all implementation specific. :) MA> The proper way to handle this is to implement separate LDP sessions not= separate Hello adjacencies sharing the same LDP session. Current standard = LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be exchanges and they = do not require separate hello adjacencies. These are just FEC types and hav= e no relationship whatsoever to the type of adjacency. > > 5. Section 6.1 - Transport connection establishment " > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > and IPv6 transport address optional objects, but MUST use only > > the transport address whose address family is the same as that > > of the IP packet carrying Hello. > > " > > MA> This is not a new issue. If I am not mistaken, this can also occur in RFC > 5036 implementations if an LSR receives two optional IPv4 transport address > TLVs. RFC 506 does not say what to do with this and was left for > implementations to handle. If we absolutely need to specify something, maybe > we should say only the first TLV in the Hello message is processed. Good point, but this is a different problem. It is not about the sequence (= which was ok if IPv4 hellow as carrying two IPv4 transport addresses). The problem is that allowing IPv4 based "discovery" to suggest an IPv6 tran= sport address is fundamentally a wrong approach, IMO. How would IPv4 know t= hat IPv6 transport is even functional (and vice versa). IPv4 based discove= ry should suggest IPv4 transport, and IPv6 based discovery should suggest I= Pv6 transport. MA> Again, what you are asking for can be solved with the use of separate L= DP sessions for IPv4 and IPv6. This is a deployment choice and not a protoc= ol design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 co= nnection and vice-versa. There is no relationship whatsoever between the ty= pe of TCP conneciton in BGP and the NRLI family exchanged. > > 6. Section 6.1 - Transport connection establishment " > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > hello adjacencies for the same LDP Identifier (over a dual- > > stack interface, or two or more single-stack IPv4 and IPv6 > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if they attempted two TCP > > connections using IPv4 and IPv6 transport addresses > > simultaneously. > > " > > MA> No need for all this if you enforce that only a single adjacency is > maintained to each peer over a dual-stack interface. We need the address-family awareness in peer hello adjacency/s, whether it = is a kept in a single adj structure or not. Loosing the AFI awareness leads up the other problems that I mentioned earl= ier. > > 7. Section 7 - Label Distribution; First paragraph: > > " > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > well as interface addresses via ADDRESS message) from/to the peer > > over an LDP session (using whatever transport), unless it has valid > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > section 6.2. > > " > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings should > depend on the existence of an IPv6 Hello adjacency. This is a very narrow > interpretation of RFC 5036. > > The proper solution to this is to add an IPV6 LDP capability to negotiate which > FEC address family can be exchanged regardless if the Hello adjacency is IPv4 > or IPv6. This is already done for multicast LDP (mLDP) FECs. It is MAY. :) It was changed to MAY based on the exhaustive discussion on mailing list in= 2011 for us to move forward. MA> Bottom line, you are changing the behaviour of RFC 5036. This is a diff= erent protocol. > > 8. Section 7 - Label Distribution; Fourth paragraph: > > " > > Additionally, to ensure backward compatibility (and interoperability > > with IPv4-only LDP implementations), this document specifies that > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > containing FEC Elements of different address-family. In other words, a FEC TLV > in the label mapping message MUST contain the FEC Elements belonging to the > same address-family. > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > message) with an Address List TLV containing IP addresses of different address- > family. In other words, an Address List TLV in the Address (or Address > Withdraw) message MUST contain the addresses belonging to the same > address-family.. > > " > > MA> This is yet another narrow interpretation of RFC 5036. There is no > justification for such a restriction and certainly RFC 5036 does not make it. A > FEC TLV contains list of FEC Elements which are opaque. Each FEC Element has > its own Type, Length, Value and is self sufficient. Although implementations > don't mix and match FEC elements but they are designed to handle it. Same > applies to Address list TLV. We initially thought so too, until we discovered the following very explici= tly in RFC5036. This is a recipe for a disaster, if left untreated. // Section 3.5.5.1 - If an LSR does not support the Address Family specified in the Address List= TLV, it SHOULD send an Unsupported Address Family Notification to its LDP = signaling an error and abort processing the message. Section 3.4.1.1 - If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Fa= mily it does not support, it SHOULD stop decoding the FEC TLV, abort proces= sing the message containing the TLV, and send an "Unsupported Address Famil= y" Notification message to its LDP peer signaling an error. // MA> Well all this is controlled via the LDP capability or configuring the F= EC filters. If after this, the node still receives the unsupported FEC or a= ddress type, what else do you suggest it should do? > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > MA> I believe the need to handle duplicate interface addresses received from > two different peers is not a new issue. It needed to be handled in existing IPv4 > based LDP implementations. Maybe the authors can specify why duplicate link > local addresses is any different. Because it is native in IPv6 to allow for link-local addresses that IPv4 ne= ver allowed. So, what was an anomaly with IPv4 is now a standard behavior with IPv6, hen= ce, that verbiage. > > 10. Section 9 - LDP TTL Security > > " > > This document also specifies that the LDP/TCP transport connection > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > session peering established between the adjacent LSRs using Basic > > Discovery, by default. > > " > > MA> GTSM must be optional as explained in RFC 5082. This draft is not > defining a new protocol and as such it should remain optional as in RFC 5036. We posed the Q about GTSM being the default or not during IETF 80, and ther= e were 10-yes and 0-no (mostly from operators) Pls see the minutes, http://= www.ietf.org/proceedings/80/minutes/mpls.txt MA> Well that certainly contradicts the process. If you are creating a new = LDP version protocol, we can consider making it mandatory by default. If yo= u claim you are still compliant to RFC 5036 then you cannot change it and i= t must remain optional. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Monday, February 06, 2012 3:21 PM > To: Shane Amante > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Shane, > LDP as defined in RFC 5036 can carry multiple FEC types within an LDP session > from a peer which is identified by the LDP identifier tuple {LSR-id, label-space- > id}. If two LSR nodes using the same LSR-id want to advertise two different label > spaces, then they must use two different Hello adjacencies and LDP sessions for > that. Also, if an implementation supports virtualization of LDP, then a different > LDP identifier altogether can be used to establish a separate LDP session. Other > than that, there is no relation between the type of adjacency and the FEC which > are carried. For example, the same LDP Hello Adjacency and LDP session are > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between two > directly connected peers. > > As far as I know BGP is not very different. It offers the ability to carry IPv4 NLRI > over a IPv6 session and vice versa. > > If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 on an IPv4 > session between two LSRs, then we should consider extending RFC 5036 to > allow for two different LSR-id values sharing the same global label space. This > way, we can have separate Hello adjacency and LDP session and it is up to the > user to assign which FEC type is allowed on which LDP session. This is a new > work item but in my view much cleaner and backward compatible with RFC > 5036 than to try to tie the address family to the type of Hello adjacency. > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate Hello > adjacency but a single shared LDP session. It is not exactly what you are asking > for. > > Regards, > Mustapha. > > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Friday, February 03, 2012 11:32 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Mustapha, > > I am not an author, but I do want to provide some operational input on some of > your comments. Specifically, I get the sense from several of your comments -- > actually, moreso from #3 -- that you are opposed to maintaining separate LDP > Hello and/or Session Adjacencies: 1 for each address family. (If my impression > is incorrect I apologize). > > I actually *do* want to have separate LDP Hello and Session adjacencies: one > per address family, at least at this point in time. I'm concerned about > [operational] issues that may develop in, for example, v6 affecting the > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one more > concrete example, 6man/v6ops are only right now working on improving the > robustness of IPv6 ND to DoS attacks. There are potentially other areas where > IPv6 will be hardened, as well. The bottom-line is I do not want problems in v6 > to affect exchange of FEC's + labels for v4, or vice-versa. Also, FWIW, there has > already been a precedent here wrt BGP where there it maintains separate > neighbors/sessions for each address family, so why aren't we doing the same > thing for LDP? > > Ultimately, having separate sessions over-the-wire is much more intuitive to > operators in lots of cases where they may expect that a configuration change > or bugs they /think/ are only going to affect one address family, really do only > affect one address family. Besides, LDP Hello & Sessions timers, when set to > default, are extremely relaxed (order of several seconds), so the burden on > implementations to maintain separate sessions should be miniscule. > > IMO, I would prefer that the default be separate Hellos & Sessions over the > wire to avoid "fate sharing". Only when an operator chooses to explicitly > configure their device to have hellos and sessions share fate should the device > do so. > > Just my $0.02, > > -shane > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > Dear authors, > > below are comments on this draft. I realize this draft passed WG last call but I > think the issues are significant enough in my view. I apologize if some of these > comments were already raised on this mailing list. > > > > Regards, > > Mustapha. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1. Section 3 - LSP Mapping; second paragraph. > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring to a > loopback interface of the egress router, not any other interface. That is why > RFC 5036 explicitly states /32 for IPv4. In my view, we should explicitly refer to > /128 for IPv6. > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > " > > Additionally, it is desirable that a packet is forwarded to an LSP of an egress > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches with that of > the LDP hello adjacency on the next-hop interface. > > " > > MA> RFC 5036 makes no tie, and there should not be, between the type of > resolved FEC and the adjacency to the next-hop. I think this statement should be > removed. > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > " > > This document qualifies the first sentence of last paragraph of > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > updates that sentence to the following: "For a given address family > > over which a Hello is sent, and a given label space, an LSR MUST > > advertise the same transport address." This rightly enables the per- > > platform label space to be shared between IPv4 and IPv6. > > " > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has anything > to do with the address family. It only requires that an LSR advertises the same > transport address in all Hello adjacencies that advertise the same label space. > In fact the intent as explained in the second sentence of that same paragraph > was to make sure that if two LSRs are establishing multiple Hello adjacencies > that they play the same active/passive role for establishing the TCP connection. > > > > In practice though, most implementations allow Hello adjacencies over > parallel links with different IPv4 transport addresses and it works just fine. I > think we should remove this restriction from RFC 5036 and not refer to it in this > draft. > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > MA> I understand the need to send both IPv4 and IPv6 Hello messages over a > dual-stack interface since there could be both IPv4 and IPv6 LSRs on the same > subnet. However, this does not justify the need to maintain two separate Hello > ajacencies per peer. In practice, each router can send both IPv4 and IPv6 hellos > but only a single Hello adjacency must be allowed with each peer (LSR-id, label- > space} over a given interface, whichever came up first. Over a P2P interface, it > is up to the user to configure which adjacency they want to form which means > there is only a need to send one type of hello. > > > > > > 5. Section 6.1 - Transport connection establishment " > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > and IPv6 transport address optional objects, but MUST use only > > the transport address whose address family is the same as that > > of the IP packet carrying Hello. > > " > > MA> This is not a new issue. If I am not mistaken, this can also occur in RFC > 5036 implementations if an LSR receives two optional IPv4 transport address > TLVs. RFC 506 does not say what to do with this and was left for > implementations to handle. If we absolutely need to specify something, maybe > we should say only the first TLV in the Hello message is processed. > > > > > > 6. Section 6.1 - Transport connection establishment " > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > hello adjacencies for the same LDP Identifier (over a dual- > > stack interface, or two or more single-stack IPv4 and IPv6 > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > LDP session with a remote LSR, if they attempted two TCP > > connections using IPv4 and IPv6 transport addresses > > simultaneously. > > " > > MA> No need for all this if you enforce that only a single adjacency is > maintained to each peer over a dual-stack interface. > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > " > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > well as interface addresses via ADDRESS message) from/to the peer > > over an LDP session (using whatever transport), unless it has valid > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > section 6.2. > > " > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings should > depend on the existence of an IPv6 Hello adjacency. This is a very narrow > interpretation of RFC 5036. > > The proper solution to this is to add an IPV6 LDP capability to negotiate which > FEC address family can be exchanged regardless if the Hello adjacency is IPv4 > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > " > > Additionally, to ensure backward compatibility (and interoperability > > with IPv4-only LDP implementations), this document specifies that > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > containing FEC Elements of different address-family. In other words, a FEC TLV > in the label mapping message MUST contain the FEC Elements belonging to the > same address-family. > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > message) with an Address List TLV containing IP addresses of different address- > family. In other words, an Address List TLV in the Address (or Address > Withdraw) message MUST contain the addresses belonging to the same > address-family.. > > " > > MA> This is yet another narrow interpretation of RFC 5036. There is no > justification for such a restriction and certainly RFC 5036 does not make it. A > FEC TLV contains list of FEC Elements which are opaque. Each FEC Element has > its own Type, Length, Value and is self sufficient. Although implementations > don't mix and match FEC elements but they are designed to handle it. Same > applies to Address list TLV. > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > MA> I believe the need to handle duplicate interface addresses received from > two different peers is not a new issue. It needed to be handled in existing IPv4 > based LDP implementations. Maybe the authors can specify why duplicate link > local addresses is any different. > > > > > > 10. Section 9 - LDP TTL Security > > " > > This document also specifies that the LDP/TCP transport connection > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > session peering established between the adjacent LSRs using Basic > > Discovery, by default. > > " > > MA> GTSM must be optional as explained in RFC 5082. This draft is not > defining a new protocol and as such it should remain optional as in RFC 5036. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mtinka@globaltransit.net Thu Mar 1 22:31:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F621F8B49 for ; Thu, 1 Mar 2012 22:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipcDW1T24CRT for ; Thu, 1 Mar 2012 22:31:25 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id AD08F21F8B45 for ; Thu, 1 Mar 2012 22:31:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3M1P-0003hN-Ni; Fri, 02 Mar 2012 14:31:19 +0800 From: Mark Tinka Organization: Global Transit International To: "Rajiv Asati (rajiva)" Date: Fri, 2 Mar 2012 14:31:16 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203021109.05568.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3830896.gdIq7yp1LH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021431.19153.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:31:25 -0000 --nextPart3830896.gdIq7yp1LH Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva)=20 wrote: > In the past, implementations provided the router-id CLI > for any interface IPv4 address to be chosen as router-id > for various protocols including LDP. > However, many implementations already evolved the CLI to > not even give an "interface" IP address for router-id, > to accommodate IPv6. Almost all deployed networks > already accommodated that. We do operate some implementations today that "still" allow=20 you to specify the Router-ID for various protocols as an=20 independent 32-bit integer (only), and also allow you to=20 define the LSR-ID for LDP as an interface (only). This is=20 current, shipping 2012 code. So both scenarios you mention above are still much in play=20 today. Whether operators are using them or not (I know we=20 are) is another matter entirely. > Now that LDP is being enhanced to use IPv6, > implementations could evolve LDP router-id as well to > accommodate IPv6. This would make LDP router-id to be > consistent with other protocols delving with IPv6. And > this can certainly be operationally beneficial from IPv6 > POV. Agree. > In fact, one of the implementations allow the router-id > to be configured just once and let all protocols just > use it, if they wanted. Yes, we operate some implementations that use this method=20 too. It's quite elegant, in that you configure once and=20 forget. Other implementations that are more structured means=20 operators could easily forget to specify the Router-ID for a=20 particular protocol, for better or worse. Cheers, Mark. --nextPart3830896.gdIq7yp1LH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUGk3AAoJEGcZuYTeKm+G1qAP/iFN+930iufbSHinHl0l9MJB /fCWIS+oYYQzgp1fevzEL0lcbtMimcaSpid9Frx42jp3SN8mLd/I0b/dqEegjJp5 cfSHU1nMrtzoS1Zan8KCJu0q2q1vNPuW/RcTgnhowEPumR9MWJXhLWA/kvtOhOHr aVX+m5+/NdBKZDtlL3UDClDlYRRWq+u2UowEdy4t4XiEnZTRU4Odu5Q3XDBPTb+/ s5eWtOLelCz1SSwlGWOvIKx0l5XMmxCjVSL9/bhG27g+XraQd3FahAqtDgbj549M R8bdYp0ri5JdbO74DlL0+98CxiBtnc8X9Xu95LdKt4jqFgnW3rXbkmSNUQYy/5T1 N68szkOO2ukTERaIJF0OWO+Tf4ZHbtQAaj+pxjm/NXAaDoZRbx9CayKE8TQjkfsu 0VqIBm2G6YZkPdjvk9Rj9U6LCN5A+CCZYBUFzz3m8HNBrYYIgVXfgUN16UouNWVw XQ1mRxGjPGBczijjugEmoo8zIDA3IkvdwvPsoL5bSERP2Wu6/wQswMlnM5OcLusy AMlhqDvIuAL9L+PeBSDiQelAAyj0038XQZKAwSb7xE4iPSHzj8LbZlVfUO+gXJzK qDU7HnXyHUvAVLyi1xvpq+9150pwtgcLdUd+nolXnDMszPFkGg4yWH7bbcndN0bm fvYly9aFrezwmGarr2kV =v6+N -----END PGP SIGNATURE----- --nextPart3830896.gdIq7yp1LH-- From mtinka@globaltransit.net Thu Mar 1 22:35:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179D021E8020 for ; Thu, 1 Mar 2012 22:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve3k8fUR1A-a for ; Thu, 1 Mar 2012 22:35:27 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA221F8B7A for ; Thu, 1 Mar 2012 22:35:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3M5J-0003i5-58; Fri, 02 Mar 2012 14:35:21 +0800 From: Mark Tinka Organization: Global Transit International To: "Rajiv Asati (rajiva)" Date: Fri, 2 Mar 2012 14:35:20 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <64E677AD-6ED5-488C-8FA3-90F81D411D04@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C078BE5D1@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE5D1@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1448811.cLvLUy1tzn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021435.20629.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:35:28 -0000 --nextPart1448811.cLvLUy1tzn Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 11:47:39 AM Rajiv Asati (rajiva)=20 wrote: > IPv4 and IPv6 info should be kept separate (my preference > as well as I alluded to it in my previous email), but we > can't mandate the implementation specifics in the RFC. > Would you disagree? I'm okay not to necessarily define the detailed specifics=20 inside the RFC, provided we don't sacrifice inter-vendor=20 operability. =46or specifics, vendors can detail their implementations in=20 their manuals for operators to feed on, but only as long as=20 operators can inter-operate a particular method (integrated=20 or separate AF's) without issue. Mark. --nextPart1448811.cLvLUy1tzn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUGooAAoJEGcZuYTeKm+GFRgP/jmh4E0aX4q3xi786cH4hQmQ 7Cfa4aRfHqRQ7o/mNtpIbeMJwJ8h8j/DoLmsfg8yBjjJq0rGPdWB4q+jq0EeQcZK BywXAgM3oNirfJkt0ZE1Ze66VJib+iPYGvfoeevNewR8ZvIpm5pkcB5xBWIligD7 7SUMbTpP88Boy6GtoxbJ3r5Vk+ImO4m1cOGAoVRxRRmcc7a8p5OYXiUS+zMx9ufv pM4sutZcmdhz4TA0ClVN1wuzHTOJTBOnphBvfUZw0GDSVZwjWZSlwJTVd20lMqju lp9oyfqCS2lEml4plSFOXXzHcvKkK8C/wq1/lyFCI/nHe+5jKjaY2ayn6ucXXPuH FEw4WVm4W8wst5S56mVyvzY1ulvDq2ZLGl2QGt8+fySK7lNAnI9TYAwrH58dYxty 8MrcaIbvG2/EyNg4qBUDBT5cgD1O3Fa6c7fpRztLSjOWusf24e0myiBMO9H5ftQ5 rOCtKDMHdAjWOuhONj5XPECtrO3/ITesp34CnNNLbRXpbVJBkCeAJiLSEJqlQdmD 0EnKMFocqdTVKWHnyiAhCI1PBCeo5JDbYIODRJm/1j6mSea8wfMqRiEBQuf6tMfW KasJOrrTixTmjl0V2NHYTuRJk8jpb62cSlBYDOEt3QZh0MKInspStSh/MlxtLHuW uAY6sPxjx+u1H4OpVGKP =7kXC -----END PGP SIGNATURE----- --nextPart1448811.cLvLUy1tzn-- From rajiva@cisco.com Thu Mar 1 22:38:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBD021E80D4 for ; Thu, 1 Mar 2012 22:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.629 X-Spam-Level: X-Spam-Status: No, score=-9.629 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiqOpsffUdDf for ; Thu, 1 Mar 2012 22:38:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6399F21E80A3 for ; Thu, 1 Mar 2012 22:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2199; q=dns/txt; s=iport; t=1330670330; x=1331879930; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sM+WCUbQRDOUJKQWICEv7Aoc5Xn388r6QLdyb+DzGjo=; b=mbpGoRSUiTMax7LLTjUnVp8mFkcfJe25mqZ2o00FRwgajQWLtG3V5aKV 0Yg4geHf5KRt7WY+aPkT58z7iR1caUYUNX5c4+Mmp3HEBr6Js/s+w+x80 15YJEd/W/Evp4c6BWVGwJmHOVrtNl60dWBZYlUoZXX3aD3kIHVqeBNnqa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALFqUE+tJV2Y/2dsb2JhbABDtB6BB4F9AQEBBBIBHQo/DAQCAQgRBAEBAQoGFwEGASAlCQgBAQQTCBqHZJs5AZ5hiRuDGgMQCxACPRgJAoVEChUXAQ+CP2MEiE+YB4d2 X-IronPort-AV: E=Sophos;i="4.73,516,1325462400"; d="scan'208";a="63237170" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 02 Mar 2012 06:38:50 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q226cnsd030555; Fri, 2 Mar 2012 06:38:49 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 00:38:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 00:38:42 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> In-Reply-To: <201203021431.19153.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAw References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203021109.05568.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com> <201203021431.19153.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 02 Mar 2012 06:38:49.0952 (UTC) FILETIME=[208B2600:01CCF83F] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:38:51 -0000 Hi Mark, Well said.=20 I take that we are in agreement wrt 4-octet entity for LDP router-id in the context of IPv6, as specified. =20 Cheers, Rajiv > -----Original Message----- > From: Mark Tinka [mailto:mtinka@globaltransit.net] > Sent: Friday, March 02, 2012 1:31 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); lizhong.jin@zte.com.cn; > vishwas.ietf@gmail.com > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > wrote: >=20 > > In the past, implementations provided the router-id CLI > > for any interface IPv4 address to be chosen as router-id > > for various protocols including LDP. >=20 > > However, many implementations already evolved the CLI to > > not even give an "interface" IP address for router-id, > > to accommodate IPv6. Almost all deployed networks > > already accommodated that. >=20 > We do operate some implementations today that "still" allow > you to specify the Router-ID for various protocols as an > independent 32-bit integer (only), and also allow you to > define the LSR-ID for LDP as an interface (only). This is > current, shipping 2012 code. >=20 > So both scenarios you mention above are still much in play > today. Whether operators are using them or not (I know we > are) is another matter entirely. >=20 > > Now that LDP is being enhanced to use IPv6, > > implementations could evolve LDP router-id as well to > > accommodate IPv6. This would make LDP router-id to be > > consistent with other protocols delving with IPv6. And > > this can certainly be operationally beneficial from IPv6 > > POV. >=20 > Agree. >=20 > > In fact, one of the implementations allow the router-id > > to be configured just once and let all protocols just > > use it, if they wanted. >=20 > Yes, we operate some implementations that use this method > too. It's quite elegant, in that you configure once and > forget. Other implementations that are more structured means > operators could easily forget to specify the Router-ID for a > particular protocol, for better or worse. >=20 > Cheers, >=20 > Mark. From rajiva@cisco.com Thu Mar 1 22:39:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0432B21F890D for ; Thu, 1 Mar 2012 22:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.657 X-Spam-Level: X-Spam-Status: No, score=-9.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smjHUx51-PkF for ; Thu, 1 Mar 2012 22:39:35 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2B21F8909 for ; Thu, 1 Mar 2012 22:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1057; q=dns/txt; s=iport; t=1330670375; x=1331879975; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zg/EziBVJvrYun7UHnJKYW0WAiS8wprctyPZKfiVznw=; b=HDo+iK+16483ic3l0Jxk5jVgcnIl2tWr/akesHNTmL4BrDYlzNiYc5Qe wqRZaszqLR2kAgiNXNNozfk0WpLPVfidZsormWEK3+4Kl4xXj4yWjAtM5 PxYX3p4/mksZ15PI9FehFV7S5CksSOy9I0keZlTdvrru+VtlQL15s/Qx+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALFqUE+tJV2b/2dsb2JhbABDtB6BB4F9AQEBBBIBHQo/DAQCAQgRBAEBAQoGFwEGAUUJCAEBBBMIGodkmzkBnmGMVA8CPRgGAwKFRAosEII/YwSIT599gT0 X-IronPort-AV: E=Sophos;i="4.73,516,1325462400"; d="scan'208";a="63234660" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 02 Mar 2012 06:39:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q226dYCa024531; Fri, 2 Mar 2012 06:39:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 00:39:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 00:39:33 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE61A@XMB-RCD-111.cisco.com> In-Reply-To: <201203021435.20629.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Pqc4qs4IGqX5SAiGKIGTgy3r5QAAHaxA References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <64E677AD-6ED5-488C-8FA3-90F81D411D04@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C078BE5D1@XMB-RCD-111.cisco.com> <201203021435.20629.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: X-OriginalArrivalTime: 02 Mar 2012 06:39:34.0826 (UTC) FILETIME=[3B4A60A0:01CCF83F] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:39:36 -0000 Mark, Indeed. We are in agreement on this. Thanks for your feedback. Cheers, Rajiv > -----Original Message----- > From: Mark Tinka [mailto:mtinka@globaltransit.net] > Sent: Friday, March 02, 2012 1:35 AM > To: Rajiv Asati (rajiva) > Cc: Shane Amante; mpls@ietf.org; Aissaoui, Mustapha (Mustapha) > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Friday, March 02, 2012 11:47:39 AM Rajiv Asati (rajiva) > wrote: >=20 > > IPv4 and IPv6 info should be kept separate (my preference > > as well as I alluded to it in my previous email), but we > > can't mandate the implementation specifics in the RFC. > > Would you disagree? >=20 > I'm okay not to necessarily define the detailed specifics > inside the RFC, provided we don't sacrifice inter-vendor > operability. >=20 > For specifics, vendors can detail their implementations in > their manuals for operators to feed on, but only as long as > operators can inter-operate a particular method (integrated > or separate AF's) without issue. >=20 > Mark. From wim.henderickx@alcatel-lucent.com Thu Mar 1 22:42:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3C021E8106 for ; Thu, 1 Mar 2012 22:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.189 X-Spam-Level: X-Spam-Status: No, score=-9.189 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cnhntLKLyqo for ; Thu, 1 Mar 2012 22:42:20 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6723C21E8103 for ; Thu, 1 Mar 2012 22:42:20 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q226g49r010329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 07:42:05 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 2 Mar 2012 07:42:04 +0100 From: "Henderickx, Wim (Wim)" To: "Rajiv Asati (rajiva)" , "mtinka@globaltransit.net" Date: Fri, 2 Mar 2012 07:42:03 +0100 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203021109.05568.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com> <201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:42:21 -0000 Rajiv, I believe we need to provide both options to ensure both are possibl= e. If we do not introduce the IPv6 LSR ID now I will be very hard to ad it = in the future. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: vrijdag 2 maart 2012 7:39 To: mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mark, Well said.=20 I take that we are in agreement wrt 4-octet entity for LDP router-id in the context of IPv6, as specified. =20 Cheers, Rajiv > -----Original Message----- > From: Mark Tinka [mailto:mtinka@globaltransit.net] > Sent: Friday, March 02, 2012 1:31 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); lizhong.jin@zte.com.cn; > vishwas.ietf@gmail.com > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > wrote: >=20 > > In the past, implementations provided the router-id CLI > > for any interface IPv4 address to be chosen as router-id > > for various protocols including LDP. >=20 > > However, many implementations already evolved the CLI to > > not even give an "interface" IP address for router-id, > > to accommodate IPv6. Almost all deployed networks > > already accommodated that. >=20 > We do operate some implementations today that "still" allow > you to specify the Router-ID for various protocols as an > independent 32-bit integer (only), and also allow you to > define the LSR-ID for LDP as an interface (only). This is > current, shipping 2012 code. >=20 > So both scenarios you mention above are still much in play > today. Whether operators are using them or not (I know we > are) is another matter entirely. >=20 > > Now that LDP is being enhanced to use IPv6, > > implementations could evolve LDP router-id as well to > > accommodate IPv6. This would make LDP router-id to be > > consistent with other protocols delving with IPv6. And > > this can certainly be operationally beneficial from IPv6 > > POV. >=20 > Agree. >=20 > > In fact, one of the implementations allow the router-id > > to be configured just once and let all protocols just > > use it, if they wanted. >=20 > Yes, we operate some implementations that use this method > too. It's quite elegant, in that you configure once and > forget. Other implementations that are more structured means > operators could easily forget to specify the Router-ID for a > particular protocol, for better or worse. >=20 > Cheers, >=20 > Mark. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From shane@castlepoint.net Thu Mar 1 23:02:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE4321F8A37 for ; Thu, 1 Mar 2012 23:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lguXXW65lsyg for ; Thu, 1 Mar 2012 23:02:24 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4690721F8A36 for ; Thu, 1 Mar 2012 23:02:24 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id EDBC526806D; Fri, 2 Mar 2012 00:02:23 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 02 Mar 2012 00:02:23 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=61202; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE609@XMB-RCD-111.cisco.com> Date: Fri, 2 Mar 2012 00:02:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2D026530-B8AD-4E40-BC45-0842388C8FFA@castlepoint.net> References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> <7F2A789A-D8C6-47C6-9B09-85038B949E67@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C078BE609@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:02:25 -0000 Rajiv, On Mar 1, 2012, at 11:02 PM, Rajiv Asati (rajiva) wrote: > Hi Shane, >=20 > Thankfully, neither approaches are embraced/recommended/considered. >=20 >> a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I > can >> transport IPv4 "Router ID's" around my network? Or, >=20 > No.=20 >=20 > Router-ID is no longer a routable entity in IPv6 networks. Please = refer > to BGP (RFC6286) & OSPF (RFC5340). > In fact, OSPF (RFC5340) explicitly prohibits Router ID to be any IPv6 > address. >=20 > BGP RFC6286 > // > The BGP Identifier is a 4-octet, unsigned, non-zero integer that > should be unique within an AS. The value of the BGP Identifier > // >=20 >=20 > OSPF RFC5340 > // > o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the > IPv4 size of 32 bits. They can no longer be assigned as (IPv6) > addresses. > // Yes, I heard you before. Thanks, got that. So, please tell me how I'm supposed to ping/traceroute to this 32-bit = "Router ID" in this new IPv6-only world, just like I do today in IPv4 = today, to verify reachability? Usually, this is one of the first steps = in troubleshooting a problem. I'm curious if we've gotten lazy by = assuming dual-stack v4 + v6 will "always be there", so I can just use v4 = to ping/traceroute to a 32-bit Router ID ... but, what happens when v4 = is no longer there any more? >> b) Will we have to settle for IPv4-mapped IPv6 addresses, just for = the >> purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the >> operational reasons I outlined in my previous e-mail? >=20 > No. >=20 > It wouldn't make any sense, nor would it help.=20 > v4-mapped v6 address is still a v6 address, after all and it wouldn't = do > any good for 32-bit router-id. FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically, a = protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire; = however, "out-of-band" I assign a IPv4-mapped IPv6 address to a Loopback = interface on a router and inject it into my "IPv6-only" IGP in order to = preserve my ability to see it in the topology (in the routing table), = and simultaneously am able to ping/traceroute to it to ensure that the = Loopback interface is "alive". But, this is a kludge, because now I = have to keep the ROUTER_ID in sync with the configuration of IPv4-mapped = IPv6 address on a Loopback interface ...=20 -shane= From mtinka@globaltransit.net Thu Mar 1 23:03:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C493321F8A4F for ; Thu, 1 Mar 2012 23:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7hw0SBowJwj for ; Thu, 1 Mar 2012 23:03:48 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0E21F8A47 for ; Thu, 1 Mar 2012 23:03:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3MWg-0003uX-Am; Fri, 02 Mar 2012 15:03:38 +0800 From: Mark Tinka Organization: Global Transit International To: "Rajiv Asati (rajiva)" Date: Fri, 2 Mar 2012 15:03:34 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2826351.hlTzg5fqbF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021503.37730.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:03:48 -0000 --nextPart2826351.hlTzg5fqbF Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 02:38:42 PM Rajiv Asati (rajiva)=20 wrote: > Hi Mark, Hello Rajiv. > I take that we are in agreement wrt 4-octet entity for > LDP router-id in the context of IPv6, as specified. Well, to be specific, I'm not opposed to having a 32-bit=20 integer only, as it would be on par with what we're doing=20 with BGP (as well as for other operators who are maintaining=20 OSPFv3 implementations). But if others feel we need to provide both options,=20 particularly for LDP, I wouldn't argue with them either. If both options are included in the spec., I'm not sure=20 whether the IETF or the vendors should decide which one be=20 the default. Mark. --nextPart2826351.hlTzg5fqbF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUHDJAAoJEGcZuYTeKm+Gy5IP/3PiJFJJi7jrOqerhyMMqTsu LUz9PQw2U7CMX+Z8PD5a8eBXPPyywLkjpkDDCzx9DH0b3qROLrayFCRPPUMwnW2t N/VGne/o4yEvovsqT6t7U2YTDqqJAl6znatvquxnGK5bUP9tj9qyKuM6jDgPUx3S PZUI6psLj5plWeafVJRSJGBbHF3WAK+wAWTyEXi5WrQ5eoPU6TS98jP7wg7h/TlH u47Q4+o8Pm0WH/nhsPTDni1yklXgxotoBWcf4WJBBOqRRVOjG+RllbwW//bf73XS 1toKZjZ6T8zppQ51iq90IJHebYMpatyjHF9FrUA2TApiUoJEiv9sONOZ7aswYTCh uQU9PDmj1zf9OBNMMCLguB8stpITZ0Za9m9ZxHZKcVECrDmdObHVj+rJZO7+o+d/ ujuukm3TWMn+iTzHTzigLP9wJ91yMBq/NVXV4RlKJ2xzQDLEIfkVLtKuVwCtaKeP uQipf1DRITX1QmrjdMOcjZZPUDwmkKMoC7tjI2yKnT8mNWjZyuJkfBAVXAWLdVL0 ED/SFhCeVEIb4O8zjmH191Ec3UIK3uKsU/4RHxfkUqIqdIqfduEbQJ7OtT2hKXUS u8C5SIuLtMxhXOT5nREcO/M+fKg7s4LiJcxMQiHr4r3/QiEgjM3d+kwAGNZKPvdj Z3Tav+LIwpziVnuDEU5B =/O7R -----END PGP SIGNATURE----- --nextPart2826351.hlTzg5fqbF-- From rajiva@cisco.com Thu Mar 1 23:08:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403FF21F8BC1 for ; Thu, 1 Mar 2012 23:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.683 X-Spam-Level: X-Spam-Status: No, score=-9.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KByVQFSqRz+m for ; Thu, 1 Mar 2012 23:08:01 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EF59021F8B9C for ; Thu, 1 Mar 2012 23:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4320; q=dns/txt; s=iport; t=1330672081; x=1331881681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GIJ09c7sQogBS3mqLuSJ0nakPQ1idZ9JrWQJATWajwM=; b=f3flUfgwRPTrrUhtpV9Dh2Rf2jCYbHBblXfGAU5E6Vdr/pfCjuBx/43l VdZICSysyIsZWLprwi9yNXOVLawuIwUg65JcU3/AY91OCCobn+80PqtUy TX8E7MLga5KEEdLGr9ecAVTVhYnjZAqdI8mhBjM0Cx/OWjlYXoqz9y/0T I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAZxUE+tJXG//2dsb2JhbABDtCKBB4F9AQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEgBh8JCAEBBAESCBqHZAubLwGeWwSJIIVhYwSIT5gKh3aBPQ X-IronPort-AV: E=Sophos;i="4.73,517,1325462400"; d="scan'208";a="63234665" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 02 Mar 2012 07:08:00 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q22780ol025478; Fri, 2 Mar 2012 07:08:00 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 01:08:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 01:07:58 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooA== References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Henderickx, Wim (Wim)" , X-OriginalArrivalTime: 02 Mar 2012 07:08:00.0547 (UTC) FILETIME=[33FABF30:01CCF843] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:08:02 -0000 Hi Wim, That's a reasonable point, but no such proposal has been made for other protocols. In fact, IPv6 deployments have already accommodated 4-octet router-id for routing protocols (which was also a departure from the common practice in IPv4 realm). As Mark T and I discussed in the previous email, the router-id consistency across protocols would be an operational benefit.=20 Focusing on the technicalities, Router ID is meant to ensure the uniqueness of the router within the network while following the protocol, so are we thinking that 4-octet is not good enough to ensure the uniqueness? If so, then it would be worth having that discussion in the Routing and Internet areas that have been focusing on IPv6 at large. While I do agree to 128-bit future expandability as a benefit, the benefit would be trivial (at the expense of message structure changes) if we expanded it for the sake of it, but didn't address the root of the problem.=20 Do you think otherwise? Cheers, Rajiv=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, March 02, 2012 1:42 AM > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, I believe we need to provide both options to ensure both are possible. > If we do not introduce the IPv6 LSR ID now I will be very hard to ad it in the > future. >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: vrijdag 2 maart 2012 7:39 > To: mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Mark, >=20 > Well said. >=20 > I take that we are in agreement wrt 4-octet entity for LDP router-id in > the context of IPv6, as specified. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > Sent: Friday, March 02, 2012 1:31 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > lizhong.jin@zte.com.cn; > > vishwas.ietf@gmail.com > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > wrote: > > > > > In the past, implementations provided the router-id CLI > > > for any interface IPv4 address to be chosen as router-id > > > for various protocols including LDP. > > > > > However, many implementations already evolved the CLI to > > > not even give an "interface" IP address for router-id, > > > to accommodate IPv6. Almost all deployed networks > > > already accommodated that. > > > > We do operate some implementations today that "still" allow > > you to specify the Router-ID for various protocols as an > > independent 32-bit integer (only), and also allow you to > > define the LSR-ID for LDP as an interface (only). This is > > current, shipping 2012 code. > > > > So both scenarios you mention above are still much in play > > today. Whether operators are using them or not (I know we > > are) is another matter entirely. > > > > > Now that LDP is being enhanced to use IPv6, > > > implementations could evolve LDP router-id as well to > > > accommodate IPv6. This would make LDP router-id to be > > > consistent with other protocols delving with IPv6. And > > > this can certainly be operationally beneficial from IPv6 > > > POV. > > > > Agree. > > > > > In fact, one of the implementations allow the router-id > > > to be configured just once and let all protocols just > > > use it, if they wanted. > > > > Yes, we operate some implementations that use this method > > too. It's quite elegant, in that you configure once and > > forget. Other implementations that are more structured means > > operators could easily forget to specify the Router-ID for a > > particular protocol, for better or worse. > > > > Cheers, > > > > Mark. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From mtinka@globaltransit.net Thu Mar 1 23:11:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01F621E8017 for ; Thu, 1 Mar 2012 23:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H52oalMfXpl4 for ; Thu, 1 Mar 2012 23:11:01 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id D90EB21E800F for ; Thu, 1 Mar 2012 23:11:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3Mdk-0003zG-IG; Fri, 02 Mar 2012 15:10:56 +0800 From: Mark Tinka Organization: Global Transit International To: "Henderickx, Wim (Wim)" Date: Fri, 2 Mar 2012 15:10:55 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3944032.RFHmlN2OQt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021510.55974.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:11:01 -0000 --nextPart3944032.RFHmlN2OQt Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 02:42:03 PM Henderickx, Wim (Wim)=20 wrote: > Rajiv, I believe we need to provide both options to > ensure both are possible. If we do not introduce the > IPv6 LSR ID now I will be very hard to ad it in the > future. I do see where Shane and Wim are coming from, as I did find=20 it rather ambiguous that an IPv6-only router would need to=20 specify a 32-bit integer as the Router-ID for some IPv6- based routing protocols to work. But we also need to be concerned about consistency across=20 various protocols that operators are turning on. If 60% of=20 all the key protocols are relying on the presence of a 32- bit integer, even in an IPv6-only network, and then LDP (or=20 some other protocol) has a different take on the matter,=20 does that make things easier or harder for operators? Personally, I'd have preferred Router-ID's for IPv4 and IPv6=20 to be different per AF even for MP-BGP, OSPFv3 and others.=20 But I realize this isn't the right thread for that, which is=20 why I'm open to having both options in LDP. The BGP and OSPF specs. are clear on this issue, but I=20 certainly wouldn't mind them revisiting it in the future. If=20 making LDP "dual-stack" in the Router-ID perspective is what=20 may give the other working groups a kick-in-the-behind to=20 consider the operational value (and challenges) of doing=20 this in 2012 and beyond, I certainly won't stand in their=20 way. Mark. --nextPart3944032.RFHmlN2OQt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUHJ/AAoJEGcZuYTeKm+GfSgP/idpKVhdWZ7W98v82NeRKMTc k9V8CtrQuZsq3Z2NhwDrscC2of45iasux4pDHRdtvLSKAKjysuI6KTSPWI5OzKIy hm0xYjE2tjEfz3JZ+04NIL27gtH7hfjC1iOJRXCXboz4ZzwhMJ0JUMMiNASIWqSl YKxfB2SAz7F7S9Z8BhPsNU8/y8syU458uKxcjSdsOUhnRpnRQw3b68wK5uzJJBIh zR/Xasg7QGJSZvPJ7LOml1rWAtjoPSH+lywHf17X6W8LC8f/skGuR7Bg3HYYTTyK mGs7TpKb8IBv2tDJv6S1F9XJfaR7m7/ErwSGDjw7vOVahsONkNumE5xoUE2YJ12r lLJqmV7nPrD6kSPKkTxISVT969JiKorIbkXDM8aPdVbw3Y+Dche+6jhtapLNPjxl s0yzpPF9ktkW2V77m4PvEbUUOz+5rUQ7LC9KJ59jXKI5xwlKKeaemE5eYNH3hxxP 1kivcU/c2hfBBxndhEMqLUnHTj+RD2Fvg2ZcQipEKFqU213qC5JVgKsZoHlq/cA8 02kKvZxPNmiDKwzGWCQad1iPsxLzfDNFStafZWPsYv3ywt3rUlbhUxxbGXGGl+rP OVISkFNrNnMBpl2B4XwByE/ixw3fsKsb9zYA4gjHVK52SbIerxmR/3TfFnfLi0pO PPzWXmewYdGzFFuPLAEA =/xQF -----END PGP SIGNATURE----- --nextPart3944032.RFHmlN2OQt-- From mtinka@globaltransit.net Thu Mar 1 23:20:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5385321E8060 for ; Thu, 1 Mar 2012 23:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC28orejMiLj for ; Thu, 1 Mar 2012 23:20:42 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4721E800F for ; Thu, 1 Mar 2012 23:20:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3Mn7-00041D-9c; Fri, 02 Mar 2012 15:20:37 +0800 From: Mark Tinka Organization: Global Transit International To: "Rajiv Asati (rajiva)" Date: Fri, 2 Mar 2012 15:20:36 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1845077.LzlaICKFlv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203021520.36665.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:20:42 -0000 --nextPart1845077.LzlaICKFlv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Friday, March 02, 2012 03:07:58 PM Rajiv Asati (rajiva)=20 wrote: > Focusing on the technicalities, Router ID is meant to > ensure the uniqueness of the router within the network > while following the protocol, so are we thinking that > 4-octet is not good enough to ensure the uniqueness? I think what Shane and Wim were alluding to is that even=20 though the 32-bit integer was meant to provide uniqueness in=20 the network, operators have actually made it routeable (by=20 mapping the the Router-ID to the Loopback interface or some=20 other interface on a router that is present in an IGP of=20 choice). While this may not have necessarily been the original intent=20 of the spec., it is what has happened. So what Shane and=20 them are trying to do is maintain that troubleshooting=20 capability within an IPv6-only network. However, ... > If > so, then it would be worth having that discussion in the > Routing and Internet areas that have been focusing on > IPv6 at large. > While I do agree to 128-bit future expandability as a > benefit, the benefit would be trivial (at the expense of > message structure changes) if we expanded it for the > sake of it, but didn't address the root of the problem. =2E.. I do agree with Rajiv's assessment in the above two=20 paragraphs. Mark. --nextPart1845077.LzlaICKFlv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUHTEAAoJEGcZuYTeKm+GWuMQAIcQbtJSQDXKtjOCH72q7bav wJBRGUGWamCTgG4UCrm1zTGkm1lCJH77dc7MsaZY2Hp6hYWhco6AUvA1vOeHjLGc edTBilhVuVuD89K3Z7bYWcwYmmTCLeKcaVN162yJthVlQ5IbXKHNAw67L2TUfdAp U2BTKGAF8R6FlC2ftQSohY9JYMVCr/Wb/Q1AWOH868tqyQb/kaWlxZAA5hrVyDGS cS2ajlWthYhT6WosE3rcPZpGngKRG1tapLIkRrQUxHFs2MyuFlOC1h23iTnhHHzo P6ThrW79Q8dukd3YYtGmDOC9DjcfkAbF0sk+IsVSEj7kD8dFWtIEpEAKsR517+VV pkB5iwy5YY6zWWY2bt8obBWgp08H5J06W4LyBlCaSXn1uSxbnxcGf2MewWm/VHxF nAElK7bUqml64FlVmFM55GPWfmfHcqfh80p9+NARSeOfS+krP9+GpLQ4KE7Kmyuy HQ28hQz6fgwmzptHIlqbFCp9V3Orol9/lBGf1RCRt8KaI9FEmj/u/Kg5tkIhTo7n zndGSaZkYgjFkVN6IlnOpop/9tS5m6BCCRXeJD2hPdJdYbYbBXevMdjj/jt58rif 7aWHzrvTi5gK7gfli3ENxtBf6J7CcZotwqkC3sj3hmy5+eeg8kvvy2FtB3bHZeYX pFwXFsGmRIUV2EC3rJ3X =Ygv7 -----END PGP SIGNATURE----- --nextPart1845077.LzlaICKFlv-- From wim.henderickx@alcatel-lucent.com Fri Mar 2 00:41:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E2521F8B8C for ; Fri, 2 Mar 2012 00:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.285 X-Spam-Level: X-Spam-Status: No, score=-9.285 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kh94UaXKrpih for ; Fri, 2 Mar 2012 00:41:49 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 44CCB21F8B8E for ; Fri, 2 Mar 2012 00:41:48 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q228eEWJ010603 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 09:41:29 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 2 Mar 2012 09:41:20 +0100 From: "Henderickx, Wim (Wim)" To: "Rajiv Asati (rajiva)" , "mtinka@globaltransit.net" Date: Fri, 2 Mar 2012 09:41:20 +0100 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9g Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 08:41:51 -0000 Rajiv, I understand we didn't add a IPv6 router ID option in BGP/OSPF but we shoul= d look at the future to get to IPv6 only networks and as such it will be re= quired. So we are now at a point where we should add this option in all pro= tocols. Since LDP for Ipv6 is open we need to add it now.=20 My 2 cents Cheers, Wim -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: vrijdag 2 maart 2012 8:08 To: Henderickx, Wim (Wim); mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Wim, That's a reasonable point, but no such proposal has been made for other protocols. In fact, IPv6 deployments have already accommodated 4-octet router-id for routing protocols (which was also a departure from the common practice in IPv4 realm). As Mark T and I discussed in the previous email, the router-id consistency across protocols would be an operational benefit.=20 Focusing on the technicalities, Router ID is meant to ensure the uniqueness of the router within the network while following the protocol, so are we thinking that 4-octet is not good enough to ensure the uniqueness? If so, then it would be worth having that discussion in the Routing and Internet areas that have been focusing on IPv6 at large. While I do agree to 128-bit future expandability as a benefit, the benefit would be trivial (at the expense of message structure changes) if we expanded it for the sake of it, but didn't address the root of the problem.=20 Do you think otherwise? Cheers, Rajiv=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, March 02, 2012 1:42 AM > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, I believe we need to provide both options to ensure both are possible. > If we do not introduce the IPv6 LSR ID now I will be very hard to ad it in the > future. >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: vrijdag 2 maart 2012 7:39 > To: mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Mark, >=20 > Well said. >=20 > I take that we are in agreement wrt 4-octet entity for LDP router-id in > the context of IPv6, as specified. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > Sent: Friday, March 02, 2012 1:31 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > lizhong.jin@zte.com.cn; > > vishwas.ietf@gmail.com > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > wrote: > > > > > In the past, implementations provided the router-id CLI > > > for any interface IPv4 address to be chosen as router-id > > > for various protocols including LDP. > > > > > However, many implementations already evolved the CLI to > > > not even give an "interface" IP address for router-id, > > > to accommodate IPv6. Almost all deployed networks > > > already accommodated that. > > > > We do operate some implementations today that "still" allow > > you to specify the Router-ID for various protocols as an > > independent 32-bit integer (only), and also allow you to > > define the LSR-ID for LDP as an interface (only). This is > > current, shipping 2012 code. > > > > So both scenarios you mention above are still much in play > > today. Whether operators are using them or not (I know we > > are) is another matter entirely. > > > > > Now that LDP is being enhanced to use IPv6, > > > implementations could evolve LDP router-id as well to > > > accommodate IPv6. This would make LDP router-id to be > > > consistent with other protocols delving with IPv6. And > > > this can certainly be operationally beneficial from IPv6 > > > POV. > > > > Agree. > > > > > In fact, one of the implementations allow the router-id > > > to be configured just once and let all protocols just > > > use it, if they wanted. > > > > Yes, we operate some implementations that use this method > > too. It's quite elegant, in that you configure once and > > forget. Other implementations that are more structured means > > operators could easily forget to specify the Router-ID for a > > particular protocol, for better or worse. > > > > Cheers, > > > > Mark. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Fri Mar 2 01:28:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E0421F8C18 for ; Fri, 2 Mar 2012 01:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aM2XbrLzjaL for ; Fri, 2 Mar 2012 01:28:16 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2200921F8C16 for ; Fri, 2 Mar 2012 01:28:15 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 60C262A8002; Fri, 2 Mar 2012 10:28:10 +0100 (CET) Message-ID: <4F5092A8.8000600@pi.nu> Date: Fri, 02 Mar 2012 10:28:08 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-koike-mpls-tp-temporal-hitless-psm@tools.ietf.org" , Ross Callon , George Swallow , Adrian Farrel References: <4F327811.1000700@pi.nu> <4F3E8461.9070002@pi.nu> In-Reply-To: <4F3E8461.9070002@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Addition on this poll - the IPR aspect (Was Re: Poll on draft-koike-mpls-tp-temporal-hitless-psm) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 09:28:16 -0000 All, this poll has ended. We have good support to make it a working group document, however we will wait until we hear from all authors regarding whether all IPR they are ware of has been disclosed before we request that the document be posted as a working group document. /Loa for the MPLS wg co-chairs On 2012-02-17 17:46, Loa Andersson wrote: > All, > > this poll has been running for some time, according the process the > wg chair outlined in a recent mail it should have been preceded > by a mail reminding about IPRs. We didn't have that process really > in place when the poll was started. So here comes the IPR remeinder. > > As you can see from the poll the wg chairs have sent out the authors > have asked for draft-koike-mpls-tp-temporal-hitless-psm to be > considered for adoption as a WG document. We would like to check > whether there is IPR on the document that needs to be disclosed. > We will weigh this in when we judge the consensus on the call for > adoption. > > Are you aware of any IPR that applies to draft-koike-mpls-tp-temporal- > hitless-psm? If so, has this IPR been disclosed in compliance with IETF > IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. This document will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > /Loa > > (as MPLS WG co-chair) > > > > On 2012-02-08 14:26, Loa Andersson wrote: >> Working Group, >> >> this is to start a two week poll to see if there is support to make >> >> draft-koike-mpls-tp-temporal-hitless-psm-04 >> >> mpls working group drafts. >> >> Pleased send your comments to the mpls working group mailing list >> (mpls@ietf.org). >> >> This poll ends February 22, 2012! >> >> Loa >> for the mpls wg chairs >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From mustapha.aissaoui@alcatel-lucent.com Fri Mar 2 06:43:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC80F21F8648 for ; Fri, 2 Mar 2012 06:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA6bVD3VBiwH for ; Fri, 2 Mar 2012 06:43:17 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB021F8645 for ; Fri, 2 Mar 2012 06:43:02 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q22EgwnL023012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 08:42:58 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22Egw08020144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 08:42:58 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 2 Mar 2012 08:42:58 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" , "lizhong.jin@zte.com.cn" , "vishwas.ietf@gmail.com" Date: Fri, 2 Mar 2012 08:42:54 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3h+t1pocdfUrCSq6tiXLdLEPZMgATF64QAAuPoBYABtb58AAY6SlA Message-ID: <5DF53972F7E9134782DCE51624466FE50AD58116F3@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:43:18 -0000 UmFqaXYsDQpGcm9tIGEgcHVyZSBwcm9vdG9jb2wgcGVyc3BlY3RpdmUsIHlvdSBhcmUgY29ycmVj dC4gDQoNClRoaXMgaXMgaG93ZXZlciBhIHByYWN0aWNhbCBtYXR0ZXIuIE1hbnkgZGVwbG95bWVu dHMgdG9kYXkgaGF2ZSB0aGUgcm91dGVyLWlkIGRlZmF1bHQgdG8gYSB3ZWxsIGtub3duIHN5c3Rl bSBsb29wYmFjayBpbnRlcmZhY2UgSVB2NCBhZGRyZXNzLiBUaGlzIG1lYW5zIHRoYXQgcm91dGlu ZyBwcm90b2NvbHMsIE1QTFMgc2lnbmFsaW5nIHByb3RvY29scyxhbmQgT0FNIHByb3RvY29scyBj YW4gb3BlcmF0ZSBkaXJlY3RseSB1c2luZyB0aGlzIGFkZHJlc3MuIENlcnRhaW5seSB3aXRoIEJH UCwgdGhlIG9wZXJhdG9yIGNhbiBjb25maWd1cmUgYSBuZWlnaGJvdXIgYWRkcmVzcyB3aGljaCBp cyBJUHY2IGFuZCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgcm91dGVyLWlkIGJ1dCB0aGF0IHJvdXRl ci1pZCBpcyBhbHJlYWR5IHJlcXVpcmVkIGZvciB0aGUgb3BlcmF0aW9uIG9mIElQdjQgQkdQIG5l aWdoYm91cnMgYW5kIG90aGVyIHByb3RvY29scyBhbmQgc3VjaCB0aGlzIGlzIG1hbmFnZWFibGUu IEFzIHdlIGdvIGludG8gYWxsIElQdjYgZGVwbG95bWVudHMsIHdlIG5lZWQgdG8gaGF2ZSBtZWFu cyBmb3IgZGVwbG95bWVudHMgdG8gaGF2ZSBhIHNpbWlsYXIgZGVmYXVsdCBJUHY2IHN5c3RlbSBh ZGRyZXNzLiBJdCBpcyBoYXJkbHkganVzdGlmaWFibGUgYXQgdGhhdCBwb2ludCBpbiB0aW1lIHRv IGNvbmZpZ3VyZSB0d28gZGlmZmVyZW50IGFkZHJlc3NlcyB0byBnZXQgdGhlIHByb3JvdGNvbHMg d29ya2luZyBieSBkZWZhdWx0LiBXZSBtYXkgYXMgd2VsbCBtYWtlIHRoaXMgY2hhbmdlIG5vdyBh cyBwYXJ0IG9mIGFsbG93aW5nIHNlcGFyYXRlIExEUCBzZXNzaW9ucyBmb3IgSVB2NCBhbmQgSVB2 NiBvciB3ZSB3aWxsIGNyZWF0ZSB5ZXQgYSB0aGlyZCBMRFAgdmVyc2lvbiBudW1iZXIgaW4gdGhl IG5leHQgZmV3IHllYXJzLg0KDQpSZWdhcmRzLA0KTXVzdGFwaGEuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKSBbbWFpbHRvOnJhaml2YUBj aXNjby5jb21dIA0KU2VudDogVGh1cnNkYXksIE1hcmNoIDAxLCAyMDEyIDk6NDQgUE0NClRvOiBB aXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgbGl6aG9uZy5qaW5AenRlLmNvbS5jbjsgdmlz aHdhcy5pZXRmQGdtYWlsLmNvbQ0KQ2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbbXBs c10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQoNCkhpIE11c3RhcGhh LA0KDQpJIHdhcyByZWZlcnJpbmcgdG8gTFNSIElEIGFuZCByb3V0ZXItaWQgZGlzY3Vzc2lvbiBp biBteSByZXNwb25zZS4NClJvdXRlci1pZCBzZWxlY3Rpb24gaGFzIG5vdGhpbmcgdG8gZG8gd2l0 aCBzZXBhcmF0ZSBMRFAgc2Vzc2lvbiBwZXIgQUZJLg0KDQpEbyB5b3UgZGlzYWdyZWUgdG8gd2hh dCBJIGRlc2NyaWJlZCB3cnQgTFNSIElEIGJlaW5nIDQtb2N0ZXQ/IA0KDQpDaGVlcnMsDQpSYWpp dg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFpc3Nhb3VpLCBNdXN0 YXBoYSAoTXVzdGFwaGEpIFttYWlsdG86bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC0NCj4gbHVj ZW50LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDAxLCAyMDEyIDY6MjUgUE0NCj4gVG86 IFJhaml2IEFzYXRpIChyYWppdmEpOyAnbGl6aG9uZy5qaW5AenRlLmNvbS5jbic7ICd2aXNod2Fz LmlldGZAZ21haWwuY29tJw0KPiBDYzogJ21wbHNAaWV0Zi5vcmcnDQo+IFN1YmplY3Q6IFJlOiBb bXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQo+IA0KPiBSYWpp diwNCj4gWW91IGhhdmUgaGVhcmQgdGhlIHJlcXVpcmVtZW50cyBmcm9tIG9wZXJhdG9ycyBvbiB0 aGlzIG1haWxpbmcgbGlzdCANCj4gYXNraW5nIGZvciBzZXBhcmF0ZSBMRFAgc2Vzc2lvbnMgZm9y IElQdjQgYW5kIElQdjYuDQo+IA0KPiBUaGUgZHJhZnQgaW4gaXRzIGN1cnJlbnQgZm9ybSBkb2Vz IG5vdCBtZWV0IHRoaXMgcmVxdWlyZW1lbnQgYW5kIHlldCANCj4gaXQgYWRkcyBjb25zdHJhaW50 cyB3aGljaCBtYWtlcyBpdCBpbmNvbXBhdGlibGUgd2l0aCBSRkM1MDM2LiBJdCBhbHNvIA0KPiBk b3VibGVzIHRoZSBudW1iZXIgb2YgSGVsbG8gYWRqYWNlbmNpZXMgZm9yIG5vIGdhaW4uDQo+IA0K PiBXaGF0IGlzIHRoZSBwb2ludCBvZiBjYXJyeWluZyBmb3J3YXJkIHRoaXMgZHJhZnQgYXMgaXM/ DQo+IA0KPiBNdXN0YXBoYS4NCj4gU2VudCBmcm9tIG15IEJsYWNrYmVycnkhDQo+IA0KPiAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IFJhaml2IEFzYXRpIChyYWppdmEpIDxy YWppdmFAY2lzY28uY29tPg0KPiBUbzogTGl6aG9uZyBKaW4gPGxpemhvbmcuamluQHp0ZS5jb20u Y24+OyBWaXNod2FzIE1hbnJhbCANCj4gPHZpc2h3YXMuaWV0ZkBnbWFpbC5jb20+DQo+IENjOiBB aXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgbXBsc0BpZXRmLm9yZyA8bXBsc0BpZXRmLm9y Zz4NCj4gU2VudDogVGh1IE1hciAwMSAxMjowNzoyMyAyMDEyDQo+IFN1YmplY3Q6IFJFOiBbbXBs c10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQo+IA0KPiBJIGFncmVl LiBCYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiAmIGFncmVlbWVudCwgd2Ugd2lsbCBwcm9jZWVkIHdp dGggdGhlIA0KPiBkb2N1bWVudCBhcyBpdC1pcy4NCj4gDQo+IEl0IGlzIHdvcnRoIG5vdGluZyB0 aGF0IHRoaXMgKExTUiBJRCkgcmVhbGx5IHJlbGF0ZXMgdG8gcm91dGVyLWlkLCANCj4gd2hpY2gg aXMgdXNlZCBieSBub3Qgb25seSBMRFAsIGJ1dCBhbHNvIG90aGVyIHByb3RvY29scyAoZS5nLiBC R1AsIA0KPiBPU1BGKS4gT2YgY291cnNlLCBlYWNoIHByb3RvY29sIGNvdWxkIHVzZSB0aGUgY29t bW9uIHJvdXRlci1pZCBvciBhIGRpZmZlcmVudCBvbmUuDQo+IFN0cmljdGx5IHNwZWFraW5nLCBh bGwgdGhlc2UgcHJvdG9jb2xzIGRlZmluZSByb3V0ZXItaWQgdG8gYmUgbm90IA0KPiByb3V0YWJs ZSBhbmQgbGV2ZXJhZ2UgdGhlIHNhbWUgNC1vY3RldCBudW1iZXIgZm9yIElQdjYgYXMgd2VsbC4N Cj4gDQo+IEZvciBleCwgT25lIGNvdWxkIGxvb2sgYXQgUkZDIDYyODYsIHdoaWNoIHVwZGF0ZWQg dGhlIGJhc2UgQkdQIHNwZWMgDQo+IFJGQzQyNzEsIHRvIGVuc3VyZSB0aGUgdXNhZ2Ugb2YgNC1v Y3RldCBhcyB0aGUgQkdQIElEIGluIHRoZSBjb250ZXh0IA0KPiBvZiBJUHY2Lg0KPiANCj4gVGhl cmUgaXMgbm8gYmVuZWZpdCAmIHJlYXNvbiB0byBjaGFuZ2UgTFNSIElEIGRlZmluaXRpb24gMzIt Yml0IHRvIA0KPiAxMjgtYml0IGZvciBMRFAgd2l0aG91dCBjb25zaWRlcmluZyB0aGUgYmlnZ2Vy IHBpY3R1cmUgaGF2aW5nIG90aGVyIA0KPiBwcm90b2NvbHMgaW4gdGhlIG5ldHdvcmsuIFRoaXMg c3BlY2lmaWMgaXNzdWUgaGFzIGJlZW4gdmlzaXRlZCBiZWZvcmUgDQo+IGFuZCBjbG9zZWQuDQo+ IA0KPiBDaGVlcnMsDQo+IFJhaml2DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYNCj4gT2YNCj4gPiBMaXpob25nIEppbg0KPiA+IFNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAwMSwgMjAxMiAzOjQ2IEFNDQo+ID4gVG86IFZpc2h3YXMgTWFucmFsDQo+ID4g Q2M6IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBtcGxzQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUmU6IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYN Cj4gPg0KPiA+DQo+ID4NCj4gPiA+IEhpIExpemhvbmcvIFByYW5qYWwvIE11c3RhcGhhLA0KPiA+ ID4NCj4gPiA+IFNvIHRoZSB0d28gbWFpbiBjb21tZW50cyB0aGF0IGhhdmUgY29tZSBhZnRlciBs YXN0IGNhbGwgYXJlOg0KPiA+ID4NCj4gPiA+IDEuIEFsbG93IGZvciBzZXBhcmF0aW9uIG9mIHNl c3Npb25zIGFsb25nIHdpdGggdGhlIGFkamFjZW5jeS4NCj4gPiA+IDIuIEFsbG93IGZvciBhbiBJ UHY2IGJhc2VkIExTUi1JRC4NCj4gPiA+DQo+ID4gPiBUaGUgc2Vjb25kIGNvdWxkIGxlYWQgdG8g Y2hhbmdlcyByZXF1aXJlZCBpbiBib3RoIE9TUEYgYW5kIElTLUlTLCANCj4gPiA+IGFzIHdlbGwg YmVjYXVzZSB0aGUgbmV3IExTUiBJRCB3b3VsZCB0aGVuIG5lZWQgdG8gYmUgZXhjaGFuZ2VkLiBX ZSANCj4gPiA+IGNvdWxkIHRyZWF0IGl0IGFzIGFuIGVuaGFuY2VtZW50IGluc3RlYWQgaW4gbXkg dmlldy4gRG8geW91IGFncmVlPw0KPiA+IFtMaXpob25nXSBhZ3JlZSwgYnV0IGFzIEthbXJhbiBw b2ludGVkIG91dCBhbHNvIGluIGFub3RoZXIgZW1haWwsIGl0DQo+IGlzIG5vdA0KPiA+IG5lY2Vz c2FyeSB0byBmbG9vZCBMU1ItSUQgaW4gcm91dGluZyBwcm90b2NvbCwgdGhlIHRyYW5zcG9ydCBh ZGRyZXNzDQo+IGluIGhlbGxvDQo+ID4gbWVzc2FnZSBpcyByZXF1aXJlZCB0byBiZSBmbG9vZGVk Lg0KPiA+DQo+ID4gUmVnYXJkcw0KPiA+IExpemhvbmcNCj4gPg0KPiA+ID4NCj4gPiA+IFRoYW5r cywNCj4gPiA+IFZpc2h3YXMNCj4gPg0KPiA+ID4gT24gV2VkLCBGZWIgMjksIDIwMTIgYXQgNTow MyBQTSwgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkgPCANCj4gPiA+IHByYW5qYWwuZHV0dGFA YWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToNCj4gPiA+IFllcywgSSBzdXBwb3J0IHRoYXQgdG9v LiBUaGVyZSB3b3VsZCBiZSBuZXR3b3JrIG1hbmFnZW1lbnQgaXNzdWVzIA0KPiA+ID4gd2l0aCBt YXBwaW5nIG9mIDQgYnl0ZSBMU1ItSUQgdG8gYW4gSVBWNiByZW1vdGUgYWRkcmVzcy4NCj4gPiA+ IE1vc3Qgb2YgdGhlIGltcGxlbWVudGF0aW9ucyBJIGtub3cgb2ZmIHVzdWFsbHkgbWFwcyA0IGJ5 dGUgb2YgdGhlIA0KPiA+ID4gTFNSLUlEIHdpdGggYSBsb2NhbCBpcHY0IGludGVyZmFjZSBhZGRy ZXNzIGluIHRoZSBzeXN0ZW0uDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gUHJhbmphbA0K PiA+ID4NCj4gPiA+DQo+ID4gPiBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvbmcuamlu QHp0ZS5jb20uY25dDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI5LCAyMDEyIDQ6 NTcgUE0NCj4gPiA+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKQ0KPiA+ID4gQ2M6 IG1wbHNAaWV0Zi5vcmc7IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOw0KPiB2aXNod2FzLmll dGZAZ21haWwuY29tDQo+ID4gPg0KPiA+ID4gU3ViamVjdDogUkU6IFttcGxzXSBDb21tZW50cyBv biBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYNCj4gPiA+DQo+ID4gPg0KPiA+ID4gSGkgTXVz dGFwaGEsDQo+ID4gPiBJIGFncmVlLCBhbmQgSSBhbHNvIHByZWZlciB0byBkZWZpbmluZyBhIElQ djYgZm9ybWF0ZWQgTFNSLUlELCBhcyANCj4gPiA+IEkgcG9pbnRlZCBvdXQgaW4gbXkgZmlyc3Qg ZW1haWwuDQo+ID4gPg0KPiA+ID4gVGhhbmtzDQo+ID4gPiBMaXpob25nDQo+ID4gPg0KPiA+ID4N Cj4gPiA+ICJBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKSINCj4gPG11c3RhcGhhLmFpc3Nh b3VpQGFsY2F0ZWwtbHVjZW50LmNvbQ0KPiA+ID4gPiB3cm90ZSAyMDEyLzAzLzAxIDA0OjM1OjQx Og0KPiA+ID4NCj4gPiA+ID4gSGkgTGl6aG9uZywNCj4gPiA+ID4gSSBhY3R1YWxseSB0aGluayB0 aGF0IHdlIHdvdWxkIG5lZWQgdG8gZGVmaW5lIGEgbmV3IG9uZSB3aGljaCANCj4gPiA+ID4gd2ls bCBhY2NvbW9kYXRlIGFuIElQdjYgLzEyOCBhZGRyZXNzLiBPdGhlcndpc2UsIHRhcmdldGVkIExE UCANCj4gPiA+ID4gc2Vzc2lvbnMNCj4gaW4NCj4gPiA+ID4gYSBhbGwtSVB2NiBuZXR3b3JrIHdp bGwgbm90IGJlIHBvc3NpYmxlLiBJIGNhbm5vdCBzZWUgdGhhdA0KPiBvcGVyYXRvcnMNCj4gPiA+ ID4gd2lsbCBzdGFydCBtYWludGFpbmluZyBhIG1hcHBpbmcgb2Ygc29tZSBnbG9iYWwgbm9uIHJv dXRhYmxlDQo+IExTUi1pZA0KPiA+ID4gPiB2YWx1ZSB0byBhbiBJUHY2IGxvb3BiYWNrIGludGVy ZmFjZSBvbiBlYWNoIHJvdXRlciBpbiB0aGUgbmV0d29yay4NCj4gPiA+ID4NCj4gPiA+ID4gTXVz dGFwaGEuDQo+ID4gPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmDQo+ID4gT2YNCj4gPiA+ID4gQWlzc2FvdWks IE11c3RhcGhhIChNdXN0YXBoYSkNCj4gPiA+ID4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcs IDIwMTIgMTA6MTIgQU0NCj4gPiA+ID4gVG86IExpemhvbmcgSmluOyBEdXR0YSwgUHJhbmphbCBL IChQcmFuamFsKTsNCj4gdmlzaHdhcy5pZXRmQGdtYWlsLmNvbQ0KPiA+ID4gPiBDYzogbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtbXBscy1sZHAtaXB2Ni0wNg0KPiA+ID4NCj4gPiA+ID4gTGl6aG9uZywNCj4gPiA+ID4gdGhl IGV4aXN0aW5nIExTUi1pZCB3aWxsIGRvIHRoZSBqb2IgYW5kIHNob3VsZCBiZSBzdXBwb3J0ZWQg DQo+ID4gPiA+IHNpbmNlIHRoZSBMU1ItaWQgbmVlZCBub3QgYmUgYW4gSVAgYWRkcmVzcy4gTW9z dCBpbXBsZW1lbnRhdGlvbnMgDQo+ID4gPiA+IHdpbGwgYWN0dWFsbHkgcG9wdWxhdGUgdGhlIGZp ZWxkIHdpdGggYSAvMzIgYWRkcmVzcyBpbiBJUHY0IGFuZCANCj4gPiA+ID4gdGh1cyBJZiBuZWNl c3Nhcnkgd2UgY291bGQgZGVmaW5lIGEgbmV3IGZvcm1hdCB0byBhbGxvdyB0aGUgdXNlIA0KPiA+ ID4gPiBvZiAvMTI4DQo+ID4gPiBJUHY2YWRkcmVzc2VzLg0KPiA+ID4gPg0KPiA+ID4gPiBNdXN0 YXBoYS4NCj4gPiA+ID4NCj4gPiA+ID4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25n LmppbkB6dGUuY29tLmNuXQ0KPiA+ID4gPiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDEy IDEwOjIzIFBNDQo+ID4gPiA+IFRvOiBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsgdmlzaHdh cy5pZXRmQGdtYWlsLmNvbTsgDQo+ID4gPiA+IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEp DQo+ID4gPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10g Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2LTA2DQo+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBIaSwNCj4gPiA+ID4gSSB3b25kZXIgaWYgaXQgaXMgZmVhc2libGUgdG8gdXNlIExE UCBjYXBhYmlsaXR5IHRvIGFkdmVydGlzZSANCj4gPiA+ID4gSVB2NiBGRUMgd2l0aG91dCBJUHY2 IGFkamFjZW5jeSwgYW5kIG9ubHkgdXNlIG9uZSBhZGphY2VuY3kgZm9yIA0KPiA+ID4gPiBMRFAg c2Vzc2lvbiBpbiBkdWFsLXN0YWNrIG5ldHdvcmsuIExEUCBjYXBhYmlsaXR5IGlzIHBlciBub2Rl IA0KPiA+ID4gPiBjYXBhYmlsaXR5LCBub3QgcGVyIGludGVyZmFjZSBjYXBhYmlsaXR5LiBCdXQg Zm9yIExEUCB0byBjaG9vc2UNCj4gdGhlDQo+ID4gPiA+IGNvcnJlY3QgZG93bnN0cmVhbSBzZXNz aW9uIGFuZCBvdXRwdXQgaW50ZXJmYWNlIGZvciBlYWNoIEZFQywgaXQgDQo+ID4gPiA+IHNob3Vs ZCBhbHNvIGNoZWNrIGlmIHRoZSBvdXRwdXQgaW50ZXJmYWNlIGlzIExEUCBlbmFibGVkIG9yIG5v dC4NCj4gVGhlDQo+ID4gPiA+IGxpbmsgYWRqYWNlbmN5IGNvdWxkIGJlIHVzZWQgdG8gYXNzaXN0 IHN1Y2gga2luZCBvZiBjaGVja2luZy4NCj4gPiA+ID4NCj4gPiA+ID4gSG93ZXZlciwgSU1PLCBp dCBpcyB2YWx1YWJsZSB0byBhbGxvdyB0d28gaW5kZXBlbmRlbnQgTERQIA0KPiA+ID4gPiBzZXNz aW9ucyBmb3IgSVB2NCBhbmQgSVB2NiBhcyBhbiBvcHRpb24uIFJlZ2FyZGluZyB0aGUgZm9ybWF0 IA0KPiA+ID4gPiBkZWZpbml0aW9uIGluIFJGQzUwMzYsIHdlIG1heSBuZWVkIG5ldyBMRFAgdmVy c2lvbiBudW1iZXIgdG8gDQo+ID4gPiA+IGlkZW50aWZ5IElQdjYNCj4gTFNSLUlELg0KPiA+ID4g PiBPciB3ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1JRCBmb3IgSVB2NiB3aXRoIElQdjQsIGJ1 dCBJIA0KPiA+ID4gPiBwcmVmZXIgbmV3IGZvcm1hdCBvZiBMU1ItSUQuDQo+ID4gPiA+DQo+ID4g PiA+IFJlZ2FyZHMNCj4gPiA+ID4gTGl6aG9uZw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+ DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE1lc3NhZ2U6IDENCj4gPiA+ ID4gPiBEYXRlOiBUdWUsIDcgRmViIDIwMTIgMDU6Mjg6MjEgKzA1MzANCj4gPiA+ID4gPiBGcm9t OiAiRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCkiDQo+IDxwcmFuamFsLmR1dHRhQGFsY2F0ZWwt bHVjZW50LmNvbT4NCj4gPiA+ID4gPiBUbzogVmlzaHdhcyBNYW5yYWwgPHZpc2h3YXMuaWV0ZkBn bWFpbC5jb20+DQo+ID4gPiA+ID4gQ2M6ICJBaXNzYW91aSwgTXVzdGFwaGEgXChNdXN0YXBoYVwp Ig0KPiA+ID4gPiA+ICAgIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+LCAg ICJtcGxzQGlldGYub3JnIg0KPiA+ID4gPiA+ICAgIDxtcGxzQGlldGYub3JnPg0KPiA+ID4gPiA+ IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxkcC1pcHY2 LTA2DQo+ID4gPiA+ID4gTWVzc2FnZS1JRDoNCj4gPiA+ID4gPg0KPiA+DQo+IDxDNTg0MDQ2NDY2 RUQyMjRDQTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdASU5CQU5TWENITUJTQTMuaW4uDQo+ID4g PiA+ID4gYWxjYXRlbC1sdWNlbnQuY29tPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQ29udGVudC1U eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEkgd291bGQgcmF0aGVyIGZvciBjb21wbGV0ZSBzZXBhcmF0aW9uIHdpdGggbXVsdGlwbGUgbHNy LWlkDQo+IGJlY2F1c2UNCj4gPiA+ID4gPiBoYXZpbmcgc2VwYXJhdGUgbGluayBhZGphY2VuY2ll cyBkb2VzIG5vdCByZWFsbHkgc29sdmVkIGFueQ0KPiBwcm9ibGVtLg0KPiA+ID4gPiA+IFNpbmNl IGhlbGxvIGFkamFjZW5jaWVzIGFyZSBhc3NvY2lhdGVkIHdpdGggYSBsaW5rLCBzdGlsbCBmYXRl IA0KPiA+ID4gPiA+IHNoYXJpbmcgd291bGQgY29udGludWUgb3ZlciB0aGUgc2luZ2xlIGxkcC90 Y3Agc2Vzc2lvbiBmb3IgDQo+ID4gPiA+ID4gSVBWNA0KPiBhbmQNCj4gPiBJUFY2Lg0KPiA+ID4g PiA+IEhhdmluZyBJUFY0IGFuZCBJUFY2IHNwZWNpZmljIGhlbGxvIGFkamFjZW5jaWVzIG92ZXIg YSBsaW5rDQo+IHdvdWxkDQo+ID4gPiA+ID4gb25seSBkZWNpZGUgd2hldGhlciBzdWNoIGEgbGlu ayBpcyB0byBiZSBwcm9ncmFtbWVkIGZvciBJUFY0IA0KPiA+ID4gPiA+IG9yDQo+IElQVjYNCj4g PiA+ID4gPiBlZ3Jlc3MgdHJhZmZpYyBidXQgSSBzZWUgaXQgYXMgb3ZlcmtpbGwgYW5kIHVubmVj ZXNzYXJ5DQo+ID4gPiBzY2FsYWJpbGl0eSBpbXBhY3RzLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g VGhhbmtzLA0KPiA+ID4gPiA+IFByYW5qYWwNCj4gPiA+ID4gPg0KPiA+ID4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiBa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIA0KPiA+ID4gPiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgDQo+ID4gPiA+IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlDQo+IG9ibGlnYXRlZA0KPiA+ID4g PiB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgDQo+ID4gPiA+IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+ ID4gPiA+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBj b25maWRlbnRpYWwgDQo+ID4gPiA+IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIA0KPiA+ID4gPiB3aG9tDQo+IHRoZXkNCj4gPiA+ ID4gYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2UgDQo+ID4gPiA+IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiANCj4gPiA+ID4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+ID4gPiA+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURQ0KPiBBbnRpLVNwYW0NCj4gPiBzeXN0 ZW0uDQo= From pranjal.dutta@alcatel-lucent.com Fri Mar 2 09:02:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CF621F86C2 for ; Fri, 2 Mar 2012 09:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.38 X-Spam-Level: X-Spam-Status: No, score=-7.38 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGRhoH-2U3dl for ; Fri, 2 Mar 2012 09:02:43 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6321F86D5 for ; Fri, 2 Mar 2012 09:02:43 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q22H2OEW028017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 11:02:30 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22H2ML9029686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 22:32:22 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 2 Mar 2012 22:32:22 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Henderickx, Wim (Wim)" , "Rajiv Asati (rajiva)" , "mtinka@globaltransit.net" Date: Fri, 2 Mar 2012 22:32:19 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 17:02:44 -0000 Rajiv, We shouldn't be ruling out the fact that there are some differences = in applications of LDP compared to OSPF or BGP. If we have IPV6 only transp= ort network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has t= o advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T-LDP = has to auto-create targeted sessions. We can't force to set-up another ip4 = network just for some applications. It won't be possible to map 4 byte ldp = LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID is mus= t for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility and b= etter to add it now. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Hen= derickx, Wim (Wim) Sent: Friday, March 02, 2012 12:41 AM To: Rajiv Asati (rajiva); mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Rajiv, I understand we didn't add a IPv6 router ID option in BGP/OSPF but we shoul= d look at the future to get to IPv6 only networks and as such it will be re= quired. So we are now at a point where we should add this option in all pro= tocols. Since LDP for Ipv6 is open we need to add it now.=20 My 2 cents Cheers, Wim -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: vrijdag 2 maart 2012 8:08 To: Henderickx, Wim (Wim); mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Wim, That's a reasonable point, but no such proposal has been made for other protocols. In fact, IPv6 deployments have already accommodated 4-octet router-id for routing protocols (which was also a departure from the common practice in IPv4 realm). As Mark T and I discussed in the previous email, the router-id consistency across protocols would be an operational benefit.=20 Focusing on the technicalities, Router ID is meant to ensure the uniqueness of the router within the network while following the protocol, so are we thinking that 4-octet is not good enough to ensure the uniqueness? If so, then it would be worth having that discussion in the Routing and Internet areas that have been focusing on IPv6 at large. While I do agree to 128-bit future expandability as a benefit, the benefit would be trivial (at the expense of message structure changes) if we expanded it for the sake of it, but didn't address the root of the problem.=20 Do you think otherwise? Cheers, Rajiv=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, March 02, 2012 1:42 AM > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, I believe we need to provide both options to ensure both are possible. > If we do not introduce the IPv6 LSR ID now I will be very hard to ad it in the > future. >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: vrijdag 2 maart 2012 7:39 > To: mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Mark, >=20 > Well said. >=20 > I take that we are in agreement wrt 4-octet entity for LDP router-id in > the context of IPv6, as specified. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > Sent: Friday, March 02, 2012 1:31 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > lizhong.jin@zte.com.cn; > > vishwas.ietf@gmail.com > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > wrote: > > > > > In the past, implementations provided the router-id CLI > > > for any interface IPv4 address to be chosen as router-id > > > for various protocols including LDP. > > > > > However, many implementations already evolved the CLI to > > > not even give an "interface" IP address for router-id, > > > to accommodate IPv6. Almost all deployed networks > > > already accommodated that. > > > > We do operate some implementations today that "still" allow > > you to specify the Router-ID for various protocols as an > > independent 32-bit integer (only), and also allow you to > > define the LSR-ID for LDP as an interface (only). This is > > current, shipping 2012 code. > > > > So both scenarios you mention above are still much in play > > today. Whether operators are using them or not (I know we > > are) is another matter entirely. > > > > > Now that LDP is being enhanced to use IPv6, > > > implementations could evolve LDP router-id as well to > > > accommodate IPv6. This would make LDP router-id to be > > > consistent with other protocols delving with IPv6. And > > > this can certainly be operationally beneficial from IPv6 > > > POV. > > > > Agree. > > > > > In fact, one of the implementations allow the router-id > > > to be configured just once and let all protocols just > > > use it, if they wanted. > > > > Yes, we operate some implementations that use this method > > too. It's quite elegant, in that you configure once and > > forget. Other implementations that are more structured means > > operators could easily forget to specify the Router-ID for a > > particular protocol, for better or worse. > > > > Cheers, > > > > Mark. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Fri Mar 2 09:17:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9321F868A for ; Fri, 2 Mar 2012 09:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.033 X-Spam-Level: X-Spam-Status: No, score=-7.033 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2HBvO2m5XX8 for ; Fri, 2 Mar 2012 09:17:14 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFD821F86A7 for ; Fri, 2 Mar 2012 09:17:14 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q22HGpax009790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 11:16:54 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22HGnwJ030654 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 22:46:49 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 2 Mar 2012 22:46:49 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , Shane Amante Date: Fri, 2 Mar 2012 22:46:46 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAACLLo0AL6hK0A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CAB5AINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 17:17:20 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CAB5AINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kamran, Further some comments below. Thanks, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kam= ran Raza Sent: Thursday, March 01, 2012 10:20 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> Esp. for T-LDP hellos we would always like to match destination IP of he= llo packets to match 4 byte LSR-ID, Just a quick comment on the above statement: Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e.= v4 loopback /32 in most impl), there are still some other cases where they= do not _always_ use LSR-Id as the T-LDP destination. One such case will be= when T-LDP session needs to be established/signaled with a remote PE that = is discovered via BGP (AD). In this case, the BGP discovered remote PE's /= 32 address **may not** match remote PE's LDP /32 address (LSR Id). The same example can also be applied to BGP AD (for v6) and T-LDP v6. [Pranjal] However this is implementation specific. In BGP-AD or Dynamic MS-= PW it certainly adds value when BGP discovered remote PE address is same as= 4 byte of LDP LSR-ID and thus LSR-ID is routable. Implementations can auto= -create T-LDP sessions using BGP remote address as 4 byte of LDP LSR-ID. It= has tremendous operational benefits since it serves the purpose for "auto-= discovery" in such applications and thus avoids another layer of mapping be= tween BGP next-hops->ldp lsr-ids. There are running codes in field that is = based on such provisioning models. RFC 5036 never says that 4 byte router I= D MUST not be routable. If we apply the same with BGP-AD V6 and tomorrow if= we have IPV6 only transport networks then only way we can automate T-LDP s= ession set-up is by using a 16 byte LSR-ID (v2) since we have to make L2VPN= /MS-PW AFI/SAFI NLRI routable via IPV6. So I wouldn't stick to existing the= ory or have a dogmatic view on RFC 5036. Thx. -- Kamran On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" wrote: Esp. for T-LDP hellos we would always like to match destination IP of hello= packets to match 4 byte LSR-ID, so same is applicable for IPV6. TCP Transport address is an after affect - T-LDP hellos should be sent to t= he correct IPV6 address first before TCP transport address comes into play. ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Thursday, March 01, 2012 7:45 AM To: Kamran Raza Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: Firstly, I don't agree that LSR Id be made IPv6 (address) based and/or rout= e-able; LSR Id, as defined in the base spec, is just a 4 octet unique id an= d need not be routable, though most implementations currently populate it w= ith /32 loopback address. Let's not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in t= he networks I operate it is *always* routable. From a simple troubleshootin= g PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, b) look at a routing table for the existence of a /32 (4-octet) LSR-ID b) use traceroute and/or a routing table to learn the _topological_ locatio= n of the /32 (4-octet) LSR-ID in the network ... In summary, there is a tremendous amount of operational value in the 4-Byte= LSR-ID actually be announced/routed in a network's IGP -- let us not under= estimate that. All I'm saying is, let's not go out of our way to try to mak= e a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical r= easons. -shane Secondly, If there is a need to define new "LDP Identifier" in order to est= ablish/maintain a separate session for IPv6 AF, this should be a protocol c= hange - i.e. we should bump up LDP protocol version in LDP PDU header for t= his, and possibly define new format for "LDP Identifier" in the context of = new LDP protocol version. My 2 cents. On 12-02-29 8:11 PM, "Vishwas Manral" > wrote: Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org ; Dutta, Pranjal K (Pranjal)= ; vishwas.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com ; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org " > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > . > > alcatel-lucent.com > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --_000_C584046466ED224CA92C1BC3313B963E09F00CAB5AINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

Hi Kamran,

      &n= bsp;            = ;   Further some comments below.

Thanks,

Pranjal

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kamran Raza
Sent: Thursday, March 01, 20= 12 10:20 AM
To: Dutta, Pranjal K (Pranjal); Shane Am= ante
Cc: Aissaoui, Mustapha (Mustapha); mpls@iet= f.org; Lizhong Jin
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 


>> Esp. for T-LDP h= ellos we would always like to match destination IP of hello packets to match 4 by= te LSR-ID,

Just a quick comment on the above statement:

Though for most cases, T-LDP Hellos are destined to remote LDP LSR-Id (i.e.= v4 loopback /32 in most impl), there are still some other cases where they do = not _always_ use LSR-Id as the T-LDP destination. One such case will be when T-= LDP session needs to be established/signaled with a remote PE that is discovere= d via BGP (AD).  In this case, the BGP discovered remote PE’s /32 address **may not** match remote PE’s LDP /32 address (LSR Id).

The same example can also be applied to BGP AD (for v6) and T-LDP v6.

=  

= [Pranjal] However this is implementation specific. In BGP-AD or Dynamic MS-PW it certainly adds value when BGP discovered remote PE address is same as 4 byt= e of LDP LSR-ID and thus LSR-ID is routable. Implementations can auto-create T-L= DP sessions using BGP remote address as 4 byte of LDP LSR-ID. It has tremendous operati= onal benefits since it serves the purpose for “auto-discovery” in su= ch applications and thus avoids another layer of mapping between BGP next-hops->ldp lsr-ids. There are running codes in field that is based o= n such provisioning models. RFC 5036 never says that 4 byte router ID MUST no= t be routable. If we apply the same with BGP-AD V6 and tomorrow if we have IPV6 = only transport networks then only way we can automate T-LDP session set-up is by using a 16 byte LSR-ID (v2) since we have to make L2VPN/MS-PW AFI/SAFI NLRI routable via IPV6. So I wouldn’t stick to existing theory or have a dogmatic view on RFC 5036.



Thx.
-- Kamran

On 12-03-01 1:08 PM, "Dutta, Pranjal K (Pranjal)" <pranjal.du= tta@alcatel-lucent.com> wrote:

Esp. for T-LDP hellos we would always = like to match destination IP of hello packets to match 4 byte LSR-ID, so same is applicable for IPV6.
TCP Transport address is an after affect – T-LDP hellos should be sen= t to the correct IPV6 address first before TCP transport address comes into play= .
 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]= On Behalf Of Shane Amante
Sent: Thursday, March 01, 20= 12 7:45 AM
To: Kamran Raza
Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

Kamran,



On Feb 29, 2012, at 9:39 PM, Kamr= an Raza wrote:


Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/o= r route-able; LSR Id, as defined in the base spec, is just a 4 octet unique i= d and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usa= ge.



Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to:

a) ping the /32 (4-octet) LSR-ID; or,

b) look at a routing table for the existence of a /32 (4-octe= t) LSR-ID

b) use traceroute and/or a routing table to learn the _topological_ location of the /32 (4-octet) LSR-ID in the network ...



In summary, there is a tremendous amount of operational value= in the 4-Byte LSR-ID actually be announced/routed in a network's IGP -- let us= not underestimate that. All I'm saying is, let's not go out of our way to try t= o make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely theoretical reasons.



-shane





Secondly, If there is a need to define new “LDP Identifier” in order to establish/maintain a separate session for IPv6 AF, this should be a protoco= l change — i.e. we should bump up LDP protocol version in LDP PDU heade= r for this, and possibly define new format for “LDP Identifier” i= n the context of new LDP protocol version.

My 2 cents.

On 12-02-29 8:11 PM, "Vishwas Manral" <vishwas.ietf@gmail.com <x-msg= ://1083/vishwas.ietf@gmail.com>= ; > wrote:



Hi Lizhong/ Pranjal/ Mustapha,

So the two main comments that have come after last call are:

1. Allow for separation of sessions along with the adjacency.
2. Allow for an IPv6 based LSR-ID.

The second could lead to changes required in both OSPF and IS-IS, as well because the new LSR ID would then need to be exchanged. We could treat it a= s an enhancement instead in my view. Do you agree?

Thanks,
Vishwas

On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal= K (Pranjal) <pranjal.dutta@al= catel-lucent.com <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> > wrote:


Yes, I support that too. There would be netwo= rk management issues with mapping of 4 byte LSR-ID to an IPV6 remote address.<= br> Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system.
 
Thanks,
Pranjal
 


From: Lizhong = Jin [mailto:lizhong.jin@zte.com.cn] <= br> Sent: Wednesday, February 29= , 2012 4:57 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org> ; <= st1:PersonName w:st=3D"on">Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ;

Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06


Hi Mustapha,
I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my first email.

Thanks
Lizhong


"Aissaoui, Mustapha (Mustapha)" <musta= pha.aissaoui@alcatel-lucent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> > wrote 2012/03/01 04:35:41:

> Hi Lizhong,
> I actually think that we would need to define a n= ew one which will
> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network.
>  
> Mustapha.
> From: mpls-boun= ces@ietf.org <x-msg://1083/mpls-bounces@ietf= .org> [mailto:mpls-bounces@ietf.org]= On Behalf Of
> Aissaoui, Mustapha (Musta= pha)
> Sent: Tuesday, February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gma= il.com>
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> Lizhong,
> the existing LSR-id will do the job and should be supported since
> the LSR-id need not be an IP address. Most implementations will
> actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addresses.
>  
> Mustapha.
>
> From: Lizhong Jin [mailto:li= zhong.jin@zte.com.cn]
> Sent: Monday, February 06, 2012 10:23 PM
> To: Dutta, Pranjal K (Pra= njal); vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ; ; Aissaoui,
> Mustapha (Mustapha)
> Cc: mpls@ietf.org <x-msg://1083/mpls@ietf.org>
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>
> Hi,
> I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP
> session in dual-stack network. LDP capability is per node
> capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it
> should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking.
>
> However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer
> new format of LSR-ID.
>
> Regards
> Lizhong
>
>
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21 +0530
> > From: "Dutta, Pranjal K (Pranjal)" <pranjal.du= tta@alcatel-lucent.com <x-msg://1083/pranja= l.dutta@alcatel-lucent.com> >
> > To: Vishwas Manral &= lt;vishwas.ietf@gmail.com <x-msg://1083/vishwas.ietf@gmail.com>= ; >
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> >    <mustapha.aissaoui@alcatel-lucent.com <x-msg://1083/mu= stapha.aissaoui@alcatel-lucent.com> >,   "mpls@ietf.org <x-m= sg://1083/mpls@ietf.org> "
> >    <mpls@ietf.org <x-msg://1083/mpls@ietf.org> >= ;
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >    <C5840= 46466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in <x-msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in&g= t; .
> > alcatel-lucent.com <http= ://alcatel-lucent.com>  <http://alcatel-lucent.com <http://alcatel-lucent.com/&g= t; > >
> >    
> > Content-Type: text/plain; charset=3D"us-ascii"
> >
> > I would rather for complete separation with multiple lsr-id becau= se
> > having separate link adjacencies does not really solved any probl= em.
> > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 a= nd IPV6.
> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
> > only decide whether such a link is to be programmed for IPV4 or I= PV6
> > egress traffic but I see it as overkill and unnecessary scalabili= ty impacts.
> >
> > Thanks,
> > Pranjal
> >
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.


_______________________________________________
mpls mailing list
mpls@ietf.org <x-msg://1083/mpls@ietf.org>
https://www.ietf.org= /mailman/listinfo/mpls


--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.com

--_000_C584046466ED224CA92C1BC3313B963E09F00CAB5AINBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Fri Mar 2 10:22:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88721F8639 for ; Fri, 2 Mar 2012 10:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.976 X-Spam-Level: X-Spam-Status: No, score=-8.976 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIpnsowi7P6l for ; Fri, 2 Mar 2012 10:22:42 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 153FA21F85D3 for ; Fri, 2 Mar 2012 10:22:37 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q22IMPPE016859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 12:22:32 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22IMPg3032189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 23:52:25 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 2 Mar 2012 23:52:25 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Vishwas Manral Date: Fri, 2 Mar 2012 23:52:22 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQ Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CAB6BINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 18:22:47 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CAB6BINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Viswas, We raised one more point earlier on the following clau= se in the draft. Section 6.2 As outlined in section 2.5.5 of RFC5036, this draft describes that if an LSR has a dual-stack interface, which is enabled with both IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 LDP Link Hellos and must separately maintain the Hello adjacency for IPv4 and IPv6 on that interface. This ensures successful labeled IPv4 and labeled IPv6 traffic forwarding on a dual-stacked interface, as well as successful LDP peering using the appropriate transport on a multi-access interface (even if there are IPv4-only, IPv6-only and dual-stack LSRs connected to that multi-access interface). The draft mandates that two separate hello adjacencies should be maintained= on dual-stack - one for IPV4 and another for IPV6. We don't see any benefi= t or technical reason of running two separate adjacencies. 1. First of all, doing so does not provide fate separation any way. Bo= th IPV4 and IPV6 fecs are still exchanged over same LDP sessions. 2. This clause mandates that a transit network that is carrying IPV6 L= SPs must provision IPv6 interfaces. It is not mandatory that the transport= network itself be IPV6 in order to carry IPV6 traffic over its tunnels. Th= is is a very narrow interpretation of section 2.5.5 in RFC 5036. It's not = necessary that an IPV6 FEC should be resolved by an IPV6 only route next-ho= p. The hello adjacency can still be over an IPV4 link and IPV6 prefix can s= till be resolved by an IPV4 route next-hop. It's not necessary that source = of hellos be IPv6 or transport address of TCP session be ipv6. 3. This clause has unnecessary scalability implications. We do run ver= y large number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls = or similar deployments. This clause requires to run 20K hello adjacencies w= hich has scalability implications. On theory there may not much difference = between 10K and 20K but in real implementations there is. If we allow separ= ation of sessions for fate separation of IPV4 and IPV6 then it would become= 40K adjacencies. We can limit to only one hello adjacency per interface yet address the dual= stack issue. A graceful solution is to come up with a notion of LDP adjace= ncy specific capabilities (similar to LDP capabilities that applies to enti= re sessions) that would benefit multiple purposes. For example, we have mul= tiple ECMP Links between neighboring LSRs A and B as shows below. +----------------L1------------------+ | = | A ----------------L2----------------- B | = | +----------------L3------------------+ The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe= r IPV4 OR ipv6 addresses but not both. Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3= are IPv6 capable. Then hellos exchanged over link would advertise capabilities as below: L1 would carry capabilities - Ipv4 + Mcast L2 would carry capabilities - ipv4 + ipv6 + Mcast L3 would carry capabilities - ipv4 + ipv6 >From an implementer/system designer's point of view I would think single he= llo adjacency with per adjacency capabilities would be right approach. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 5:11 PM To: Dutta, Pranjal K (Pranjal) Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwa= s.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org" > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > > alcatel-lucent.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. --_000_C584046466ED224CA92C1BC3313B963E09F00CAB6BINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Viswas,

      &n= bsp;            = ;  We raised one more point earlier on the following clause in the draft.=

 

Section 6.2 <= /p>

 

&=
nbsp;  As outlined in section 2.5.5 of RFC5036, this draft describes t=
hat
  =
 if an LSR has a dual-stack interface, which is enabled with both
  =
 IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and<=
/o:p>
  =
 IPv6 LDP Link Hellos and must separately maintain the Hello
  =
 adjacency for IPv4 and IPv6 on that interface.
 <=
/o:p>
  =
   This ensures successful labeled IPv4 and labeled IPv6 traffic<=
o:p>
  =
   forwarding on a dual-stacked interface, as well as successful =
LDP
  =
   peering using the appropriate transport on a multi-access=

  =
   interface (even if there are IPv4-only, IPv6-only and dual-sta=
ck
  =
   LSRs connected to that multi-access interface).
 <=
/o:p>
 <=
/o:p>
The draft mandates that two separate hello adjacencies should b=
e maintained on dual-stack – one for IPV4 and another for IPV6. We do=
n’t see any benefit or technical reason of running two separate adjac=
encies.  
 
1.      Firs=
t of all, doing so does not provide fate separation any way. Both IPV4 and =
IPV6 fecs are still exchanged over same LDP sessions. 
 
2.      This=
 clause mandates that a transit network that=
 is carrying IPV6 LSPs must provision IPv6 interfaces.  It is not mand=
atory that the transport network itself be IPV6 in order to carry IPV6 traf=
fic over its tunnels. This is a very narrow interpretation of section 2.5.5=
 in  RFC 5036. It’s not necessary that an IPV6 FEC should be res=
olved by an IPV6 only route next-hop. The hello adjacency can still be over=
 an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-h=
op. It’s not necessary that source of hellos be IPv6 or transport add=
ress of TCP session be ipv6.
 
3.      This=
 clause has unnecessary scalability implications. We do run very large numb=
er of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar d=
eployments. This clause requires to run 20K hello adjacencies which has sca=
lability implications. On theory there may not much difference between 10K =
and 20K but in real implementations there is. If we allow separation of ses=
sions for fate separation of IPV4 and IPV6 then it would become 40K adjacen=
cies.
 
=
We can limit to only one hello adjacency per interface yet address the dual=
 stack issue. A graceful solution is to come up with a notion of LDP adjace=
ncy specific capabilities (similar to LDP capabilities that applies to enti=
re sessions) that would benefit multiple purposes. For example, we have mul=
tiple ECMP Links between neighboring LSRs A and B as shows below.
 
=
            &nb=
sp;            =
          +----------------L1-=
-----------------+
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
           A ------------=
----L2----------------- B
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
            +-------=
---------L3------------------+
 
=
The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe=
r IPV4 OR ipv6 addresses but not both.
<=
font
size=3D2 color=3Dnavy face=3DArial> 
=
Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3=
 are IPv6 capable. 
 
=
Then hellos exchanged over link would advertise capabilities as below:=

 
L1 would carry capa=
bilities – Ipv4 + Mcast
      L2 would carry capabilities R=
11; ipv4 + ipv6 + Mcast
      L3 would carry capabilities R=
11; ipv4 + ipv6 
 
=
 
From an implementer/system designer’s point of view I wou=
ld think single hello adjacency with per adjacency capabilities would be ri=
ght approach. 
 
=
Thanks,
Pranjal 



 















From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=
 

Sent: Wednesday, February 29=
, 2012
5:11 PM

To: Dutta,
 Pranjal K (Pranjal)

Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org

Subject: Re: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06






 



Hi Lizhong/ Pranj=
al/
Mustapha,



So the two main comments that have come after last call are:



1. Allow for separation of sessions along with the adjacency.

2. Allow for an IPv6 based LSR-ID.



The second could lead to changes required in both OSPF and IS-IS, as well
because the new LSR ID would then need to be exchanged. We could treat it a=
s an
enhancement instead in my view. Do you agree?



Thanks,

Vishwas






On Wed, Feb 29, 2012 at 5:03 PM, Dutta,
 Pranjal K (Pranjal) <pranjal.dutta@alcatel-luce=
nt.com>
wrote:









Yes, I support that too. There would be network management issu=
es
with mapping of 4 byte LSR-ID to an IPV6 remote address.=




Most of the implementations I know off usually maps 4 byte of t=
he
LSR-ID with a local ipv4 interface address in the system.



 



Thanks,



Pranjal



 















From: Lizhong Jin [mailto:lizhong.jin@zte.co=
m.cn]


Sent: Wednesday, February 29=
, 2012
4:57 PM

To: Aissaoui,
 Mustapha (Mustapha)

Cc: mpls@ietf.org; Dutta, Pra=
njal K
(Pranjal); vish=
was.ietf@gmail.com








Subject: RE: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06









 



&nb=
sp;









Hi Mustapha, 

I
agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed o=
ut
in my first email. 



Thanks


Lizhong


 




"Aissaoui, Mustapha (Mustapha)" <must=
apha.aissaoui@alcatel-lucent.com>
wrote 2012/03/01 04:35:41:



> Hi Lizhong, 

> I
actually think that we would need to define a new one which will 

> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id 
> value to an IPv6 loopback interface on each router in the network.


>
  

>
Mustapha. 

>
From: mpls-bounc=
es@ietf.org
[mailto:mpls-bou=
nces@ietf.org]
On Behalf Of 

> Aissaoui, Mustapha (Musta=
pha)

> Sent: Tuesday, February 07, 2012 10:12 AM

> To: Lizhong Jin; Dutta, Pranjal K
(Pranjal); vish=
was.ietf@gmail.com

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



>
Lizhong, 

>
the existing LSR-id will do the job and should be supported since 

> the LSR-id need not be an IP address. Most implementations will 

> actually populate the field with a /32 address in IPv4 and thus If 
> necessary we could define a new format to allow the use of /128
IPv6addresses. 

>
  

>
Mustapha. 

> 

> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] 

> Sent: Monday, February 06, 2012 10:23 PM

> To: Dutta, Pranjal K (Pra=
njal);
vishwas.ietf@gm=
ail.com;
Aissaoui, 

> Mustapha (Mustapha)

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



> 

> Hi, 

> I wonder if it is feasible to use LDP capability to advertise IPv6 
> FEC without IPv6 adjacency, and only use one adjacency for LDP 

> session in dual-stack network. LDP capability is per node 

> capability, not per interface capability. But for LDP to choose the 
> correct downstream session and output interface for each FEC, it 

> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking. 

> 

> However, IMO, it is valuable to allow two independent LDP sessions 
> for IPv4 and IPv6 as an option. Regarding the format definition in 
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer 

> new format of LSR-ID. 

> 

> Regards 

> Lizhong 

> 

> 

> >
----------------------------------------------------------------------

> > 

> > Message: 1

> > Date: Tue, 7 Feb 2012 05:28:21 +0530

> > From: "Dutta, Pranjal K
(Pranjal)" <pranjal.dutta@alcatel-lucent.com>

> > To: Vishwas Manral &=
lt;vishwas.ietf@gmail=
.com>

> > Cc: "Aissaoui, Mustapha
\(Mustapha\)"

> >    <mustapha.aissaoui@alcatel-lucent.com>,   &quo=
t;mpls@ietf.org"

> >    <mpls@ietf.org>

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> > Message-ID:

> >  
 <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.

> > alcatel-l=
ucent.com>

> >    

> > Content-Type: text/plain; charset=3D"us-ascii"

> > 

> > I would rather for complete separation with multiple lsr-id becau=
se 

> > having separate link adjacencies does not really solved any probl=
em.

> > Since hello adjacencies are associated with a link, still fate 
> > sharing would continue over the single ldp/tcp session for IPV4 a=
nd
IPV6.

> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
 

> > only decide whether such a link is to be programmed for IPV4 or I=
PV6

> > egress traffic but I see it as overkill and unnecessary scalabili=
ty
impacts.

> > 

> > Thanks,

> > Pranjal

> > 

>
--------------------------------------------------------

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 

> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.

> This email and any files transmitted with it are confidential and 

> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 

> notify the originator of the message. Any views expressed in this 

> message are those of the individual sender.

> This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.


















 
--_000_C584046466ED224CA92C1BC3313B963E09F00CAB6BINBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Fri Mar 2 11:26:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121021E803D for ; Fri, 2 Mar 2012 11:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.03 X-Spam-Level: X-Spam-Status: No, score=-9.03 tagged_above=-999 required=5 tests=[AWL=0.969, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74AjtF4wmc4w for ; Fri, 2 Mar 2012 11:26:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98E21E8019 for ; Fri, 2 Mar 2012 11:26:38 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q22JQMNs019726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 13:26:25 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22JQLWQ001275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2012 00:56:21 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 3 Mar 2012 00:56:21 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante , "Kamran Raza (skraza)" Date: Sat, 3 Mar 2012 00:56:18 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3wlhF5m/Bl+03Qa6Nwwf+qeguTwAE25gAAAJjiyAABSASkAAMbLTwACEsFoA= Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C078BE3F8@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C078BE5CC@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C078BE5CC@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:26:40 -0000 Well, I am not sure if we are in sync. You have heard enough examples from = operators on this.=20 Thanks, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Thursday, March 01, 2012 7:37 PM To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Thanks for confirming. We are in sync. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Thursday, March 01, 2012 4:42 PM > To: Rajiv Asati (rajiva); Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > I never claimed that it is stated by RFC 5036! Did I? > It's what we "like" to do in most cases..whereas cases do exists where it is > not so (Kamran's last reply). >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Thursday, March 01, 2012 11:18 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante; Kamran Raza (skraza) > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > Esp. for T-LDP hellos we would always like to match destination IP of > hello > > packets to match 4 byte LSR-ID, so same is applicable for IPV6. >=20 > Really ! >=20 > Could you please point to the right RFC5036 section that says the above? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Thursday, March 01, 2012 1:09 PM > > To: Shane Amante; Kamran Raza (skraza) > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Esp. for T-LDP hellos we would always like to match destination IP of > hello > > packets to match 4 byte LSR-ID, so same is applicable for IPV6. > > > > TCP Transport address is an after affect - T-LDP hellos should be sent > to the > > correct IPV6 address first before TCP transport address comes into > play. > > > > > > > > ________________________________ > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Shane Amante > > Sent: Thursday, March 01, 2012 7:45 AM > > To: Kamran Raza > > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Kamran, > > > > > > > > On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > > > > Firstly, I don't agree that LSR Id be made IPv6 (address) based > and/or > > route-able; LSR Id, as defined in the base spec, is just a 4 octet > unique id and > > need not be routable, though most implementations currently populate > it > > with /32 loopback address. Let's not carry forward a wrong > notion/usage. > > > > > > > > Although, in theory, the LSR-ID "need not be routable", I can say that > in the > > networks I operate it is *always* routable. From a simple > troubleshooting > > PoV, it's extremely easy to: > > > > a) ping the /32 (4-octet) LSR-ID; or, > > > > b) look at a routing table for the existence of a /32 (4-octet) LSR-ID > > > > b) use traceroute and/or a routing table to learn the _topological_ > location of > > the /32 (4-octet) LSR-ID in the network ... > > > > > > > > In summary, there is a tremendous amount of operational value in the > 4- > > Byte LSR-ID actually be announced/routed in a network's IGP -- let us > not > > underestimate that. All I'm saying is, let's not go out of our way to > try to > > make a "new" 16-octet LSR-ID, in LDP, _non-routeable_ for purely > theoretical > > reasons. > > > > > > > > -shane > > > > > > > > > > > > > > > > Secondly, If there is a need to define new "LDP Identifier" in order > to > > establish/maintain a separate session for IPv6 AF, this should be a > protocol > > change - i.e. we should bump up LDP protocol version in LDP PDU header > > for this, and possibly define new format for "LDP Identifier" in the > context of > > new LDP protocol version. > > > > My 2 cents. > > > > On 12-02-29 8:11 PM, "Vishwas Manral" > msg://1083/vishwas.ietf@gmail.com> > wrote: > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > So the two main comments that have come after last call are: > > > > 1. Allow for separation of sessions along with the adjacency. > > 2. Allow for an IPv6 based LSR-ID. > > > > The second could lead to changes required in both OSPF and IS-IS, as > well > > because the new LSR ID would then need to be exchanged. We could treat > it > > as an enhancement instead in my view. Do you agree? > > > > Thanks, > > Vishwas > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > lucent.com> > wrote: > > > > > > > > Yes, I support that too. There would be network management issues with > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > Most of the implementations I know off usually maps 4 byte of the > LSR-ID > > with a local ipv4 interface address in the system. > > > > Thanks, > > Pranjal > > > > > > > > > > ________________________________ > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Wednesday, February 29, 2012 4:57 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org ; Dutta, Pranjal K > (Pranjal); > > vishwas.ietf@gmail.com > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out > > in my first email. > > > > Thanks > > Lizhong > > > > > > "Aissaoui, Mustapha (Mustapha)" > > wrote > 2012/03/01 > > 04:35:41: > > > > > Hi Lizhong, > > > I actually think that we would need to define a new one which will > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > > a all-IPv6 network will not be possible. I cannot see that operators > > > will start maintaining a mapping of some global non routable LSR-id > > > value to an IPv6 loopback interface on each router in the network. > > > > > > Mustapha. > > > From: mpls-bounces@ietf.org > > [mailto:mpls-bounces@ietf.org] On Behalf Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > msg://1083/vishwas.ietf@gmail.com> > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Lizhong, > > > the existing LSR-id will do the job and should be supported since > > > the LSR-id need not be an IP address. Most implementations will > > > actually populate the field with a /32 address in IPv4 and thus If > > > necessary we could define a new format to allow the use of /128 > > IPv6addresses. > > > > > > Mustapha. > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Monday, February 06, 2012 10:23 PM > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > msg://1083/vishwas.ietf@gmail.com> ; Aissaoui, > > > Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi, > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > session in dual-stack network. LDP capability is per node > > > capability, not per interface capability. But for LDP to choose the > > > correct downstream session and output interface for each FEC, it > > > should also check if the output interface is LDP enabled or not. The > > > link adjacency could be used to assist such kind of checking. > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > new format of LSR-ID. > > > > > > Regards > > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > From: "Dutta, Pranjal K (Pranjal)" > > msg://1083/pranjal.dutta@alcatel-lucent.com> > > > > > To: Vishwas Manral > msg://1083/vishwas.ietf@gmail.com> > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > msg://1083/mustapha.aissaoui@alcatel-lucent.com> >, "mpls@ietf.org > > msg://1083/mpls@ietf.org> " > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Message-ID: > > > > > > > > > msg://1083/C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCH > > MBSA3.in> . > > > > alcatel-lucent.com > lucent.com/> > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > I would rather for complete separation with multiple lsr-id > because > > > > having separate link adjacencies does not really solved any > problem. > > > > Since hello adjacencies are associated with a link, still fate > > > > sharing would continue over the single ldp/tcp session for IPV4 > and IPV6. > > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > > only decide whether such a link is to be programmed for IPV4 or > IPV6 > > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > > > > > ________________________________ > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > -- > > Syed Kamran Raza > > Technical Leader, SPRSG IOS-XR Routing (MPLS) > > Cisco Systems, Inc., > > Kanata, ON, K2K 3E8, Canada > > Ph: +1 (613) 254-4520 > > http://www.cisco.com > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > From kishoret@juniper.net Fri Mar 2 13:10:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18921E8010 for ; Fri, 2 Mar 2012 13:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxzfiCTxARzs for ; Fri, 2 Mar 2012 13:10:03 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8D421F84C4 for ; Fri, 2 Mar 2012 13:09:56 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT1E3JBgsPh+oYbqtUaQboj/DcpCIqy5f@postini.com; Fri, 02 Mar 2012 13:10:03 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Mar 2012 13:08:41 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 2 Mar 2012 16:08:41 -0500 From: Kishore Tiruveedhula To: "Dutta, Pranjal K (Pranjal)" , "Henderickx, Wim (Wim)" , "Rajiv Asati (rajiva)" , "mtinka@globaltransit.net" , "mpls@ietf.org" Date: Fri, 2 Mar 2012 16:08:39 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeAACD/nYA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 21:10:04 -0000 I think extending LSR ID to 16 bytes ( and changing the version) would be b= etter option which gives more flexibility and allows the multiple LDP sessi= ons. So that operators can choose whether to use 4 byte or 16 byte LSR ID f= or Ipv6 LDP session. Once LSR IDs are different, then there will be different adjacencies for Ip= v4 and Ipv6 and need to send separate hellos. If the operator chooses 4 byt= e LSR ID for both Ipv4 and IPv6, then only one LDP session will be establis= hed and both Ipv4 and IPv6 hellos can go in single message with IPv6 adj ca= pability in hello. This will help to avoid if any scaling issues. Thanks, Kishore >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Dutta, Pranjal K (Pranjal) >Sent: Friday, March 02, 2012 12:02 PM >To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); >mtinka@globaltransit.net >Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >Rajiv, > We shouldn't be ruling out the fact that there are some >differences in applications of LDP compared to OSPF or BGP. If we have >IPV6 only transport network tomorrow then applications like BGP-AD, >Dynamic MS-PW etc has to advertise L2VPN NLRI/MS-PW NLRI etc using an >IPV6 BGP next-hop and T-LDP has to auto-create targeted sessions. We >can't force to set-up another ip4 network just for some applications. It >won't be possible to map 4 byte ldp LSR-ID to the BGP IPV6 next-hop. I >am not saying that 16 byte LSR-ID is must for LDP IPV6. It's OPTIONAL >and adds lot of operational flexibility and better to add it now. > >Thanks, >Pranjal > >-----Original Message----- >From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >Henderickx, Wim (Wim) >Sent: Friday, March 02, 2012 12:41 AM >To: Rajiv Asati (rajiva); mtinka@globaltransit.net >Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >Rajiv, > >I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >should look at the future to get to IPv6 only networks and as such it >will be required. So we are now at a point where we should add this >option in all protocols. Since LDP for Ipv6 is open we need to add it >now. > >My 2 cents > >Cheers, >Wim > >-----Original Message----- >From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >Sent: vrijdag 2 maart 2012 8:08 >To: Henderickx, Wim (Wim); mtinka@globaltransit.net >Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > >Hi Wim, > >That's a reasonable point, but no such proposal has been made for other >protocols. In fact, IPv6 deployments have already accommodated 4-octet >router-id for routing protocols (which was also a departure from the >common practice in IPv4 realm). As Mark T and I discussed in the >previous email, the router-id consistency across protocols would be an >operational benefit. > >Focusing on the technicalities, Router ID is meant to ensure the >uniqueness of the router within the network while following the >protocol, so are we thinking that 4-octet is not good enough to ensure >the uniqueness? If so, then it would be worth having that discussion in >the Routing and Internet areas that have been focusing on IPv6 at large. > > >While I do agree to 128-bit future expandability as a benefit, the >benefit would be trivial (at the expense of message structure changes) >if we expanded it for the sake of it, but didn't address the root of the >problem. > >Do you think otherwise? > >Cheers, >Rajiv > >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >> Sent: Friday, March 02, 2012 1:42 AM >> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >lizhong.jin@zte.com.cn >> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Rajiv, I believe we need to provide both options to ensure both are >possible. >> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >it in the >> future. >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >Of >> Rajiv Asati (rajiva) >> Sent: vrijdag 2 maart 2012 7:39 >> To: mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Hi Mark, >> >> Well said. >> >> I take that we are in agreement wrt 4-octet entity for LDP router-id >in >> the context of IPv6, as specified. >> >> Cheers, >> Rajiv >> >> > -----Original Message----- >> > From: Mark Tinka [mailto:mtinka@globaltransit.net] >> > Sent: Friday, March 02, 2012 1:31 AM >> > To: Rajiv Asati (rajiva) >> > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >> lizhong.jin@zte.com.cn; >> > vishwas.ietf@gmail.com >> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> > >> > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >> > wrote: >> > >> > > In the past, implementations provided the router-id CLI for any >> > > interface IPv4 address to be chosen as router-id for various >> > > protocols including LDP. >> > >> > > However, many implementations already evolved the CLI to not even >> > > give an "interface" IP address for router-id, to accommodate IPv6. >> > > Almost all deployed networks already accommodated that. >> > >> > We do operate some implementations today that "still" allow you to >> > specify the Router-ID for various protocols as an independent 32-bit >> > integer (only), and also allow you to define the LSR-ID for LDP as >> > an interface (only). This is current, shipping 2012 code. >> > >> > So both scenarios you mention above are still much in play today. >> > Whether operators are using them or not (I know we >> > are) is another matter entirely. >> > >> > > Now that LDP is being enhanced to use IPv6, implementations could >> > > evolve LDP router-id as well to accommodate IPv6. This would make >> > > LDP router-id to be consistent with other protocols delving with >> > > IPv6. And this can certainly be operationally beneficial from IPv6 >> > > POV. >> > >> > Agree. >> > >> > > In fact, one of the implementations allow the router-id to be >> > > configured just once and let all protocols just use it, if they >> > > wanted. >> > >> > Yes, we operate some implementations that use this method too. It's >> > quite elegant, in that you configure once and forget. Other >> > implementations that are more structured means operators could >> > easily forget to specify the Router-ID for a particular protocol, >> > for better or worse. >> > >> > Cheers, >> > >> > Mark. >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From mtinka@globaltransit.net Fri Mar 2 21:09:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBF21F8602 for ; Fri, 2 Mar 2012 21:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lAokb+PpE0f for ; Fri, 2 Mar 2012 21:09:46 -0800 (PST) Received: from the-host.globaltransit.net (the-net-11.globaltransit.net [203.223.132.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9466821F8601 for ; Fri, 2 Mar 2012 21:09:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3hDs-0002Oy-3n; Sat, 03 Mar 2012 13:09:36 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Sat, 3 Mar 2012 13:09:30 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10088597.GR76foM1dC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203031309.34330.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 05:09:47 -0000 --nextPart10088597.GR76foM1dC Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 (Pranjal) wrote: > >From an implementer/system designer's point of view I > >would think single hello adjacency with per adjacency > >capabilities would be right approach. Pranjal, I appreciate that from a vendor perspective,=20 implementing it this way would make sense for large scale=20 deployments. However, for some operators who may be using BGP or RSVP to=20 signal or nest a large number of LSP's, we would like to=20 have the option of choosing a discrete separation of IPv4=20 and IPv6 adjacencies for LDP. If there are operators who aren't going to be looking at=20 scaling that many LSP's anytime in their network, they might=20 still prefer to eliminate adjacency fate-sharing. I would propose that vendors implement both options,=20 allowing operators to choose (via CLI) which method they=20 would like to deploy in the field. There are many operators=20 out there who maintain separate BGP transport and policy=20 sessions for IPv4 and IPv6 AF's to protect themselves=20 against the problems fate-sharing could bring. This is why=20 some of us prefer to make our lives harder by going native,=20 dual-stack rather than 6PE :-). So while I won't disagree with your opinion on using a=20 single adjacency for both AF's for scaling purposes, I would=20 certainly like to have the option to choose which method=20 suits me best in the wild. Mark. --nextPart10088597.GR76foM1dC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUaeOAAoJEGcZuYTeKm+GPJMQAKc/5YaBfPTb5LWsXRtBWCW7 F5ZtmbKnaxMADKbNI6UKf+4u8vjf4ZFpD/vX1NtObEk+6+VL7MrDJwLO8eSuSZlK 0mPvgaSecaEpCpF79xMFvcWHiTLFqm6HphmNB4f/XqNvrTKiQI/CHMAB+y4GYA0m FFHcCLM4dcszS6JcCIs3sYX6Est1yYvTvrsVIaSrulOUF839pwcirwpCaPxAOjEU gVVXMGSV/GFNdmA+lFtYVQ3SNh401jn+ddAddq7r89UpDhAmIeUt+spyezT6UOeL UTCyDVGAYYvj2Ul7OsF1Voxmmay4DkvDYmeJ6zwanaZt3H4HcHpaLa23AC6TYwWC qUNA1bop6wsuTkE5g5wabMlkh0jXEo6j9OtugNXbfvjICBT8pBXxVwrwJM/1wtu5 uEHwBQ45+2ta7T2ibYb+bLJ9sUgjumjBWiQtvvwg8JAxvjfj+3ulVShuEK46Sivw c/BdKVQN1p0pF7+iUOfrq44mh5myHmKgfra/8hhYs94pI0b9zMIrXIYgNBYbQLeT RiyPFJ8m6Nkjl1JsoEFTnEu/LiQfDd91WZyrvWbtXcqRiYifjhLu3DXz4ardM59n VUdATrz2wMh9OkQdLFU2/kQX6KxFujoKGyrzKW8KqWuPs26JukDplHAsUo1yY3KL rDsctKIbeuu76KfKrD+c =NBGH -----END PGP SIGNATURE----- --nextPart10088597.GR76foM1dC-- From mtinka@globaltransit.net Fri Mar 2 21:10:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2513E21E8044 for ; Fri, 2 Mar 2012 21:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK6jiKdSM4NW for ; Fri, 2 Mar 2012 21:10:03 -0800 (PST) Received: from the-host.globaltransit.net (the-net-11.globaltransit.net [203.223.132.218]) by ietfa.amsl.com (Postfix) with ESMTP id D900321F8605 for ; Fri, 2 Mar 2012 21:10:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S3hDx-0002PF-PY; Sat, 03 Mar 2012 13:09:41 +0800 From: Mark Tinka Organization: Global Transit International To: Kishore Tiruveedhula Date: Sat, 3 Mar 2012 13:09:40 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1412376.qiap9dPT8I"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203031309.40384.mtinka@globaltransit.net> Cc: "mpls@ietf.org" , "lizhong.jin@zte.com.cn" , "Aissaoui, Mustapha \(Mustapha\)" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 05:10:04 -0000 --nextPart1412376.qiap9dPT8I Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday, March 03, 2012 05:08:39 AM Kishore Tiruveedhula=20 wrote: > I think extending LSR ID to 16 bytes ( and changing the > version) would be better option which gives more > flexibility and allows the multiple LDP sessions. So > that operators can choose whether to use 4 byte or 16 > byte LSR ID for Ipv6 LDP session. I don't see how this would hurt, as it maintains backward=20 compatibility for those who are for 32-bit LSR-ID's, and=20 gives 128-bit LSR-ID fans future flexbility. Win-win. > Once LSR IDs are different, then there will be different > adjacencies for Ipv4 and Ipv6 and need to send separate > hellos. If the operator chooses 4 byte LSR ID for both > Ipv4 and IPv6, then only one LDP session will be > established and both Ipv4 and IPv6 hellos can go in > single message with IPv6 adj capability in hello. This > will help to avoid if any scaling issues. This works for vendors who specify a global Router-ID that=20 various (routing) protocols reference when starting up. There are other vendors who specify the Router-ID (LSR-ID,=20 in the case of LDP, to be pedantic) via an interface in=20 their CLI. Special care would need to be taken in this=20 scenario, as it would imply that if the reference interface=20 (typically, the Loopback interface) is dual-stack, then 2x=20 adjacencies would be formed, one per AF (on the basis of=20 common sense, of course, as not doing this would indicate=20 that LDPv6 code is ignoring the presence of an IPv6 address=20 on the reference interface, which would be quite odd).=20 However, it is possible a particular operator may prefer=20 adjacency consolidation. Yes, I understand this is vendor- implementation-specific, but I thought I'd mention it now so=20 that operators have this flexibility the moment LDPv6 code=20 starts shipping, rather than wait for a future upgrade which=20 provides knobs for adjacency separation or consolidation. I suppose we can leave it up to vendors which option is the=20 default in their implementation, although my personal=20 preference would be for adjacency separation :-). Cheers, Mark. --nextPart1412376.qiap9dPT8I Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPUaeUAAoJEGcZuYTeKm+GSSQP/iQ+sB1T7xmN3XWVFZvSgJSr oI+jLpTEAnDhtxJ9dDj7wqWxUDEs9AtreVnKw2+id5ZTcFayEuqZ7YNk+6S7504q gjgaHoCqs2vEmdghHDXkJJ0YFpSRrz6YMQUQNC/j299hd2GETQBQVTo+gyZgFFOI z35G+ipq3FaCunkMANq8g423WO2vzK2RAKbD62dPyMTP0KgEgpECcFKVWpifEni5 pAzYp+25RwvhQbDCa65vkflBiie99ycSSA5ujB2askKWtgks06aQ/vwXqLlJ54xJ 8tw994Tt3L3TE/xKY2Y0XKZcpi74XcXQAFhU2PSS+0z9iqyqp0sAe0gRX5fiFlCu UlxmKEzxZat/RS5ymEDLWEePqQ49Rd5WJTIg5Cirpl/ZIecPUvSOFLLsTby7YpVg dmEyQMHF6/yql05nCyJsuEb0rsPCHDUPXb3uZ6+Va4BBaCNyi/FuT9I9xKCKbFD2 +DefdeVgj2D4Qw8Ux69BOS7lHJ6rLrOnICSPdKLq+FstT2uywspuUR6PqFzt8cCR nQ1CknbhIktTglfl52c7XP5zluwOUtDlR8cUS7Fm6m/oYRWaI9dCoMe+WIorOEYY nctYShtmdjQT+6wSnzJwLNwufsNpe9Kd54h5McIuUdBUPrqoIxD0yqWflBzLCoYN CPxw9CmeZ5EGtLbq1fFp =tSmv -----END PGP SIGNATURE----- --nextPart1412376.qiap9dPT8I-- From shane@castlepoint.net Fri Mar 2 23:34:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770421F851D for ; Fri, 2 Mar 2012 23:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA-eacSTBM0m for ; Fri, 2 Mar 2012 23:34:41 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id CBAEB21F851E for ; Fri, 2 Mar 2012 23:34:41 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 0DF1F26806D; Sat, 3 Mar 2012 00:34:41 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sat, 03 Mar 2012 00:34:40 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=51321; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <201203031309.34330.mtinka@globaltransit.net> Date: Sat, 3 Mar 2012 00:34:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net> References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> To: mtinka@globaltransit.net X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 07:34:42 -0000 Mark, I completely agree with all of your comments below. I too would = (strongly) prefer the option to allow operators to choose (via CLI) = whether to: a) use separate transport to ensure there is no fate-sharing of IPv4 + = IPv6; or, b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, = other AF's) on a single session, for scale reasons. -shane On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 > (Pranjal) wrote: >=20 >>> =46rom an implementer/system designer's point of view I >>> would think single hello adjacency with per adjacency >>> capabilities would be right approach. >=20 > Pranjal, I appreciate that from a vendor perspective,=20 > implementing it this way would make sense for large scale=20 > deployments. >=20 > However, for some operators who may be using BGP or RSVP to=20 > signal or nest a large number of LSP's, we would like to=20 > have the option of choosing a discrete separation of IPv4=20 > and IPv6 adjacencies for LDP. >=20 > If there are operators who aren't going to be looking at=20 > scaling that many LSP's anytime in their network, they might=20 > still prefer to eliminate adjacency fate-sharing. >=20 > I would propose that vendors implement both options,=20 > allowing operators to choose (via CLI) which method they=20 > would like to deploy in the field. There are many operators=20 > out there who maintain separate BGP transport and policy=20 > sessions for IPv4 and IPv6 AF's to protect themselves=20 > against the problems fate-sharing could bring. This is why=20 > some of us prefer to make our lives harder by going native,=20 > dual-stack rather than 6PE :-). >=20 > So while I won't disagree with your opinion on using a=20 > single adjacency for both AF's for scaling purposes, I would=20 > certainly like to have the option to choose which method=20 > suits me best in the wild. >=20 > Mark. From ietfc@btconnect.com Sat Mar 3 04:42:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0921F86DD for ; Sat, 3 Mar 2012 04:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.741 X-Spam-Level: X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL1RrpJXjB34 for ; Sat, 3 Mar 2012 04:42:55 -0800 (PST) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 2617F21F86DC for ; Sat, 3 Mar 2012 04:42:54 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2beaomr09.btconnect.com with SMTP id GND06390; Sat, 03 Mar 2012 12:42:42 +0000 (GMT) Message-ID: <00f701ccf932$ab605540$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Aissaoui, Mustapha \(Mustapha\)" , "Rajiv Asati \(rajiva\)" , , References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116F3@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Sat, 3 Mar 2012 12:42:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F5211C1.00FC, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2012.3.3.115419:17:9.975, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4F5211C3.0014,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 12:42:56 -0000 ----- Original Message ----- From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" ; ; Cc: Sent: Friday, March 02, 2012 3:42 PM > Rajiv, > From a pure prootocol perspective, you are correct. > > This is however a practical matter. Many deployments today have the router-id default to a well known system loopback interface IPv4 address. This means that routing protocols, MPLS signaling protocols,and OAM protocols can operate directly using this address. Stepping back, a, if not the, major problem of the Internet, is getting people off the somewhat overloaded IPv4. And one of the reasons it is so difficult is because that 32 bit dotted decimal has been used for system identifier, system address, system locator etc etc - it is called overloading and is a surefire way of making migration expensive, bordering on the impossible (see the RRG archives for this lengthy discussion:-(. So using a routable address as a router identifier was always short sighted and dumb. Using a separate namespace and a mapping system (ever heard of DNS or /etc/hosts/?) is so obviously the right way to go that ... well if you don't get the message ... The ancilliary point is that dotted decimal makes a 32 bit number almost user friendly. Anyone who thinks that a generic 128 bit number is, well ..... see above. I realise that if you have complete control over your address structure you can choose a structure that reduces the number of characters to be comparable to dotted decimal, in general you cannot, and even when you can, you have to get those pesky double colons right - and as has been pointed already, every one of those colons is shift on most keyboards, while those dots are not shift on most keyboards. So please, do not repeat the mistake of the IETF all those years ago, which so haunts us so today. BGP and OSPF have seen the light, with identifiers for IPv6, and I respect their wisdom. Tom Petch Certainly with BGP, the operator can configure a neighbour address which is IPv6 and is different from the router-id but that router-id is already required for the operation of IPv4 BGP neighbours and other protocols and such this is manageable. As we go into all IPv6 deployments, we need to have means for deployments to have a similar default IPv6 system address. It is hardly justifiable at that point in time to configure two different addresses to get the prorotcols working by default. We may as well make this change now as part of allowing separate LDP sessions for IPv4 and IPv6 or we will create yet a third LDP version number in the next few years. > > Regards, > Mustapha. > From lizhong.jin@zte.com.cn Sun Mar 4 22:39:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B86D11E8085 for ; Sun, 4 Mar 2012 22:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.305 X-Spam-Level: X-Spam-Status: No, score=-100.305 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrwJKE2-MLiY for ; Sun, 4 Mar 2012 22:39:16 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 045B411E8079 for ; Sun, 4 Mar 2012 22:39:15 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Mon, 5 Mar 2012 14:07:50 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 35739.6407659339; Mon, 5 Mar 2012 14:39:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q256cv5l068406; Mon, 5 Mar 2012 14:38:57 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: "Dutta, Pranjal K (Pranjal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Mon, 5 Mar 2012 14:38:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-05 14:38:59, Serialize complete at 2012-03-05 14:39:00, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-05 14:39:00 Content-Type: multipart/alternative; boundary="=_alternative 00248740482579B8_=" X-MAIL: mse02.zte.com.cn q256cv5l068406 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 06:39:18 -0000 This is a multipart message in MIME format. --=_alternative 00248740482579B8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VGhlIHR3byBzZXBhcmF0ZSBoZWxsbyBhZGphY2VuY3kgaXNzdWUgaXMgY2F1c2VkIGJ5IHRoZSBj dXJyZW50IGRlZmluZWQgDQpMRFAgY2FwYWJpbGl0eSBwZXIgbm9kZSBpbiBSRkM1NTYxLiBBY3R1 YWxseSwgY2FwYWJpbGl0eSBwZXIgaGVsbG8gDQphZGphY2VuY3kgaXMgYSBnZW5lcmFsIHJlcXVp cmVtZW50IGFuZCBub3Qgc3BlY2lmaWMgZm9yIExEUCBJUHY2LiBXZSANCnNob3VsZCB1cGRhdGUg UkZDNTU2MSBmaXJzdCwgc28gYXMgdG8gaGF2ZSBvbmUgaGVsbG8gYWRqYWNlbmN5IGZvciANCmR1 YWwtc3RhY2sgaW50ZXJmYWNlLg0KDQpSZWdhcmRzDQpMaXpob25nDQoNCg0KIkR1dHRhLCBQcmFu amFsIEsgKFByYW5qYWwpIiA8cHJhbmphbC5kdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3Rl IA0KMjAxMi8wMy8wMyAwMjoyMjoyMjoNCg0KPiBIaSBWaXN3YXMsDQo+ICAgICAgICAgICAgICAg ICAgICAgIFdlIHJhaXNlZCBvbmUgbW9yZSBwb2ludCBlYXJsaWVyIG9uIHRoZSANCj4gZm9sbG93 aW5nIGNsYXVzZSBpbiB0aGUgZHJhZnQuDQo+IA0KPiBTZWN0aW9uIDYuMiANCj4gDQo+ICAgIEFz IG91dGxpbmVkIGluIHNlY3Rpb24gMi41LjUgb2YgUkZDNTAzNiwgdGhpcyBkcmFmdCBkZXNjcmli ZXMgdGhhdA0KPiAgICBpZiBhbiBMU1IgaGFzIGEgZHVhbC1zdGFjayBpbnRlcmZhY2UsIHdoaWNo IGlzIGVuYWJsZWQgd2l0aCBib3RoDQo+ICAgIElQdjQgYW5kIElQdjYgTERQLCB0aGVuIHRoZSBM U1IgbXVzdCBwZXJpb2RpY2FsbHkgc2VuZCBib3RoIElQdjQgYW5kDQo+ICAgIElQdjYgTERQIExp bmsgSGVsbG9zIGFuZCBtdXN0IHNlcGFyYXRlbHkgbWFpbnRhaW4gdGhlIEhlbGxvDQo+ICAgIGFk amFjZW5jeSBmb3IgSVB2NCBhbmQgSVB2NiBvbiB0aGF0IGludGVyZmFjZS4NCj4gDQo+ICAgICAg VGhpcyBlbnN1cmVzIHN1Y2Nlc3NmdWwgbGFiZWxlZCBJUHY0IGFuZCBsYWJlbGVkIElQdjYgdHJh ZmZpYw0KPiAgICAgIGZvcndhcmRpbmcgb24gYSBkdWFsLXN0YWNrZWQgaW50ZXJmYWNlLCBhcyB3 ZWxsIGFzIHN1Y2Nlc3NmdWwgTERQDQo+ICAgICAgcGVlcmluZyB1c2luZyB0aGUgYXBwcm9wcmlh dGUgdHJhbnNwb3J0IG9uIGEgbXVsdGktYWNjZXNzDQo+ICAgICAgaW50ZXJmYWNlIChldmVuIGlm IHRoZXJlIGFyZSBJUHY0LW9ubHksIElQdjYtb25seSBhbmQgZHVhbC1zdGFjaw0KPiAgICAgIExT UnMgY29ubmVjdGVkIHRvIHRoYXQgbXVsdGktYWNjZXNzIGludGVyZmFjZSkuDQo+IA0KPiANCj4g VGhlIGRyYWZ0IG1hbmRhdGVzIHRoYXQgdHdvIHNlcGFyYXRlIGhlbGxvIGFkamFjZW5jaWVzIHNo b3VsZCBiZSANCj4gbWFpbnRhaW5lZCBvbiBkdWFsLXN0YWNrIKhDIG9uZSBmb3IgSVBWNCBhbmQg YW5vdGhlciBmb3IgSVBWNi4gV2UgDQo+IGRvbqGvdCBzZWUgYW55IGJlbmVmaXQgb3IgdGVjaG5p Y2FsIHJlYXNvbiBvZiBydW5uaW5nIHR3byBzZXBhcmF0ZSANCj4gYWRqYWNlbmNpZXMuIA0KPiAN Cj4gMS4gICAgICBGaXJzdCBvZiBhbGwsIGRvaW5nIHNvIGRvZXMgbm90IHByb3ZpZGUgZmF0ZSBz ZXBhcmF0aW9uIGFueSANCj4gd2F5LiBCb3RoIElQVjQgYW5kIElQVjYgZmVjcyBhcmUgc3RpbGwg ZXhjaGFuZ2VkIG92ZXIgc2FtZSBMRFAgc2Vzc2lvbnMuIA0KDQo+IA0KPiAyLiAgICAgIFRoaXMg Y2xhdXNlIG1hbmRhdGVzIHRoYXQgYSB0cmFuc2l0IG5ldHdvcmsgdGhhdCBpcyBjYXJyeWluZw0K PiBJUFY2IExTUHMgbXVzdCBwcm92aXNpb24gSVB2NiBpbnRlcmZhY2VzLiAgSXQgaXMgbm90IG1h bmRhdG9yeSB0aGF0IA0KPiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgaXRzZWxmIGJlIElQVjYgaW4g b3JkZXIgdG8gY2FycnkgSVBWNiB0cmFmZmljIA0KPiBvdmVyIGl0cyB0dW5uZWxzLiBUaGlzIGlz IGEgdmVyeSBuYXJyb3cgaW50ZXJwcmV0YXRpb24gb2Ygc2VjdGlvbiAyLg0KPiA1LjUgaW4gIFJG QyA1MDM2LiBJdKGvcyBub3QgbmVjZXNzYXJ5IHRoYXQgYW4gSVBWNiBGRUMgc2hvdWxkIGJlIA0K PiByZXNvbHZlZCBieSBhbiBJUFY2IG9ubHkgcm91dGUgbmV4dC1ob3AuIFRoZSBoZWxsbyBhZGph Y2VuY3kgY2FuIA0KPiBzdGlsbCBiZSBvdmVyIGFuIElQVjQgbGluayBhbmQgSVBWNiBwcmVmaXgg Y2FuIHN0aWxsIGJlIHJlc29sdmVkIGJ5IA0KPiBhbiBJUFY0IHJvdXRlIG5leHQtaG9wLiBJdKGv cyBub3QgbmVjZXNzYXJ5IHRoYXQgc291cmNlIG9mIGhlbGxvcyBiZSANCj4gSVB2NiBvciB0cmFu c3BvcnQgYWRkcmVzcyBvZiBUQ1Agc2Vzc2lvbiBiZSBpcHY2Lg0KPiANCj4gMy4gICAgICBUaGlz IGNsYXVzZSBoYXMgdW5uZWNlc3Nhcnkgc2NhbGFiaWxpdHkgaW1wbGljYXRpb25zLiBXZSBkbyAN Cj4gcnVuIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIExEUCBhZGphY2VuY2llcy9zZXNzaW9ucyAoZS5n IDEwSykgaW4gDQo+IG1vYmlsaXR5IGJhY2toYXVscyBvciBzaW1pbGFyIGRlcGxveW1lbnRzLiBU aGlzIGNsYXVzZSByZXF1aXJlcyB0byANCj4gcnVuIDIwSyBoZWxsbyBhZGphY2VuY2llcyB3aGlj aCBoYXMgc2NhbGFiaWxpdHkgaW1wbGljYXRpb25zLiBPbiANCj4gdGhlb3J5IHRoZXJlIG1heSBu b3QgbXVjaCBkaWZmZXJlbmNlIGJldHdlZW4gMTBLIGFuZCAyMEsgYnV0IGluIHJlYWwNCj4gaW1w bGVtZW50YXRpb25zIHRoZXJlIGlzLiBJZiB3ZSBhbGxvdyBzZXBhcmF0aW9uIG9mIHNlc3Npb25z IGZvciANCj4gZmF0ZSBzZXBhcmF0aW9uIG9mIElQVjQgYW5kIElQVjYgdGhlbiBpdCB3b3VsZCBi ZWNvbWUgNDBLIGFkamFjZW5jaWVzLg0KPiANCj4gV2UgY2FuIGxpbWl0IHRvIG9ubHkgb25lIGhl bGxvIGFkamFjZW5jeSBwZXIgaW50ZXJmYWNlIHlldCBhZGRyZXNzIA0KPiB0aGUgZHVhbCBzdGFj ayBpc3N1ZS4gQSBncmFjZWZ1bCBzb2x1dGlvbiBpcyB0byBjb21lIHVwIHdpdGggYSANCj4gbm90 aW9uIG9mIExEUCBhZGphY2VuY3kgc3BlY2lmaWMgY2FwYWJpbGl0aWVzIChzaW1pbGFyIHRvIExE UCANCj4gY2FwYWJpbGl0aWVzIHRoYXQgYXBwbGllcyB0byBlbnRpcmUgc2Vzc2lvbnMpIHRoYXQg d291bGQgYmVuZWZpdCANCj4gbXVsdGlwbGUgcHVycG9zZXMuIEZvciBleGFtcGxlLCB3ZSBoYXZl IG11bHRpcGxlIEVDTVAgTGlua3MgYmV0d2VlbiANCj4gbmVpZ2hib3JpbmcgTFNScyBBIGFuZCBC IGFzIHNob3dzIGJlbG93Lg0KPiANCj4gKy0tLS0tLS0tLS0tLS0tLS1MMS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEgLS0tLS0tLS0tLS0tLS0tLUwyLS0tLS0t LS0tLS0tLS0tLS0gDQpCDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICB8DQo+ICstLS0tLS0tLS0tLS0tLS0tTDMtLS0tLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiBUaGUg aGVsbG8gYWRqYWNlbmNpZXMgb3ZlciBMMSwgTDIgYW5kIEwzIGFyZSBJUDQgaW50ZXJmYWNlcyBh cmUgDQo+IHVzaW5nIGVpdGhlciBJUFY0IE9SIGlwdjYgYWRkcmVzc2VzIGJ1dCBub3QgYm90aC4N Cj4gDQo+IExpbmsgTDEsIEwyIGFyZSBtdWx0aWNhc3QgY2FwYWJsZSAoUDJNUCBvciBNUDJNUF9V UCBvciBNUDJNUF9ETikuIEwyDQo+IGFuZCBMMyBhcmUgSVB2NiBjYXBhYmxlLiANCj4gDQo+IFRo ZW4gaGVsbG9zIGV4Y2hhbmdlZCBvdmVyIGxpbmsgd291bGQgYWR2ZXJ0aXNlIGNhcGFiaWxpdGll cyBhcyBiZWxvdzoNCj4gDQo+IEwxIHdvdWxkIGNhcnJ5IGNhcGFiaWxpdGllcyCoQyBJcHY0ICsg TWNhc3QNCj4gICAgICAgTDIgd291bGQgY2FycnkgY2FwYWJpbGl0aWVzIKhDIGlwdjQgKyBpcHY2 ICsgTWNhc3QNCj4gICAgICAgTDMgd291bGQgY2FycnkgY2FwYWJpbGl0aWVzIKhDIGlwdjQgKyBp cHY2IA0KPiANCj4gDQo+IEZyb20gYW4gaW1wbGVtZW50ZXIvc3lzdGVtIGRlc2lnbmVyoa9zIHBv aW50IG9mIHZpZXcgSSB3b3VsZCB0aGluayANCj4gc2luZ2xlIGhlbGxvIGFkamFjZW5jeSB3aXRo IHBlciBhZGphY2VuY3kgY2FwYWJpbGl0aWVzIHdvdWxkIGJlIA0KPiByaWdodCBhcHByb2FjaC4g DQo+IA0KPiBUaGFua3MsDQo+IFByYW5qYWwgDQo+IA0KPiANCj4gRnJvbTogVmlzaHdhcyBNYW5y YWwgW21haWx0bzp2aXNod2FzLmlldGZAZ21haWwuY29tXSANCj4gU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSAyOSwgMjAxMiA1OjExIFBNDQo+IFRvOiBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFs KQ0KPiBDYzogTGl6aG9uZyBKaW47IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBtcGxz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1t cGxzLWxkcC1pcHY2LTA2DQo+IA0KPiBIaSBMaXpob25nLyBQcmFuamFsLyBNdXN0YXBoYSwNCj4g DQo+IFNvIHRoZSB0d28gbWFpbiBjb21tZW50cyB0aGF0IGhhdmUgY29tZSBhZnRlciBsYXN0IGNh bGwgYXJlOg0KPiANCj4gMS4gQWxsb3cgZm9yIHNlcGFyYXRpb24gb2Ygc2Vzc2lvbnMgYWxvbmcg d2l0aCB0aGUgYWRqYWNlbmN5Lg0KPiAyLiBBbGxvdyBmb3IgYW4gSVB2NiBiYXNlZCBMU1ItSUQu DQo+IA0KPiBUaGUgc2Vjb25kIGNvdWxkIGxlYWQgdG8gY2hhbmdlcyByZXF1aXJlZCBpbiBib3Ro IE9TUEYgYW5kIElTLUlTLCBhcw0KPiB3ZWxsIGJlY2F1c2UgdGhlIG5ldyBMU1IgSUQgd291bGQg dGhlbiBuZWVkIHRvIGJlIGV4Y2hhbmdlZC4gV2UgDQo+IGNvdWxkIHRyZWF0IGl0IGFzIGFuIGVu aGFuY2VtZW50IGluc3RlYWQgaW4gbXkgdmlldy4gRG8geW91IGFncmVlPw0KPiANCj4gVGhhbmtz LA0KPiBWaXNod2FzDQo+IE9uIFdlZCwgRmViIDI5LCAyMDEyIGF0IDU6MDMgUE0sIER1dHRhLCBQ cmFuamFsIEsgKFByYW5qYWwpIDwNCj4gcHJhbmphbC5kdXR0YUBhbGNhdGVsLWx1Y2VudC5jb20+ IHdyb3RlOg0KPiBZZXMsIEkgc3VwcG9ydCB0aGF0IHRvby4gVGhlcmUgd291bGQgYmUgbmV0d29y ayBtYW5hZ2VtZW50IGlzc3VlcyANCj4gd2l0aCBtYXBwaW5nIG9mIDQgYnl0ZSBMU1ItSUQgdG8g YW4gSVBWNiByZW1vdGUgYWRkcmVzcy4NCj4gTW9zdCBvZiB0aGUgaW1wbGVtZW50YXRpb25zIEkg a25vdyBvZmYgdXN1YWxseSBtYXBzIDQgYnl0ZSBvZiB0aGUgDQo+IExTUi1JRCB3aXRoIGEgbG9j YWwgaXB2NCBpbnRlcmZhY2UgYWRkcmVzcyBpbiB0aGUgc3lzdGVtLg0KPiANCj4gVGhhbmtzLA0K PiBQcmFuamFsDQo+IA0KPiANCj4gRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmpp bkB6dGUuY29tLmNuXSANCj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOSwgMjAxMiA0OjU3 IFBNDQo+IFRvOiBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKQ0KPiBDYzogbXBsc0BpZXRm Lm9yZzsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7IHZpc2h3YXMuaWV0ZkBnbWFpbC5jb20N Cj4gDQo+IFN1YmplY3Q6IFJFOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1tcGxzLWxk cC1pcHY2LTA2DQo+IA0KPiANCj4gSGkgTXVzdGFwaGEsIA0KPiBJIGFncmVlLCBhbmQgSSBhbHNv IHByZWZlciB0byBkZWZpbmluZyBhIElQdjYgZm9ybWF0ZWQgTFNSLUlELCBhcyBJIA0KPiBwb2lu dGVkIG91dCBpbiBteSBmaXJzdCBlbWFpbC4gDQo+IA0KPiBUaGFua3MgDQo+IExpemhvbmcgDQo+ IA0KPiANCj4gIkFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpIiA8bXVzdGFwaGEuYWlzc2Fv dWlAYWxjYXRlbC1sdWNlbnQuY29tDQo+ID4gd3JvdGUgMjAxMi8wMy8wMSAwNDozNTo0MToNCj4g DQo+ID4gSGkgTGl6aG9uZywgDQo+ID4gSSBhY3R1YWxseSB0aGluayB0aGF0IHdlIHdvdWxkIG5l ZWQgdG8gZGVmaW5lIGEgbmV3IG9uZSB3aGljaCB3aWxsIA0KPiA+IGFjY29tb2RhdGUgYW4gSVB2 NiAvMTI4IGFkZHJlc3MuIE90aGVyd2lzZSwgdGFyZ2V0ZWQgTERQIHNlc3Npb25zIGluDQo+ID4g YSBhbGwtSVB2NiBuZXR3b3JrIHdpbGwgbm90IGJlIHBvc3NpYmxlLiBJIGNhbm5vdCBzZWUgdGhh dCBvcGVyYXRvcnMNCj4gPiB3aWxsIHN0YXJ0IG1haW50YWluaW5nIGEgbWFwcGluZyBvZiBzb21l IGdsb2JhbCBub24gcm91dGFibGUgTFNSLWlkIA0KPiA+IHZhbHVlIHRvIGFuIElQdjYgbG9vcGJh Y2sgaW50ZXJmYWNlIG9uIGVhY2ggcm91dGVyIGluIHRoZSBuZXR3b3JrLiANCj4gPiANCj4gPiBN dXN0YXBoYS4gDQo+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiANCj4gPiBBaXNzYW91aSwgTXVzdGFwaGEg KE11c3RhcGhhKQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDEyIDEwOjEyIEFN DQo+ID4gVG86IExpemhvbmcgSmluOyBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsgdmlzaHdh cy5pZXRmQGdtYWlsLmNvbQ0KPiA+IENjOiBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6 IFttcGxzXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW1wbHMtbGRwLWlwdjYtMDYNCj4gDQo+ID4g TGl6aG9uZywgDQo+ID4gdGhlIGV4aXN0aW5nIExTUi1pZCB3aWxsIGRvIHRoZSBqb2IgYW5kIHNo b3VsZCBiZSBzdXBwb3J0ZWQgc2luY2UgDQo+ID4gdGhlIExTUi1pZCBuZWVkIG5vdCBiZSBhbiBJ UCBhZGRyZXNzLiBNb3N0IGltcGxlbWVudGF0aW9ucyB3aWxsIA0KPiA+IGFjdHVhbGx5IHBvcHVs YXRlIHRoZSBmaWVsZCB3aXRoIGEgLzMyIGFkZHJlc3MgaW4gSVB2NCBhbmQgdGh1cyBJZiANCj4g PiBuZWNlc3Nhcnkgd2UgY291bGQgZGVmaW5lIGEgbmV3IGZvcm1hdCB0byBhbGxvdyB0aGUgdXNl IG9mIC8xMjggDQo+IElQdjZhZGRyZXNzZXMuIA0KPiA+IA0KPiA+IE11c3RhcGhhLiANCj4gPiAN Cj4gPiBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRvOmxpemhvbmcuamluQHp0ZS5jb20uY25dIA0K PiA+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDYsIDIwMTIgMTA6MjMgUE0NCj4gPiBUbzogRHV0 dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7IHZpc2h3YXMuaWV0ZkBnbWFpbC5jb207IEFpc3Nhb3Vp LCANCj4gPiBNdXN0YXBoYSAoTXVzdGFwaGEpDQo+ID4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0w Ng0KPiANCj4gPiANCj4gPiBIaSwgDQo+ID4gSSB3b25kZXIgaWYgaXQgaXMgZmVhc2libGUgdG8g dXNlIExEUCBjYXBhYmlsaXR5IHRvIGFkdmVydGlzZSBJUHY2IA0KPiA+IEZFQyB3aXRob3V0IElQ djYgYWRqYWNlbmN5LCBhbmQgb25seSB1c2Ugb25lIGFkamFjZW5jeSBmb3IgTERQIA0KPiA+IHNl c3Npb24gaW4gZHVhbC1zdGFjayBuZXR3b3JrLiBMRFAgY2FwYWJpbGl0eSBpcyBwZXIgbm9kZSAN Cj4gPiBjYXBhYmlsaXR5LCBub3QgcGVyIGludGVyZmFjZSBjYXBhYmlsaXR5LiBCdXQgZm9yIExE UCB0byBjaG9vc2UgdGhlIA0KPiA+IGNvcnJlY3QgZG93bnN0cmVhbSBzZXNzaW9uIGFuZCBvdXRw dXQgaW50ZXJmYWNlIGZvciBlYWNoIEZFQywgaXQgDQo+ID4gc2hvdWxkIGFsc28gY2hlY2sgaWYg dGhlIG91dHB1dCBpbnRlcmZhY2UgaXMgTERQIGVuYWJsZWQgb3Igbm90LiBUaGUNCj4gPiBsaW5r IGFkamFjZW5jeSBjb3VsZCBiZSB1c2VkIHRvIGFzc2lzdCBzdWNoIGtpbmQgb2YgY2hlY2tpbmcu IA0KPiA+IA0KPiA+IEhvd2V2ZXIsIElNTywgaXQgaXMgdmFsdWFibGUgdG8gYWxsb3cgdHdvIGlu ZGVwZW5kZW50IExEUCBzZXNzaW9ucyANCj4gPiBmb3IgSVB2NCBhbmQgSVB2NiBhcyBhbiBvcHRp b24uIFJlZ2FyZGluZyB0aGUgZm9ybWF0IGRlZmluaXRpb24gaW4gDQo+ID4gUkZDNTAzNiwgd2Ug bWF5IG5lZWQgbmV3IExEUCB2ZXJzaW9uIG51bWJlciB0byBpZGVudGlmeSBJUHY2IExTUi1JRC4N Cj4gPiBPciB3ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1JRCBmb3IgSVB2NiB3aXRoIElQdjQs IGJ1dCBJIHByZWZlciANCj4gPiBuZXcgZm9ybWF0IG9mIExTUi1JRC4gDQo+ID4gDQo+ID4gUmVn YXJkcyANCj4gPiBMaXpob25nIA0KPiA+IA0KPiA+IA0KPiA+ID4gDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gPiANCj4gPiA+IE1lc3NhZ2U6IDENCj4gPiA+IERhdGU6IFR1ZSwgNyBGZWIgMjAxMiAwNToy ODoyMSArMDUzMA0KPiA+ID4gRnJvbTogIkR1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpIiANCjxw cmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4gPiA+IFRvOiBWaXNod2FzIE1hbnJh bCA8dmlzaHdhcy5pZXRmQGdtYWlsLmNvbT4NCj4gPiA+IENjOiAiQWlzc2FvdWksIE11c3RhcGhh IFwoTXVzdGFwaGFcKSINCj4gPiA+ICAgIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2Vu dC5jb20+LCAgICJtcGxzQGlldGYub3JnIg0KPiA+ID4gICAgPG1wbHNAaWV0Zi5vcmc+DQo+ID4g PiBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2 Ni0wNg0KPiA+ID4gTWVzc2FnZS1JRDoNCj4gPiA+ICAgIDxDNTg0MDQ2NDY2RUQyMjRDQTkyQzFC QzMzMTNCOTYzRTA5RUZFOEQ2NjdASU5CQU5TWENITUJTQTMuaW4uDQo+ID4gPiBhbGNhdGVsLWx1 Y2VudC5jb20+DQo+ID4gPiANCj4gPiA+IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD0idXMtYXNjaWkiDQo+ID4gPiANCj4gPiA+IEkgd291bGQgcmF0aGVyIGZvciBjb21wbGV0ZSBz ZXBhcmF0aW9uIHdpdGggbXVsdGlwbGUgbHNyLWlkIGJlY2F1c2UgDQo+ID4gPiBoYXZpbmcgc2Vw YXJhdGUgbGluayBhZGphY2VuY2llcyBkb2VzIG5vdCByZWFsbHkgc29sdmVkIGFueSBwcm9ibGVt Lg0KPiA+ID4gU2luY2UgaGVsbG8gYWRqYWNlbmNpZXMgYXJlIGFzc29jaWF0ZWQgd2l0aCBhIGxp bmssIHN0aWxsIGZhdGUgDQo+ID4gPiBzaGFyaW5nIHdvdWxkIGNvbnRpbnVlIG92ZXIgdGhlIHNp bmdsZSBsZHAvdGNwIHNlc3Npb24gZm9yIElQVjQgYW5kIA0KSVBWNi4NCj4gPiA+IEhhdmluZyBJ UFY0IGFuZCBJUFY2IHNwZWNpZmljIGhlbGxvIGFkamFjZW5jaWVzIG92ZXIgYSBsaW5rIHdvdWxk IA0KPiA+ID4gb25seSBkZWNpZGUgd2hldGhlciBzdWNoIGEgbGluayBpcyB0byBiZSBwcm9ncmFt bWVkIGZvciBJUFY0IG9yIElQVjYNCj4gPiA+IGVncmVzcyB0cmFmZmljIGJ1dCBJIHNlZSBpdCBh cyBvdmVya2lsbCBhbmQgdW5uZWNlc3NhcnkgDQo+IHNjYWxhYmlsaXR5IGltcGFjdHMuDQo+ID4g PiANCj4gPiA+IFRoYW5rcywNCj4gPiA+IFByYW5qYWwNCg== --=_alternative 00248740482579B8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSB0d28gc2VwYXJhdGUgaGVs bG8gYWRqYWNlbmN5IGlzc3VlDQppcyBjYXVzZWQgYnkgdGhlIGN1cnJlbnQgZGVmaW5lZCBMRFAg Y2FwYWJpbGl0eSBwZXIgbm9kZSBpbiBSRkM1NTYxLiBBY3R1YWxseSwNCmNhcGFiaWxpdHkgcGVy IDwvZm9udD48Zm9udCBzaXplPTI+PHR0PmhlbGxvIGFkamFjZW5jeSBpcyBhIGdlbmVyYWwgcmVx dWlyZW1lbnQNCmFuZCBub3Qgc3BlY2lmaWMgZm9yIExEUCBJUHY2LiBXZSBzaG91bGQgdXBkYXRl IFJGQzU1NjEgZmlyc3QsIHNvIGFzIHRvDQpoYXZlIG9uZSBoZWxsbyBhZGphY2VuY3kgZm9yIGR1 YWwtc3RhY2sgaW50ZXJmYWNlLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+UmVnYXJkczwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+TGl6aG9uZzwvdHQ+ PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7RHV0dGEsIFBy YW5qYWwgSyAoUHJhbmphbCkmcXVvdDsgJmx0O3ByYW5qYWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQu Y29tJmd0Ow0Kd3JvdGUgMjAxMi8wMy8wMyAwMjoyMjoyMjo8YnI+DQo8YnI+DQomZ3Q7IEhpIFZp c3dhcyw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtXZSByYWlzZWQgb25lIG1vcmUgcG9pbnQgZWFybGllciBvbiB0aGUgPGJyPg0KJmd0 OyBmb2xsb3dpbmcgY2xhdXNlIGluIHRoZSBkcmFmdC48L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7IFNlY3Rpb24gNi4yIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAm bmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNw O0FzIG91dGxpbmVkIGluIHNlY3Rpb24gMi41LjUgb2YNClJGQzUwMzYsIHRoaXMgZHJhZnQgZGVz Y3JpYmVzIHRoYXQ8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7 ICZuYnNwO2lmIGFuIExTUiBoYXMgYSBkdWFsLXN0YWNrIGludGVyZmFjZSwNCndoaWNoIGlzIGVu YWJsZWQgd2l0aCBib3RoPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZu YnNwOyAmbmJzcDtJUHY0IGFuZCBJUHY2IExEUCwgdGhlbiB0aGUgTFNSDQptdXN0IHBlcmlvZGlj YWxseSBzZW5kIGJvdGggSVB2NCBhbmQ8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0 PiZndDsgJm5ic3A7ICZuYnNwO0lQdjYgTERQIExpbmsgSGVsbG9zIGFuZCBtdXN0IHNlcGFyYXRl bHkNCm1haW50YWluIHRoZSBIZWxsbzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ Jmd0OyAmbmJzcDsgJm5ic3A7YWRqYWNlbmN5IGZvciBJUHY0IGFuZCBJUHY2IG9uIHRoYXQNCmlu dGVyZmFjZS48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90 dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 VGhpcyBlbnN1cmVzIHN1Y2Nlc3NmdWwgbGFiZWxlZA0KSVB2NCBhbmQgbGFiZWxlZCBJUHY2IHRy YWZmaWM8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtmb3J3YXJkaW5nIG9uIGEgZHVhbC1zdGFja2VkDQppbnRlcmZhY2UsIGFzIHdlbGwg YXMgc3VjY2Vzc2Z1bCBMRFA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtwZWVyaW5nIHVzaW5nIHRoZSBhcHByb3ByaWF0ZQ0KdHJhbnNw b3J0IG9uIGEgbXVsdGktYWNjZXNzPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW50ZXJmYWNlIChldmVuIGlmIHRoZXJlDQphcmUgSVB2 NC1vbmx5LCBJUHY2LW9ubHkgYW5kIGR1YWwtc3RhY2s8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMU1JzIGNvbm5lY3RlZCB0byB0aGF0 IG11bHRpLWFjY2Vzcw0KaW50ZXJmYWNlKS48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZu YnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBUaGUgZHJhZnQgbWFu ZGF0ZXMgdGhhdCB0d28gc2VwYXJhdGUgaGVsbG8gYWRqYWNlbmNpZXMNCnNob3VsZCBiZSA8YnI+ DQomZ3Q7IG1haW50YWluZWQgb24gZHVhbC1zdGFjayCoQyBvbmUgZm9yIElQVjQgYW5kIGFub3Ro ZXIgZm9yIElQVjYuIFdlDQo8YnI+DQomZ3Q7IGRvbqGvdCBzZWUgYW55IGJlbmVmaXQgb3IgdGVj aG5pY2FsIHJlYXNvbiBvZiBydW5uaW5nIHR3byBzZXBhcmF0ZQ0KPGJyPg0KJmd0OyBhZGphY2Vu Y2llcy4gJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNw OzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAxLiAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ZpcnN0IG9mIGFsbCwgZG9pbmcgc28NCmRvZXMgbm90IHByb3ZpZGUgZmF0ZSBzZXBh cmF0aW9uIGFueSA8YnI+DQomZ3Q7IHdheS4gQm90aCBJUFY0IGFuZCBJUFY2IGZlY3MgYXJlIHN0 aWxsIGV4Y2hhbmdlZCBvdmVyIHNhbWUgTERQIHNlc3Npb25zLg0KPC90dD48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+Jmd0OyAyLiAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgY2xhdXNlIG1hbmRhdGVzIHRo YXQNCmEgdHJhbnNpdCBuZXR3b3JrIHRoYXQgaXMgY2Fycnlpbmc8YnI+DQomZ3Q7IElQVjYgTFNQ cyBtdXN0IHByb3Zpc2lvbiBJUHY2IGludGVyZmFjZXMuICZuYnNwO0l0IGlzIG5vdCBtYW5kYXRv cnkNCnRoYXQgPGJyPg0KJmd0OyB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgaXRzZWxmIGJlIElQVjYg aW4gb3JkZXIgdG8gY2FycnkgSVBWNiB0cmFmZmljDQo8YnI+DQomZ3Q7IG92ZXIgaXRzIHR1bm5l bHMuIFRoaXMgaXMgYSB2ZXJ5IG5hcnJvdyBpbnRlcnByZXRhdGlvbiBvZiBzZWN0aW9uDQoyLjxi cj4NCiZndDsgNS41IGluICZuYnNwO1JGQyA1MDM2LiBJdKGvcyBub3QgbmVjZXNzYXJ5IHRoYXQg YW4gSVBWNiBGRUMgc2hvdWxkDQpiZSA8YnI+DQomZ3Q7IHJlc29sdmVkIGJ5IGFuIElQVjYgb25s eSByb3V0ZSBuZXh0LWhvcC4gVGhlIGhlbGxvIGFkamFjZW5jeSBjYW4gPGJyPg0KJmd0OyBzdGls bCBiZSBvdmVyIGFuIElQVjQgbGluayBhbmQgSVBWNiBwcmVmaXggY2FuIHN0aWxsIGJlIHJlc29s dmVkIGJ5DQo8YnI+DQomZ3Q7IGFuIElQVjQgcm91dGUgbmV4dC1ob3AuIEl0oa9zIG5vdCBuZWNl c3NhcnkgdGhhdCBzb3VyY2Ugb2YgaGVsbG9zDQpiZSA8YnI+DQomZ3Q7IElQdjYgb3IgdHJhbnNw b3J0IGFkZHJlc3Mgb2YgVENQIHNlc3Npb24gYmUgaXB2Ni48L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD4mZ3Q7IDMuICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBjbGF1c2UgaGFzIHVubmVjZXNzYXJ5 DQpzY2FsYWJpbGl0eSBpbXBsaWNhdGlvbnMuIFdlIGRvIDxicj4NCiZndDsgcnVuIHZlcnkgbGFy Z2UgbnVtYmVyIG9mIExEUCBhZGphY2VuY2llcy9zZXNzaW9ucyAoZS5nIDEwSykgaW4gPGJyPg0K Jmd0OyBtb2JpbGl0eSBiYWNraGF1bHMgb3Igc2ltaWxhciBkZXBsb3ltZW50cy4gVGhpcyBjbGF1 c2UgcmVxdWlyZXMgdG8NCjxicj4NCiZndDsgcnVuIDIwSyBoZWxsbyBhZGphY2VuY2llcyB3aGlj aCBoYXMgc2NhbGFiaWxpdHkgaW1wbGljYXRpb25zLiBPbiA8YnI+DQomZ3Q7IHRoZW9yeSB0aGVy ZSBtYXkgbm90IG11Y2ggZGlmZmVyZW5jZSBiZXR3ZWVuIDEwSyBhbmQgMjBLIGJ1dCBpbiByZWFs PGJyPg0KJmd0OyBpbXBsZW1lbnRhdGlvbnMgdGhlcmUgaXMuIElmIHdlIGFsbG93IHNlcGFyYXRp b24gb2Ygc2Vzc2lvbnMgZm9yIDxicj4NCiZndDsgZmF0ZSBzZXBhcmF0aW9uIG9mIElQVjQgYW5k IElQVjYgdGhlbiBpdCB3b3VsZCBiZWNvbWUgNDBLIGFkamFjZW5jaWVzLjwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PiZndDsgV2UgY2FuIGxpbWl0IHRvIG9ubHkgb25lIGhlbGxvIGFkamFjZW5jeSBw ZXINCmludGVyZmFjZSB5ZXQgYWRkcmVzcyA8YnI+DQomZ3Q7IHRoZSBkdWFsIHN0YWNrIGlzc3Vl LiBBIGdyYWNlZnVsIHNvbHV0aW9uIGlzIHRvIGNvbWUgdXAgd2l0aCBhIDxicj4NCiZndDsgbm90 aW9uIG9mIExEUCBhZGphY2VuY3kgc3BlY2lmaWMgY2FwYWJpbGl0aWVzIChzaW1pbGFyIHRvIExE UCA8YnI+DQomZ3Q7IGNhcGFiaWxpdGllcyB0aGF0IGFwcGxpZXMgdG8gZW50aXJlIHNlc3Npb25z KSB0aGF0IHdvdWxkIGJlbmVmaXQgPGJyPg0KJmd0OyBtdWx0aXBsZSBwdXJwb3Nlcy4gRm9yIGV4 YW1wbGUsIHdlIGhhdmUgbXVsdGlwbGUgRUNNUCBMaW5rcyBiZXR3ZWVuDQo8YnI+DQomZ3Q7IG5l aWdoYm9yaW5nIExTUnMgQSBhbmQgQiBhcyBzaG93cyBiZWxvdy48L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOystLS0tLS0tLS0tLS0tLS0tTDEtLS0tLS0tLS0tLS0tLS0t LS0rPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBBDQotLS0tLS0tLS0tLS0tLS0tTDItLS0tLS0tLS0tLS0tLS0tLSBC PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0tLS0tLS0tLS0tLUwzLS0tLS0tLS0tLS0tLS0tLS0t KzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgVGhlIGhlbGxvIGFkamFjZW5jaWVzIG92ZXIg TDEsIEwyIGFuZCBMMyBhcmUNCklQNCBpbnRlcmZhY2VzIGFyZSA8YnI+DQomZ3Q7IHVzaW5nIGVp dGhlciBJUFY0IE9SIGlwdjYgYWRkcmVzc2VzIGJ1dCBub3QgYm90aC48L3R0PjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD4mZ3Q7IExpbmsgTDEsIEwyIGFyZSBtdWx0aWNhc3QgY2FwYWJsZSAoUDJNUCBvciBN UDJNUF9VUA0Kb3IgTVAyTVBfRE4pLiBMMjxicj4NCiZndDsgYW5kIEwzIGFyZSBJUHY2IGNhcGFi bGUuIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgVGhlbiBoZWxsb3MgZXhjaGFuZ2VkIG92 ZXIgbGluayB3b3VsZCBhZHZlcnRpc2UNCmNhcGFiaWxpdGllcyBhcyBiZWxvdzo8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD4mZ3Q7IEwxIHdvdWxkIGNhcnJ5IGNhcGFiaWxpdGllcyCoQyBJcHY0ICsg TWNhc3Q8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgTDIgd291bGQgY2FycnkgY2FwYWJpbGl0aWVzDQqoQyBpcHY0ICsgaXB2NiArIE1j YXN0PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEwzIHdvdWxkIGNhcnJ5IGNhcGFiaWxpdGllcw0KqEMgaXB2NCArIGlwdjYgPC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwvdHQ+PC9mb250Pg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTI+PHR0PiZndDsgRnJvbSBhbiBpbXBsZW1lbnRlci9zeXN0ZW0gZGVzaWduZXKhr3MgcG9pbnQN Cm9mIHZpZXcgSSB3b3VsZCB0aGluayA8YnI+DQomZ3Q7IHNpbmdsZSBoZWxsbyBhZGphY2VuY3kg d2l0aCBwZXIgYWRqYWNlbmN5IGNhcGFiaWxpdGllcyB3b3VsZCBiZSA8YnI+DQomZ3Q7IHJpZ2h0 IGFwcHJvYWNoLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7 PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFRoYW5rcyw8L3R0PjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgUHJhbmphbCA8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y Pjx0dD4mZ3Q7IDxicj4NCiZndDsgRnJvbTogVmlzaHdhcyBNYW5yYWwgW21haWx0bzp2aXNod2Fz LmlldGZAZ21haWwuY29tXSA8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjks IDIwMTIgNToxMSBQTTxicj4NCiZndDsgVG86IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpPGJy Pg0KJmd0OyBDYzogTGl6aG9uZyBKaW47IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBt cGxzQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+Jmd0OyAmbmJzcDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgSGkg TGl6aG9uZy8gUHJhbmphbC8gTXVzdGFwaGEsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIHRoZSB0 d28gbWFpbiBjb21tZW50cyB0aGF0IGhhdmUgY29tZSBhZnRlciBsYXN0IGNhbGwgYXJlOjxicj4N CiZndDsgPGJyPg0KJmd0OyAxLiBBbGxvdyBmb3Igc2VwYXJhdGlvbiBvZiBzZXNzaW9ucyBhbG9u ZyB3aXRoIHRoZSBhZGphY2VuY3kuPGJyPg0KJmd0OyAyLiBBbGxvdyBmb3IgYW4gSVB2NiBiYXNl ZCBMU1ItSUQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBzZWNvbmQgY291bGQgbGVhZCB0byBj aGFuZ2VzIHJlcXVpcmVkIGluIGJvdGggT1NQRiBhbmQgSVMtSVMsDQphczxicj4NCiZndDsgd2Vs bCBiZWNhdXNlIHRoZSBuZXcgTFNSIElEIHdvdWxkIHRoZW4gbmVlZCB0byBiZSBleGNoYW5nZWQu IFdlIDxicj4NCiZndDsgY291bGQgdHJlYXQgaXQgYXMgYW4gZW5oYW5jZW1lbnQgaW5zdGVhZCBp biBteSB2aWV3LiBEbyB5b3UgYWdyZWU/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+ DQomZ3Q7IFZpc2h3YXM8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgT24g V2VkLCBGZWIgMjksIDIwMTIgYXQgNTowMyBQTSwgRHV0dGEsIFByYW5qYWwNCksgKFByYW5qYWwp ICZsdDs8YnI+DQomZ3Q7IHByYW5qYWwuZHV0dGFAYWxjYXRlbC1sdWNlbnQuY29tJmd0OyB3cm90 ZTo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgWWVzLCBJIHN1cHBvcnQg dGhhdCB0b28uIFRoZXJlIHdvdWxkIGJlIG5ldHdvcmsNCm1hbmFnZW1lbnQgaXNzdWVzIDxicj4N CiZndDsgd2l0aCBtYXBwaW5nIG9mIDQgYnl0ZSBMU1ItSUQgdG8gYW4gSVBWNiByZW1vdGUgYWRk cmVzcy48L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgTW9zdCBvZiB0aGUg aW1wbGVtZW50YXRpb25zIEkga25vdyBvZmYgdXN1YWxseQ0KbWFwcyA0IGJ5dGUgb2YgdGhlIDxi cj4NCiZndDsgTFNSLUlEIHdpdGggYSBsb2NhbCBpcHY0IGludGVyZmFjZSBhZGRyZXNzIGluIHRo ZSBzeXN0ZW0uPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7ICZuYnNwOzwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBUaGFua3MsPC90dD48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IFByYW5qYWw8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD4mZ3Q7IDxicj4NCiZndDsgRnJvbTogTGl6aG9uZyBKaW4gW21haWx0bzpsaXpob25nLmppbkB6 dGUuY29tLmNuXSA8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjksIDIwMTIg NDo1NyBQTTxicj4NCiZndDsgVG86IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpPGJyPg0K Jmd0OyBDYzogbXBsc0BpZXRmLm9yZzsgRHV0dGEsIFByYW5qYWwgSyAoUHJhbmphbCk7IHZpc2h3 YXMuaWV0ZkBnbWFpbC5jb208L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsg PGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBs cy1sZHAtaXB2Ni0wNjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyAmbmJz cDs8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgJm5ic3A7PC90dD48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IEhpIE11c3RhcGhhLCA8YnI+DQomZ3Q7IEkg YWdyZWUsIGFuZCBJIGFsc28gcHJlZmVyIHRvIGRlZmluaW5nIGEgSVB2NiBmb3JtYXRlZCBMU1It SUQsIGFzDQpJIDxicj4NCiZndDsgcG9pbnRlZCBvdXQgaW4gbXkgZmlyc3QgZW1haWwuIDxicj4N CiZndDsgPGJyPg0KJmd0OyBUaGFua3MgPGJyPg0KJmd0OyBMaXpob25nIDxicj4NCiZndDsgJm5i c3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtBaXNzYW91aSwgTXVzdGFwaGEgKE11c3Rh cGhhKSZxdW90OyAmbHQ7bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPGJyPg0K Jmd0OyAmZ3Q7IHdyb3RlIDIwMTIvMDMvMDEgMDQ6MzU6NDE6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZndDsgSGkgTGl6aG9uZywgPGJyPg0KJmd0OyAmZ3Q7IEkgYWN0dWFsbHkgdGhpbmsgdGhhdCB3 ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSBhIG5ldyBvbmUgd2hpY2gNCndpbGwgPGJyPg0KJmd0OyAm Z3Q7IGFjY29tb2RhdGUgYW4gSVB2NiAvMTI4IGFkZHJlc3MuIE90aGVyd2lzZSwgdGFyZ2V0ZWQg TERQIHNlc3Npb25zDQppbjxicj4NCiZndDsgJmd0OyBhIGFsbC1JUHY2IG5ldHdvcmsgd2lsbCBu b3QgYmUgcG9zc2libGUuIEkgY2Fubm90IHNlZSB0aGF0IG9wZXJhdG9yczxicj4NCiZndDsgJmd0 OyB3aWxsIHN0YXJ0IG1haW50YWluaW5nIGEgbWFwcGluZyBvZiBzb21lIGdsb2JhbCBub24gcm91 dGFibGUNCkxTUi1pZCA8YnI+DQomZ3Q7ICZndDsgdmFsdWUgdG8gYW4gSVB2NiBsb29wYmFjayBp bnRlcmZhY2Ugb24gZWFjaCByb3V0ZXIgaW4gdGhlIG5ldHdvcmsuDQo8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7IDxicj4NCiZndDsgJmd0OyBNdXN0YXBoYS4gPGJyPg0KJmd0OyAmZ3Q7IEZyb206IG1w bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24NCkJl aGFsZiBPZiA8YnI+DQomZ3Q7ICZndDsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk8YnI+ DQomZ3Q7ICZndDsgU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTIgMTA6MTIgQU08YnI+ DQomZ3Q7ICZndDsgVG86IExpemhvbmcgSmluOyBEdXR0YSwgUHJhbmphbCBLIChQcmFuamFsKTsg dmlzaHdhcy5pZXRmQGdtYWlsLmNvbTxicj4NCiZndDsgJmd0OyBDYzogbXBsc0BpZXRmLm9yZzxi cj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt bXBscy1sZHAtaXB2Ni0wNjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IExpemhvbmcsIDxicj4N CiZndDsgJmd0OyB0aGUgZXhpc3RpbmcgTFNSLWlkIHdpbGwgZG8gdGhlIGpvYiBhbmQgc2hvdWxk IGJlIHN1cHBvcnRlZCBzaW5jZQ0KPGJyPg0KJmd0OyAmZ3Q7IHRoZSBMU1ItaWQgbmVlZCBub3Qg YmUgYW4gSVAgYWRkcmVzcy4gTW9zdCBpbXBsZW1lbnRhdGlvbnMgd2lsbA0KPGJyPg0KJmd0OyAm Z3Q7IGFjdHVhbGx5IHBvcHVsYXRlIHRoZSBmaWVsZCB3aXRoIGEgLzMyIGFkZHJlc3MgaW4gSVB2 NCBhbmQgdGh1cw0KSWYgPGJyPg0KJmd0OyAmZ3Q7IG5lY2Vzc2FyeSB3ZSBjb3VsZCBkZWZpbmUg YSBuZXcgZm9ybWF0IHRvIGFsbG93IHRoZSB1c2Ugb2YgLzEyOA0KPGJyPg0KJmd0OyBJUHY2YWRk cmVzc2VzLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBNdXN0YXBoYS4g PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBGcm9tOiBMaXpob25nIEppbiBbbWFpbHRv OmxpemhvbmcuamluQHp0ZS5jb20uY25dIDxicj4NCiZndDsgJmd0OyBTZW50OiBNb25kYXksIEZl YnJ1YXJ5IDA2LCAyMDEyIDEwOjIzIFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBEdXR0YSwgUHJhbmph bCBLIChQcmFuamFsKTsgdmlzaHdhcy5pZXRmQGdtYWlsLmNvbTsgQWlzc2FvdWksDQo8YnI+DQom Z3Q7ICZndDsgTXVzdGFwaGEgKE11c3RhcGhhKTxicj4NCiZndDsgJmd0OyBDYzogbXBsc0BpZXRm Lm9yZzxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0 LWlldGYtbXBscy1sZHAtaXB2Ni0wNjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBIaSwgPGJyPg0KJmd0OyAmZ3Q7IEkgd29uZGVyIGlmIGl0IGlzIGZlYXNpYmxlIHRv IHVzZSBMRFAgY2FwYWJpbGl0eSB0byBhZHZlcnRpc2UNCklQdjYgPGJyPg0KJmd0OyAmZ3Q7IEZF QyB3aXRob3V0IElQdjYgYWRqYWNlbmN5LCBhbmQgb25seSB1c2Ugb25lIGFkamFjZW5jeSBmb3Ig TERQDQo8YnI+DQomZ3Q7ICZndDsgc2Vzc2lvbiBpbiBkdWFsLXN0YWNrIG5ldHdvcmsuIExEUCBj YXBhYmlsaXR5IGlzIHBlciBub2RlIDxicj4NCiZndDsgJmd0OyBjYXBhYmlsaXR5LCBub3QgcGVy IGludGVyZmFjZSBjYXBhYmlsaXR5LiBCdXQgZm9yIExEUCB0byBjaG9vc2UNCnRoZSA8YnI+DQom Z3Q7ICZndDsgY29ycmVjdCBkb3duc3RyZWFtIHNlc3Npb24gYW5kIG91dHB1dCBpbnRlcmZhY2Ug Zm9yIGVhY2ggRkVDLA0KaXQgPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBhbHNvIGNoZWNrIGlmIHRo ZSBvdXRwdXQgaW50ZXJmYWNlIGlzIExEUCBlbmFibGVkIG9yIG5vdC4NClRoZTxicj4NCiZndDsg Jmd0OyBsaW5rIGFkamFjZW5jeSBjb3VsZCBiZSB1c2VkIHRvIGFzc2lzdCBzdWNoIGtpbmQgb2Yg Y2hlY2tpbmcuDQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhvd2V2ZXIsIElNTywg aXQgaXMgdmFsdWFibGUgdG8gYWxsb3cgdHdvIGluZGVwZW5kZW50IExEUCBzZXNzaW9ucw0KPGJy Pg0KJmd0OyAmZ3Q7IGZvciBJUHY0IGFuZCBJUHY2IGFzIGFuIG9wdGlvbi4gUmVnYXJkaW5nIHRo ZSBmb3JtYXQgZGVmaW5pdGlvbg0KaW4gPGJyPg0KJmd0OyAmZ3Q7IFJGQzUwMzYsIHdlIG1heSBu ZWVkIG5ldyBMRFAgdmVyc2lvbiBudW1iZXIgdG8gaWRlbnRpZnkgSVB2Ng0KTFNSLUlELjxicj4N CiZndDsgJmd0OyBPciB3ZSB1c2UgZGlmZmVyZW50IDMyYml0IExTUi1JRCBmb3IgSVB2NiB3aXRo IElQdjQsIGJ1dCBJIHByZWZlcg0KPGJyPg0KJmd0OyAmZ3Q7IG5ldyBmb3JtYXQgb2YgTFNSLUlE LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHMgPGJyPg0KJmd0OyAmZ3Q7 IExpemhvbmcgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgTWVzc2FnZTogMTxicj4NCiZndDsgJmd0OyAmZ3Q7IERhdGU6IFR1ZSwgNyBGZWIgMjAxMiAw NToyODoyMSArMDUzMDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206ICZxdW90O0R1dHRhLCBQcmFu amFsIEsgKFByYW5qYWwpJnF1b3Q7ICZsdDtwcmFuamFsLmR1dHRhQGFsY2F0ZWwtbHVjZW50LmNv bSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogVmlzaHdhcyBNYW5yYWwgJmx0O3Zpc2h3YXMu aWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2M6ICZxdW90O0Fpc3Nhb3Vp LCBNdXN0YXBoYSBcKE11c3RhcGhhXCkmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7Jmx0O211c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbSZndDssDQombmJz cDsgJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsmbHQ7bXBsc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBS ZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbXBscy1sZHAtaXB2Ni0wNjxicj4NCiZn dDsgJmd0OyAmZ3Q7IE1lc3NhZ2UtSUQ6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyZsdDtDNTg0MDQ2NDY2RUQyMjRDQTkyQzFCQzMzMTNCOTYzRTA5RUZFOEQ2NjdASU5CQU5TWENI TUJTQTMuaW4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYWxjYXRlbC1sdWNlbnQuY29tJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBDb250ZW50 LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9JnF1b3Q7dXMtYXNjaWkmcXVvdDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIHJhdGhlciBmb3IgY29tcGxl dGUgc2VwYXJhdGlvbiB3aXRoIG11bHRpcGxlIGxzci1pZA0KYmVjYXVzZSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBoYXZpbmcgc2VwYXJhdGUgbGluayBhZGphY2VuY2llcyBkb2VzIG5vdCByZWFsbHkg c29sdmVkDQphbnkgcHJvYmxlbS48YnI+DQomZ3Q7ICZndDsgJmd0OyBTaW5jZSBoZWxsbyBhZGph Y2VuY2llcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGEgbGluaywgc3RpbGwNCmZhdGUgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgc2hhcmluZyB3b3VsZCBjb250aW51ZSBvdmVyIHRoZSBzaW5nbGUgbGRwL3Rj cCBzZXNzaW9uIGZvcg0KSVBWNCBhbmQgSVBWNi48YnI+DQomZ3Q7ICZndDsgJmd0OyBIYXZpbmcg SVBWNCBhbmQgSVBWNiBzcGVjaWZpYyBoZWxsbyBhZGphY2VuY2llcyBvdmVyIGEgbGluaw0Kd291 bGQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgb25seSBkZWNpZGUgd2hldGhlciBzdWNoIGEgbGluayBp cyB0byBiZSBwcm9ncmFtbWVkIGZvcg0KSVBWNCBvciBJUFY2PGJyPg0KJmd0OyAmZ3Q7ICZndDsg ZWdyZXNzIHRyYWZmaWMgYnV0IEkgc2VlIGl0IGFzIG92ZXJraWxsIGFuZCB1bm5lY2Vzc2FyeQ0K PGJyPg0KJmd0OyBzY2FsYWJpbGl0eSBpbXBhY3RzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBQcmFuamFsPC90dD48 L2ZvbnQ+DQo= --=_alternative 00248740482579B8_=-- From pranjal.dutta@alcatel-lucent.com Mon Mar 5 09:42:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A216D21F88BA for ; Mon, 5 Mar 2012 09:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.28 X-Spam-Level: X-Spam-Status: No, score=-9.28 tagged_above=-999 required=5 tests=[AWL=1.319, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-1v6bwIBZez for ; Mon, 5 Mar 2012 09:42:34 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7494521F88B8 for ; Mon, 5 Mar 2012 09:42:34 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q25HgGFX019123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 11:42:18 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25HgDoH014879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Mar 2012 23:12:14 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 5 Mar 2012 23:12:13 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mtinka@globaltransit.net" , Kishore Tiruveedhula Date: Mon, 5 Mar 2012 23:12:10 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4++vi3kxJg1LVSNaQbLtt8UmKVgB+oTbg Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.40384.mtinka@globaltransit.net> In-Reply-To: <201203031309.40384.mtinka@globaltransit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:42:35 -0000 Hi Mark,=20 Please refer my comments inline. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Mar= k Tinka Sent: Friday, March 02, 2012 9:10 PM To: Kishore Tiruveedhula Cc: mpls@ietf.org; lizhong.jin@zte.com.cn; Aissaoui, Mustapha (Mustapha) Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Saturday, March 03, 2012 05:08:39 AM Kishore Tiruveedhula=20 wrote: > I think extending LSR ID to 16 bytes ( and changing the > version) would be better option which gives more > flexibility and allows the multiple LDP sessions. So > that operators can choose whether to use 4 byte or 16 > byte LSR ID for Ipv6 LDP session. I don't see how this would hurt, as it maintains backward=20 compatibility for those who are for 32-bit LSR-ID's, and=20 gives 128-bit LSR-ID fans future flexbility. Win-win. [Pranjal] I agree. This is what we want. We shouldn't be restrictive in ldp= -ipv6 draft, rather should provide options, else would hurt various current= applicability scenarios on LDP which has been widely deployed. > Once LSR IDs are different, then there will be different > adjacencies for Ipv4 and Ipv6 and need to send separate > hellos. If the operator chooses 4 byte LSR ID for both > Ipv4 and IPv6, then only one LDP session will be > established and both Ipv4 and IPv6 hellos can go in > single message with IPv6 adj capability in hello. This > will help to avoid if any scaling issues. This works for vendors who specify a global Router-ID that=20 various (routing) protocols reference when starting up. There are other vendors who specify the Router-ID (LSR-ID,=20 in the case of LDP, to be pedantic) via an interface in=20 their CLI. Special care would need to be taken in this=20 scenario, as it would imply that if the reference interface=20 (typically, the Loopback interface) is dual-stack, then 2x=20 adjacencies would be formed, one per AF (on the basis of=20 common sense, of course, as not doing this would indicate=20 that LDPv6 code is ignoring the presence of an IPv6 address=20 on the reference interface, which would be quite odd).=20 However, it is possible a particular operator may prefer=20 adjacency consolidation. Yes, I understand this is vendor- implementation-specific, but I thought I'd mention it now so=20 that operators have this flexibility the moment LDPv6 code=20 starts shipping, rather than wait for a future upgrade which=20 provides knobs for adjacency separation or consolidation. I suppose we can leave it up to vendors which option is the=20 default in their implementation, although my personal=20 preference would be for adjacency separation :-). [Pranjal] Just to clarify that "adjacency" separation does not give you fat= e separation. For fate separation we would need to separation of "sessions"= . Hello Adjacency and Session are two different concepts in LDP. The curren= t text in the draft makes it mandatory to have two separate hello adjacenci= es for the same "fate shared" session. This conflicts with the way we decid= ed to move forward with various fec types. Please refer to my reply to your= other mail on the various technical reasons why I am saying so. Cheers, Mark. From pranjal.dutta@alcatel-lucent.com Mon Mar 5 10:31:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5021F87FE for ; Mon, 5 Mar 2012 10:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.038 X-Spam-Level: X-Spam-Status: No, score=-7.038 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2kO3y7kK1GW for ; Mon, 5 Mar 2012 10:31:41 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 56B3D21F87D4 for ; Mon, 5 Mar 2012 10:31:41 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q25IVRRg006261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 12:31:30 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25IVQMm028619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 00:01:26 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 6 Mar 2012 00:01:26 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mtinka@globaltransit.net" , "mpls@ietf.org" Date: Tue, 6 Mar 2012 00:01:23 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4++rqP00r2+MmRu+KPYcyprKrWgB+23xg Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> In-Reply-To: <201203031309.34330.mtinka@globaltransit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:31:42 -0000 Hi Mark, Please refer my responses inline. Thanks, Pranjal -----Original Message----- From: Mark Tinka [mailto:mtinka@globaltransit.net]=20 Sent: Friday, March 02, 2012 9:10 PM To: mpls@ietf.org Cc: Dutta, Pranjal K (Pranjal); Vishwas Manral; Aissaoui, Mustapha (Mustaph= a); Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 (Pranjal) wrote: > >From an implementer/system designer's point of view I > >would think single hello adjacency with per adjacency > >capabilities would be right approach. Pranjal, I appreciate that from a vendor perspective,=20 implementing it this way would make sense for large scale=20 deployments. However, for some operators who may be using BGP or RSVP to=20 signal or nest a large number of LSP's, we would like to=20 have the option of choosing a discrete separation of IPv4=20 and IPv6 adjacencies for LDP. If there are operators who aren't going to be looking at=20 scaling that many LSP's anytime in their network, they might=20 still prefer to eliminate adjacency fate-sharing. I think we are confusing two different things. Having separate he= llo adjacency over an interface as mandated in ldp-ipv6 draft **DOES NOT** = give you fate separation. Still both IPV4 and IPV6 FECs would fate-share sa= me LDP session. We are in fact saying that fate separation is desirable but for that we nee= d=20 separation of **sessions** and NOT hello adjacencies. If you follow the ldp= -ipv6 draft of separate adjacencies for IPV4 and IPV6 still all IPV4 and IP= V6=20 FECs would be fate sharing a **single** LDP sessions. The ldp-ipv6 draft makes it **mandatory** that dual stack interface MUST=20 Have two separate hello adjacencies. This does not make any sense from=20 practical stand point and rather raises many open questions keeping in view= of existing applicability/capabilities of LDP. IP6 FEC next-hop resolution= algorithms does not mandate running hello adjacency with an ipv6 next-hop.= FEC capabilities are decoupled from the address family used in hello adjac= encies.=20 Just to give an example. Let's take the WG item on mLdp in-band signaling draft below.=20 http://tools.ietf.org/html/draft-ietf-mpls-mldp-in-band-signaling-05 This draft defines in-band signaling of multicast (S,G)s top set-up the LDP= Multicast tunnels for the respective S,Gs. If we look at section 3 it has = IPV4 as well as IPV6 specific multicast LSPs. If ldp-ipv6 draft mandates ru= nning separate adjacencies on dual stack then the question would be - where= is the placement of those LSP types w.r.t dual hello adjacencies **mandate= d** by ldp-ipv6?=20 The WG has decided to move to LDP capabilities (RFC 5561) to advertise vari= ous capabilities of a single LDP session. Various extensions has been done = further based on that. For example, mLdp Spec (RFC 6388) defines capabiliti= es for various multicast fec types (Refer to section 2.1) over an ldp sessi= ons. mLdp has been shipped and is deployed. Now are we saying we=20 Should be running **separate** hello adjacencies per FEC type over a **sing= le** Interface with **same** peering LSR?=20 There is another WG item that introduces IP and PW FEC Capability. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-01 Then why the fundamental shift for IPV6 unicast FECs alone? I have scouted = the archive on all discussions occurred in the past on ldp-ipv6 yet hasn't = seen a strong technical basis why it is MUST for IPV6 FECs to take a radica= lly different approach.=20 In ldp-ipv6 draft, the proposal of running separate ipv4 and ipv6 hello adj= acencies yet fate sharing **same** session to signal dual stack capabilitie= s is a fundamental shift from the capability based approaches already adopt= ed by the WG. IPV6 is just another FEC element type. I have seen puritanica= l references like "OSPF does so", "BGP does so" in some discussions in this= list but that does not provide enough technical basis in the context of LD= P. There has to be a single/consistent approach=20 To satisfy your requirement for fate separation of IPV4 and IPV6 FECs, we n= eed to work out a separate spec on running "multi-lsr" **sessions** between= two peering systems - as an extension to RFC 5036. Such method can not on= ly useful for IPV4 and IPV6 FEC separation but for other types as well. For= example, it can also provide an option for fate separation of PW FECs (L2 = Over lay) from the transport FECs (IPV4, IPV6, Multicast). =20 I would propose that vendors implement both options,=20 allowing operators to choose (via CLI) which method they=20 would like to deploy in the field. There are many operators=20 out there who maintain separate BGP transport and policy=20 sessions for IPv4 and IPv6 AF's to protect themselves=20 against the problems fate-sharing could bring. This is why=20 some of us prefer to make our lives harder by going native,=20 dual-stack rather than 6PE :-). As I mentioned above separation of ipv4 and ipv6 hello adjacencie= s does not provide fate separation. I guess what you are mentioning about=20 Separation of IPV4 and IPV6 FECs over two separate LDP sessions between=20 two peering systems which can be achieved by running multi-lsr sessions. <\Pranjal>=20 So while I won't disagree with your opinion on using a=20 single adjacency for both AF's for scaling purposes, I would=20 certainly like to have the option to choose which method=20 suits me best in the wild. =20 I think what you are looking for knob to toggle fate sharing and fate separ= ation of IPV4 and IPV6 FECs. For this we need a knob whether we=20 Single LSR peering or multi-lsr peering. This is different from separation= =20 Of ipv4 and ipv6 hello adjacencies. In LDP, hello adjacencies are discovery= protocols and does not have "tight" coupling with various FEC types existe= nt in LDP. We can satisfy both fate-shared and fate-separation requirement= s using single hello adjacency (with per adjacency capabilities) associated= with a remote lsr-id. Mark. From pranjal.dutta@alcatel-lucent.com Mon Mar 5 10:45:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48B021F8899 for ; Mon, 5 Mar 2012 10:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.335 X-Spam-Level: X-Spam-Status: No, score=-7.335 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlaps1frbxCB for ; Mon, 5 Mar 2012 10:45:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 635D521F8826 for ; Mon, 5 Mar 2012 10:45:16 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q25IisVq016254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 12:44:56 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25Iioqv029024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 00:14:51 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 6 Mar 2012 00:14:50 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Shane Amante , "mtinka@globaltransit.net" Date: Tue, 6 Mar 2012 00:14:47 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz5ECCE3iB0wR20T2ejdWW2aKgNUwB72q5Q Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> <71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net> In-Reply-To: <71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:45:19 -0000 Hi Shane, Yes, two separate LDP sessions are required for fate separation o= f ipv4 and ipv6 fecs.=20 Separation of ipv4 and ipv6 hello adjacencies are not required to satisfy=20 a) and b). Both can be achieved with single hello adjacency per interface per peering lsr-id with adjacency specific capabilities. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Friday, March 02, 2012 11:34 PM To: mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Mark, I completely agree with all of your comments below. I too would (strongly) = prefer the option to allow operators to choose (via CLI) whether to: a) use separate transport to ensure there is no fate-sharing of IPv4 + IPv6= ; or, b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, other = AF's) on a single session, for scale reasons. -shane On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 > (Pranjal) wrote: >=20 >>> From an implementer/system designer's point of view I >>> would think single hello adjacency with per adjacency >>> capabilities would be right approach. >=20 > Pranjal, I appreciate that from a vendor perspective,=20 > implementing it this way would make sense for large scale=20 > deployments. >=20 > However, for some operators who may be using BGP or RSVP to=20 > signal or nest a large number of LSP's, we would like to=20 > have the option of choosing a discrete separation of IPv4=20 > and IPv6 adjacencies for LDP. >=20 > If there are operators who aren't going to be looking at=20 > scaling that many LSP's anytime in their network, they might=20 > still prefer to eliminate adjacency fate-sharing. >=20 > I would propose that vendors implement both options,=20 > allowing operators to choose (via CLI) which method they=20 > would like to deploy in the field. There are many operators=20 > out there who maintain separate BGP transport and policy=20 > sessions for IPv4 and IPv6 AF's to protect themselves=20 > against the problems fate-sharing could bring. This is why=20 > some of us prefer to make our lives harder by going native,=20 > dual-stack rather than 6PE :-). >=20 > So while I won't disagree with your opinion on using a=20 > single adjacency for both AF's for scaling purposes, I would=20 > certainly like to have the option to choose which method=20 > suits me best in the wild. >=20 > Mark. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mtinka@globaltransit.net Mon Mar 5 19:13:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CE21E808B for ; Mon, 5 Mar 2012 19:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MDgr1pBIdw5 for ; Mon, 5 Mar 2012 19:13:20 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC321E8089 for ; Mon, 5 Mar 2012 19:13:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S4kpo-00049d-JJ; Tue, 06 Mar 2012 11:13:08 +0800 From: Mark Tinka Organization: Global Transit International To: "Dutta, Pranjal K (Pranjal)" Date: Tue, 6 Mar 2012 11:13:07 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.40384.mtinka@globaltransit.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1922477.AWMLrUckMI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203061113.08085.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" , Kishore Tiruveedhula Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:13:21 -0000 --nextPart1922477.AWMLrUckMI Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, March 06, 2012 01:42:10 AM Dutta, Pranjal K=20 (Pranjal) wrote: > [Pranjal] I agree. This is what we want. We shouldn't be > restrictive in ldp-ipv6 draft, rather should provide > options, else would hurt various current applicability > scenarios on LDP which has been widely deployed. Agree. > [Pranjal] Just to clarify that "adjacency" separation > does not give you fate separation. For fate separation > we would need to separation of "sessions". Hello > Adjacency and Session are two different concepts in LDP. > The current text in the draft makes it mandatory to have > two separate hello adjacencies for the same "fate > shared" session. This conflicts with the way we decided > to move forward with various fec types. Please refer to > my reply to your other mail on the various technical > reasons why I am saying so. Apologies for collapsing here, I should have been more=20 explicit (operator hat, hehe). Yes, I do mean that we make discrete both adjacencies +=20 sessions to achieve a clean and clear separation of fate. Hope this clarifies my position. Mark. --nextPart1922477.AWMLrUckMI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPVYDDAAoJEGcZuYTeKm+GXEoP/iFs6fMLJnxVavtbVgF6ohK0 BB0bIrCmADJAph+Luo7TwTNY9fr0EHPqnnZDvDJ57ohHN7w2+nnSc3hiARgjBuqV LMJvsoJOpMZwSK/zkZf2U7bwW7BRcbs+Q+RSHBKLSKu6Drqe32rqK7AOjjsVG0Qt XhPBDiw78Vu2s5i+ruQMevr/NnJkK6rv+vMvQOlk2MW5keKLIJ5zsQfAwQ01es5s uEEc6DZYmt1Wgeew0BZePsWPSP2P+4ReFEeeKoWYv7SSpu9lGEFNq8+jDOgDxY6P ojevlwKZbu6xWo5xnVUwXz3IttSXOF7vF9fdIdppf35zEgzQP/kqw/2DtfLK3UZw xHPpNEBLpE9L2m4E9+QBmzxG24hpNAnr44qF1xZS4DiafeQLL/h+BH9jd3qViV/j HaxKtMDdwdrrIfwOlAu4nFHILDvBHcNWIuaWRIpwAdLN6BHGFxPZlQ8g9jVQZ1dt m9zDOPgq7JixgmPETt8j79iItQoXxnB+KNR5A0p446qPqPxqdD9IfAsx2ao3i0sS XJVcfTguJWTBw3pC4eTeGPnvVwPNKrdIY2E4dtAqZDx2Z/VXNtKrgKWITSZURGWP NM39Gl4KdjJpg3KjaBeyzGKtF7P40cceutz40wRx8T+S2MOIsu03ogpz9/0GI2Vc bEX7AC23FhSKaX27roD2 =I+hZ -----END PGP SIGNATURE----- --nextPart1922477.AWMLrUckMI-- From shane@castlepoint.net Mon Mar 5 22:13:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256A21F8692 for ; Mon, 5 Mar 2012 22:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xT6CTsF38jc for ; Mon, 5 Mar 2012 22:13:23 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id C760921F8691 for ; Mon, 5 Mar 2012 22:13:23 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id F2F36268063; Mon, 5 Mar 2012 23:13:22 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 05 Mar 2012 23:13:22 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=62561; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 5 Mar 2012 23:13:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> <71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net> To: "Dutta, Pranjal K (Pranjal)" X-Mailer: Apple Mail (2.1257) Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:13:25 -0000 Hi Pranjal, On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > Hi Shane, > Yes, two separate LDP sessions are required for fate = separation of ipv4 and ipv6 fecs.=20 >=20 > Separation of ipv4 and ipv6 hello adjacencies are not required to = satisfy=20 > a) and b). Both can be achieved with single hello adjacency per = interface > per peering lsr-id with adjacency specific capabilities. I'm in agreement with you with respect to LDP sessions. With respect to LDP Hellos, you're suggesting that operators run either = IPv4-only Hello's or IPv6-only Hello's, (never both at the same time), = but through either one can discover the "(IPv4|IPv6) transport = capabilities" of a LDP peer and, based on that, establish an IPv4 and/or = IPv6 LDP session. Correct? -shane > Thanks, > Pranjal >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Shane Amante > Sent: Friday, March 02, 2012 11:34 PM > To: mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Mark, >=20 > I completely agree with all of your comments below. I too would = (strongly) prefer the option to allow operators to choose (via CLI) = whether to: > a) use separate transport to ensure there is no fate-sharing of IPv4 + = IPv6; or, > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, = other AF's) on a single session, for scale reasons. >=20 > -shane >=20 >=20 > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 >> (Pranjal) wrote: >>=20 >>>> =46rom an implementer/system designer's point of view I >>>> would think single hello adjacency with per adjacency >>>> capabilities would be right approach. >>=20 >> Pranjal, I appreciate that from a vendor perspective,=20 >> implementing it this way would make sense for large scale=20 >> deployments. >>=20 >> However, for some operators who may be using BGP or RSVP to=20 >> signal or nest a large number of LSP's, we would like to=20 >> have the option of choosing a discrete separation of IPv4=20 >> and IPv6 adjacencies for LDP. >>=20 >> If there are operators who aren't going to be looking at=20 >> scaling that many LSP's anytime in their network, they might=20 >> still prefer to eliminate adjacency fate-sharing. >>=20 >> I would propose that vendors implement both options,=20 >> allowing operators to choose (via CLI) which method they=20 >> would like to deploy in the field. There are many operators=20 >> out there who maintain separate BGP transport and policy=20 >> sessions for IPv4 and IPv6 AF's to protect themselves=20 >> against the problems fate-sharing could bring. This is why=20 >> some of us prefer to make our lives harder by going native,=20 >> dual-stack rather than 6PE :-). >>=20 >> So while I won't disagree with your opinion on using a=20 >> single adjacency for both AF's for scaling purposes, I would=20 >> certainly like to have the option to choose which method=20 >> suits me best in the wild. >>=20 >> Mark. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Tue Mar 6 00:20:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9505F21E80B1 for ; Tue, 6 Mar 2012 00:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+aza3ydCnPG for ; Tue, 6 Mar 2012 00:20:53 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id F06FD21E808C for ; Tue, 6 Mar 2012 00:20:52 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 751292A8002; Tue, 6 Mar 2012 09:20:48 +0100 (CET) Message-ID: <4F55C8DF.80200@pi.nu> Date: Tue, 06 Mar 2012 09:20:47 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , MPLS-TP ad hoc team , "draft-koike-mpls-tp-temporal-hitless-psm@tools.ietf.org" , Ross Callon , George Swallow , Adrian Farrel References: <4F327811.1000700@pi.nu> <4F3E8461.9070002@pi.nu> <4F5092A8.8000600@pi.nu> In-Reply-To: <4F5092A8.8000600@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] [AHMPLS-TP] Re: Addition on this poll - the IPR aspect (Was Re: Poll on draft-koike-mpls-tp-temporal-hitless-psm) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:20:54 -0000 Folks, this poll has ended with good support to make the draft a working group documents, and we have received the IPR statements from all co-authors. We have a new working group document! Can the authors please republish the document as draft-ietf-mpls-tp-temporal-hitless-psm-00 without any other changes than date and filename. /Loa for the mpkls wg co-chairs On 2012-03-02 10:28, Loa Andersson wrote: > All, > > this poll has ended. We have good support to make it a working > group document, however we will wait until we hear from all > authors regarding whether all IPR they are ware of has been > disclosed before we request that the document be posted as > a working group document. > > /Loa > > for the MPLS wg co-chairs > > On 2012-02-17 17:46, Loa Andersson wrote: >> All, >> >> this poll has been running for some time, according the process the >> wg chair outlined in a recent mail it should have been preceded >> by a mail reminding about IPRs. We didn't have that process really >> in place when the poll was started. So here comes the IPR remeinder. >> >> As you can see from the poll the wg chairs have sent out the authors >> have asked for draft-koike-mpls-tp-temporal-hitless-psm to be >> considered for adoption as a WG document. We would like to check >> whether there is IPR on the document that needs to be disclosed. >> We will weigh this in when we judge the consensus on the call for >> adoption. >> >> Are you aware of any IPR that applies to draft-koike-mpls-tp-temporal- >> hitless-psm? If so, has this IPR been disclosed in compliance with IETF >> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. This document will not advance to the next stage until a response >> has been received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> /Loa >> >> (as MPLS WG co-chair) >> >> >> >> On 2012-02-08 14:26, Loa Andersson wrote: >>> Working Group, >>> >>> this is to start a two week poll to see if there is support to make >>> >>> draft-koike-mpls-tp-temporal-hitless-psm-04 >>> >>> mpls working group drafts. >>> >>> Pleased send your comments to the mpls working group mailing list >>> (mpls@ietf.org). >>> >>> This poll ends February 22, 2012! >>> >>> Loa >>> for the mpls wg chairs >>> >>> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From internet-drafts@ietf.org Tue Mar 6 01:51:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8C21F86FF; Tue, 6 Mar 2012 01:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97gipGwKxLEF; Tue, 6 Mar 2012 01:51:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFA821F8701; Tue, 6 Mar 2012 01:51:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306095126.21520.33961.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 01:51:26 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:51:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Identifiers Following ITU-T Conventions Author(s) : Rolf Winter Eric Gray Huub van Helvoort Malcolm Betts Filename : draft-ietf-mpls-tp-itu-t-identifiers-03.txt Pages : 12 Date : 2012-03-06 This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-03= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t-identifiers-03.= txt From Rolf.Winter@neclab.eu Tue Mar 6 01:57:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65421F8880 for ; Tue, 6 Mar 2012 01:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C2akMfnvgGv for ; Tue, 6 Mar 2012 01:57:58 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2921F887F for ; Tue, 6 Mar 2012 01:57:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 55DEC28000086 for ; Tue, 6 Mar 2012 10:57:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0MQmbd8IVin for ; Tue, 6 Mar 2012 10:57:57 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 399F828000084 for ; Tue, 6 Mar 2012 10:57:52 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Mar 2012 10:57:48 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt Thread-Index: AQHM+37Mbur7weEc0kSDEiRbQBa1t5ZdBxYQ Date: Tue, 6 Mar 2012 09:57:52 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D25031AF4@DAPHNIS.office.hd> References: <20120306095126.21520.33961.idtracker@ietfa.amsl.com> In-Reply-To: <20120306095126.21520.33961.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:57:59 -0000 MPLS WG, this new version has expanded a lot based on comments received from the lis= t. While the amount of text has increased significantly, the actual content= has changed little. Most IDs defined in the document are equal to the ones= defined in RFC 6370 with the exception when global uniqueness is required = (the Global_ID is exchanged with the ICC_Operator_ID, an ID which is based = on the ICC rather than on the AS number). In addition the maintenance IDs d= iffer. Feedback highly appreciated.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Dienstag, 6. M=E4rz 2012 10:51 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt >=20 >=20 > 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. >=20 > Title : MPLS-TP Identifiers Following ITU-T Conventions > Author(s) : Rolf Winter > Eric Gray > Huub van Helvoort > Malcolm Betts > Filename : draft-ietf-mpls-tp-itu-t-identifiers-03.txt > Pages : 12 > Date : 2012-03-06 >=20 > This document specifies an extension to the identifiers to be used > in > the Transport Profile of Multiprotocol Label Switching (MPLS-TP). > Identifiers that follow IP/MPLS conventions have already been > defined. This memo augments that set of identifiers for MPLS-TP > management and OAM functions to include identifier information in a > format typically used by the ITU-T. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > identifiers-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > identifiers-03.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ietfc@btconnect.com Tue Mar 6 03:28:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC12F21F8821 for ; Tue, 6 Mar 2012 03:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP9fTbo+2cVl for ; Tue, 6 Mar 2012 03:28:54 -0800 (PST) Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id A834221F87BA for ; Tue, 6 Mar 2012 03:28:52 -0800 (PST) Received: from host86-163-139-217.range86-163.btcentralplus.com (HELO pc6) ([86.163.139.217]) by c2bthomr14.btconnect.com with SMTP id GNV93289; Tue, 06 Mar 2012 11:28:48 +0000 (GMT) Message-ID: <028e01ccfb83$d5566bc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" References: <007501ccd3c4$145e5900$3d1b0b00$@olddog.co.uk> <077E41CFFD002C4CAB7DFA4386A532640520A4E7@DEMUEXC014.nsn-intra.net> Date: Tue, 6 Mar 2012 11:28:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F55F4F0.003E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.6.103624:17:7.944, ip=86.163.139.217, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4F55F4F0.01B8,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:28:54 -0000 ----- Original Message ----- From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: ; Cc: Sent: Sunday, January 15, 2012 9:42 PM > Hi Adrian, > Thank you for your review. > We will make the edit and notify you when a new version is submitted. Mmmmm any prognosis as to when? Given the lively discussions on code point allocation, it would be good to see this progres. Tom Petch > Best regards, > Nurit and Luyuan > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > ext Adrian Farrel > Sent: Sunday, January 15, 2012 10:27 PM > To: draft-ietf-mpls-tp-oam-analysis.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis > > Hello, > > I have done my AD review of your draft. I have a list of small edits > I would like you to make before we issue the IETF last call. > > I will wait for a new revision. > > Thanks, > Adrian > > --- > > You have included the pre-November 2008 copyright statement. The first > version was posted after November 2008. Do you really need this > statement? > > --- > > Please clean up the unused reference [RFC 4385] > > --- > > In Section 2 > > It is recommended that any protocol solution, meeting one or more > > functional requirement(s), be the same for PWs, LSPs, and Sections. > > Is this recommendation made by this document or by the referenced > RFC 5860? If the latter, can you make this clear. If the former, I am > not sure of the context for your recommendation. > > --- > > In Section 2 > > The following document-set addresses the basic requirements listed > above: > > The third bullet does not seem to cite a document. > > --- > > Section 4 > > This section contains > > Editor's note: > > Only RFCs will be referenced in the final version of the document. > > Can you remove this now? > > You then have... > > The following table (Table 1) provides the summary of proactive > MPLS-TP OAM Fault Management toolset functions, associated tool/ > protocol, and the corresponding IETF RFCs or Internet drafts where > they are defined. > > There are no I-Ds in the table. Same applies to the text about each of > other tables. > > Also, in the three tables you have a column headed "RFCs / Internet > Drafts". Again, there are no I-Ds in the tables. > > --- > > Section 5.4 > > The protocols for Alarm Indication Signal (AIS) and A Link Down > Indication (LDI) are defined in [RFC 6427]. > > s/A/a/ > > --- > > Section 5.5 > > The RDI OAM function is supported by the use of Bidirectional > Forwarding Detection (BFD) Control Packets [RFC 6428???]. RDI is > only used for bidirectional connections and is associated with > proactive CC-CV activation. > > Please resolve "???" > > --- > > Section 7 > > I think you might summarise the security available for the different OAM > mechanisms and the issues that don't need to be addressed because of the > OAM running on the ACH. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From nurit.sprecher@nsn.com Tue Mar 6 05:50:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC0B21F8809 for ; Tue, 6 Mar 2012 05:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JagPXlfo0kNK for ; Tue, 6 Mar 2012 05:50:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id AB0F121F8777 for ; Tue, 6 Mar 2012 05:50:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q26DoBcm007035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 14:50:11 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q26Do3Th020838; Tue, 6 Mar 2012 14:50:10 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 14:50:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 14:50:04 +0100 Message-ID: In-Reply-To: <028e01ccfb83$d5566bc0$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis Thread-Index: Acz7jE2M+q+ZcKb0SI6jbwH1BZO7oQAE6DcQ References: <007501ccd3c4$145e5900$3d1b0b00$@olddog.co.uk> <077E41CFFD002C4CAB7DFA4386A532640520A4E7@DEMUEXC014.nsn-intra.net> <028e01ccfb83$d5566bc0$4001a8c0@gateway.2wire.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext t.petch" X-OriginalArrivalTime: 06 Mar 2012 13:50:05.0272 (UTC) FILETIME=[0916A580:01CCFBA0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4008 X-purgate-ID: 151667::1331041814-000033AC-9B488FF7/0-0/0-0 Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:50:35 -0000 Please expect to see it during the weekend. =20 p.s. did you refer to OAM analysis or OAM considerations? -----Original Message----- From: ext t.petch [mailto:ietfc@btconnect.com]=20 Sent: Tuesday, March 06, 2012 12:28 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: mpls@ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis ----- Original Message -----=20 From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: ; Cc: Sent: Sunday, January 15, 2012 9:42 PM > Hi Adrian, > Thank you for your review. > We will make the edit and notify you when a new version is submitted.=20 Mmmmm any prognosis as to when? Given the lively discussions on=20 code point allocation, it would be good to see this progres. Tom Petch > Best regards, > Nurit and Luyuan >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > ext Adrian Farrel > Sent: Sunday, January 15, 2012 10:27 PM > To: draft-ietf-mpls-tp-oam-analysis.all@tools.ietf.org > Cc: mpls@ietf.org > Subject: [mpls] AD review of draft-ietf-mpls-tp-oam-analysis >=20 > Hello, >=20 > I have done my AD review of your draft. I have a list of small edits > I would like you to make before we issue the IETF last call. >=20 > I will wait for a new revision. >=20 > Thanks, > Adrian >=20 > --- >=20 > You have included the pre-November 2008 copyright statement. The first > version was posted after November 2008. Do you really need this > statement? >=20 > --- >=20 > Please clean up the unused reference [RFC 4385] >=20 > --- >=20 > In Section 2 >=20 > It is recommended that any protocol solution, meeting one or more >=20 > functional requirement(s), be the same for PWs, LSPs, and Sections. >=20 > Is this recommendation made by this document or by the referenced=20 > RFC 5860? If the latter, can you make this clear. If the former, I am > not sure of the context for your recommendation. >=20 > --- >=20 > In Section 2 >=20 > The following document-set addresses the basic requirements listed > above: >=20 > The third bullet does not seem to cite a document. >=20 > --- > =20 > Section 4 >=20 > This section contains >=20 > Editor's note: > =20 > Only RFCs will be referenced in the final version of the document. >=20 > Can you remove this now? >=20 > You then have... >=20 > The following table (Table 1) provides the summary of proactive > MPLS-TP OAM Fault Management toolset functions, associated tool/ > protocol, and the corresponding IETF RFCs or Internet drafts where > they are defined. >=20 > There are no I-Ds in the table. Same applies to the text about each of > other tables. >=20 > Also, in the three tables you have a column headed "RFCs / Internet > Drafts". Again, there are no I-Ds in the tables. >=20 > --- >=20 > Section 5.4 >=20 > The protocols for Alarm Indication Signal (AIS) and A Link Down > Indication (LDI) are defined in [RFC 6427]. >=20 > s/A/a/ >=20 > --- >=20 > Section 5.5 >=20 > The RDI OAM function is supported by the use of Bidirectional > Forwarding Detection (BFD) Control Packets [RFC 6428???]. RDI is > only used for bidirectional connections and is associated with > proactive CC-CV activation. >=20 > Please resolve "???" >=20 > --- >=20 > Section 7 >=20 > I think you might summarise the security available for the different OAM > mechanisms and the issues that don't need to be addressed because of the > OAM running on the ACH. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From internet-drafts@ietf.org Tue Mar 6 09:31:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9AE21F866B; Tue, 6 Mar 2012 09:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgTl5URQndYO; Tue, 6 Mar 2012 09:31:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0059221F8652; Tue, 6 Mar 2012 09:31:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306173138.26058.88655.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 09:31:38 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 17:31:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : An Overview of the OAM Tool Set for MPLS based Transport= Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-08.txt Pages : 22 Date : 2012-03-06 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-08.txt From pranjal.dutta@alcatel-lucent.com Tue Mar 6 10:30:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95B21E8033 for ; Tue, 6 Mar 2012 10:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.306 X-Spam-Level: X-Spam-Status: No, score=-9.306 tagged_above=-999 required=5 tests=[AWL=1.293, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qODmUBTY0pyW for ; Tue, 6 Mar 2012 10:29:58 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 194C521F88EE for ; Tue, 6 Mar 2012 10:28:10 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q26IRijH019378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 12:27:47 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q26IRgZT005234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 23:57:43 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 6 Mar 2012 23:57:42 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Shane Amante Date: Tue, 6 Mar 2012 23:57:39 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaA Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> <71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net> <6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> In-Reply-To: <6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:30:00 -0000 Hi Shane, Yes, that's correct. We can run either ipv4 hellos or ipv6 hellos= and operator can choose whichever is best, based upon the operational nee= ds. Since the src ip addresses used by hello packets are not coupled with F= EC types so single hello can advertise various FEC capabilities.=20 If we run multiple ldp sessions between peering systems for fate s= eparation of ipv4 and ipv6 then there can be two separate hello adjacencies= over a single interface (each one associated with separate sessions) but i= n that case the LSR-IDS used would be different (we need to work for an ext= ension of RFC 5036). Thanks, Pranjal -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 Sent: Monday, March 05, 2012 10:13 PM To: Dutta, Pranjal K (Pranjal) Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); mpls@ietf.org;= Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Pranjal, On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > Hi Shane, > Yes, two separate LDP sessions are required for fate separation = of ipv4 and ipv6 fecs.=20 >=20 > Separation of ipv4 and ipv6 hello adjacencies are not required to=20 > satisfy > a) and b). Both can be achieved with single hello adjacency per=20 > interface per peering lsr-id with adjacency specific capabilities. I'm in agreement with you with respect to LDP sessions. With respect to LDP Hellos, you're suggesting that operators run either IPv= 4-only Hello's or IPv6-only Hello's, (never both at the same time), but thr= ough either one can discover the "(IPv4|IPv6) transport capabilities" of a = LDP peer and, based on that, establish an IPv4 and/or IPv6 LDP session. Co= rrect? -shane > Thanks, > Pranjal >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Shane Amante > Sent: Friday, March 02, 2012 11:34 PM > To: mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Mark, >=20 > I completely agree with all of your comments below. I too would (strongly= ) prefer the option to allow operators to choose (via CLI) whether to: > a) use separate transport to ensure there is no fate-sharing of IPv4 +=20 > IPv6; or, > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, othe= r AF's) on a single session, for scale reasons. >=20 > -shane >=20 >=20 > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K >> (Pranjal) wrote: >>=20 >>>> From an implementer/system designer's point of view I would think=20 >>>> single hello adjacency with per adjacency capabilities would be=20 >>>> right approach. >>=20 >> Pranjal, I appreciate that from a vendor perspective, implementing it=20 >> this way would make sense for large scale deployments. >>=20 >> However, for some operators who may be using BGP or RSVP to signal or=20 >> nest a large number of LSP's, we would like to have the option of=20 >> choosing a discrete separation of IPv4 and IPv6 adjacencies for LDP. >>=20 >> If there are operators who aren't going to be looking at scaling that=20 >> many LSP's anytime in their network, they might still prefer to=20 >> eliminate adjacency fate-sharing. >>=20 >> I would propose that vendors implement both options, allowing=20 >> operators to choose (via CLI) which method they would like to deploy=20 >> in the field. There are many operators out there who maintain=20 >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's to=20 >> protect themselves against the problems fate-sharing could bring.=20 >> This is why some of us prefer to make our lives harder by going=20 >> native, dual-stack rather than 6PE :-). >>=20 >> So while I won't disagree with your opinion on using a single=20 >> adjacency for both AF's for scaling purposes, I would certainly like=20 >> to have the option to choose which method suits me best in the wild. >>=20 >> Mark. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Tue Mar 6 10:30:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4EB21F858B for ; Tue, 6 Mar 2012 10:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.354 X-Spam-Level: X-Spam-Status: No, score=-7.354 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVjxOlDA+9qE for ; Tue, 6 Mar 2012 10:30:01 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B121E808F for ; Tue, 6 Mar 2012 10:28:34 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q26ISLXn023505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 12:28:24 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q26ISJFw022058 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 23:58:20 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 6 Mar 2012 23:58:19 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mtinka@globaltransit.net" Date: Tue, 6 Mar 2012 23:58:04 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7RxXYQ0XN4NbZS7KWehVZ77FOvQAf77sg Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.40384.mtinka@globaltransit.net> <201203061113.08085.mtinka@globaltransit.net> In-Reply-To: <201203061113.08085.mtinka@globaltransit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" , Kishore Tiruveedhula Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:30:15 -0000 Thanks Mark for the clarifications. Regards, Pranjal=20 -----Original Message----- From: Mark Tinka [mailto:mtinka@globaltransit.net]=20 Sent: Monday, March 05, 2012 7:13 PM To: Dutta, Pranjal K (Pranjal) Cc: Kishore Tiruveedhula; mpls@ietf.org; lizhong.jin@zte.com.cn; Aissaoui, = Mustapha (Mustapha) Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Tuesday, March 06, 2012 01:42:10 AM Dutta, Pranjal K (Pranjal) wrote: > [Pranjal] I agree. This is what we want. We shouldn't be restrictive=20 > in ldp-ipv6 draft, rather should provide options, else would hurt=20 > various current applicability scenarios on LDP which has been widely=20 > deployed. Agree. > [Pranjal] Just to clarify that "adjacency" separation does not give=20 > you fate separation. For fate separation we would need to separation=20 > of "sessions". Hello Adjacency and Session are two different concepts=20 > in LDP. > The current text in the draft makes it mandatory to have two separate=20 > hello adjacencies for the same "fate shared" session. This conflicts=20 > with the way we decided to move forward with various fec types. Please=20 > refer to my reply to your other mail on the various technical reasons=20 > why I am saying so. Apologies for collapsing here, I should have been more explicit (operator h= at, hehe). Yes, I do mean that we make discrete both adjacencies + sessions to achieve= a clean and clear separation of fate. Hope this clarifies my position. Mark. From mustapha.aissaoui@alcatel-lucent.com Fri Mar 2 11:26:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C7021E8019 for ; Fri, 2 Mar 2012 11:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.712 X-Spam-Level: X-Spam-Status: No, score=-8.712 tagged_above=-999 required=5 tests=[AWL=1.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMmJHvJNGgOO for ; Fri, 2 Mar 2012 11:26:06 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 69C3021E8048 for ; Fri, 2 Mar 2012 11:26:06 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q22JQ1jo006240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 13:26:01 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22JQ18d008063 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 2 Mar 2012 13:26:01 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 2 Mar 2012 13:26:01 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "Dutta, Pranjal K (Pranjal)" , Vishwas Manral Date: Fri, 2 Mar 2012 13:26:00 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dA= Message-ID: <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5DF53972F7E9134782DCE51624466FE50AD58117BBUSNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 X-Mailman-Approved-At: Tue, 06 Mar 2012 19:12:29 -0800 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:26:11 -0000 --_000_5DF53972F7E9134782DCE51624466FE50AD58117BBUSNAVSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also have an issue with the stability of such an implementation. The draf= t suggests in Section 6.1 - Transport connection establishment, that a TCP = connection with IPv6 should be preferred to one with IPv4 if both IPv4 and = IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first= and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is esta= blished, we tear down the IPv4 TCP connection and signal the IPv6 one. This= of course is not acceptable. In RFC 5036 compliant implementations, when a= new adjacency comes up to the same LSR-ID, we just associate it with the e= xisting TCP connection which was bootstrapped by the first Hello adjacency. Mustapha. ________________________________ From: Dutta, Pranjal K (Pranjal) Sent: Friday, March 02, 2012 1:22 PM To: Vishwas Manral Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Viswas, We raised one more point earlier on the following clau= se in the draft. Section 6.2 As outlined in section 2.5.5 of RFC5036, this draft describes that if an LSR has a dual-stack interface, which is enabled with both IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 LDP Link Hellos and must separately maintain the Hello adjacency for IPv4 and IPv6 on that interface. This ensures successful labeled IPv4 and labeled IPv6 traffic forwarding on a dual-stacked interface, as well as successful LDP peering using the appropriate transport on a multi-access interface (even if there are IPv4-only, IPv6-only and dual-stack LSRs connected to that multi-access interface). The draft mandates that two separate hello adjacencies should be maintained= on dual-stack - one for IPV4 and another for IPV6. We don't see any benefi= t or technical reason of running two separate adjacencies. 1. First of all, doing so does not provide fate separation any way. Bo= th IPV4 and IPV6 fecs are still exchanged over same LDP sessions. 2. This clause mandates that a transit network that is carrying IPV6 L= SPs must provision IPv6 interfaces. It is not mandatory that the transport= network itself be IPV6 in order to carry IPV6 traffic over its tunnels. Th= is is a very narrow interpretation of section 2.5.5 in RFC 5036. It's not = necessary that an IPV6 FEC should be resolved by an IPV6 only route next-ho= p. The hello adjacency can still be over an IPV4 link and IPV6 prefix can s= till be resolved by an IPV4 route next-hop. It's not necessary that source = of hellos be IPv6 or transport address of TCP session be ipv6. 3. This clause has unnecessary scalability implications. We do run ver= y large number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls = or similar deployments. This clause requires to run 20K hello adjacencies w= hich has scalability implications. On theory there may not much difference = between 10K and 20K but in real implementations there is. If we allow separ= ation of sessions for fate separation of IPV4 and IPV6 then it would become= 40K adjacencies. We can limit to only one hello adjacency per interface yet address the dual= stack issue. A graceful solution is to come up with a notion of LDP adjace= ncy specific capabilities (similar to LDP capabilities that applies to enti= re sessions) that would benefit multiple purposes. For example, we have mul= tiple ECMP Links between neighboring LSRs A and B as shows below. +----------------L1------------------+ | = | A ----------------L2----------------- B | = | +----------------L3------------------+ The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe= r IPV4 OR ipv6 addresses but not both. Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3= are IPv6 capable. Then hellos exchanged over link would advertise capabilities as below: L1 would carry capabilities - Ipv4 + Mcast L2 would carry capabilities - ipv4 + ipv6 + Mcast L3 would carry capabilities - ipv4 + ipv6 >From an implementer/system designer's point of view I would think single he= llo adjacency with per adjacency capabilities would be right approach. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 5:11 PM To: Dutta, Pranjal K (Pranjal) Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwa= s.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org" > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > > alcatel-lucent.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. --_000_5DF53972F7E9134782DCE51624466FE50AD58117BBUSNAVSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 also have an issue with the stability of such an implementation. The draft= =20 suggests in Section 6.1 -=20 Transport connection establishment, that a TCP connection with IPv6 should = be=20 preferred to one with IPv4 if=20 both IPv4 and IPv6 adjacencies exist. This means that if the IPv4 adjacency= came=20 up first and boot straps the IPv4 TCP connection, as soon as the IPv6 hello= is=20 established, we tear down the IPv4 TCP connection and signal the IPv6 one. = This=20 of course is not acceptable. In RFC 5036 compliant implementations, when a = new=20 adjacency comes up to the same LSR-ID, we just associate it with the existi= ng=20 TCP connection which was bootstrapped by the first Hello=20 adjacency.
 
Mustapha.=

From: Dutta, Pranjal K (Pranjal)=20
Sent: Friday, March 02, 2012 1:22 PM
To: Vishwas=20 Manral
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha);=20 mpls@ietf.org
Subject: RE: [mpls] Comments on=20 draft-ietf-mpls-ldp-ipv6-06

Hi=20 Viswas,

  &nbs= p;            &= nbsp;    =20 We raised one more point earlier on the following clause in the=20 draft.

 

Section 6.2=20

 

   As outlined in section 2.5.5 of RFC5036, this=
 draft describes that
   if an LSR ha=
s a dual-stack interface, which is enabled with both
   IPv4 and IPv6 LDP, then the LSR must periodically send b=
oth IPv4 and
   IPv6 LDP Link Hellos =
and must separately maintain the Hello
<=
FONT size=3D2 face=3D"Courier New"> &n=
bsp; adjacency for IPv4 and IPv6 on that interface.
 
     This ensur=
es successful labeled IPv4 and labeled IPv6 traffic
     forwarding on a dual-stacked interface, as we=
ll as successful LDP
     p=
eering using the appropriate transport on a multi-access<=
/FONT>
     interface (even if there are IPv4-only, =
IPv6-only and dual-stack
   &nbs=
p; LSRs connected to that multi-access interface).=

 
 
The draft mandates that two separate h=
ello adjacencies should be maintained on dual-stack – one for IPV4 an=
d another for IPV6. We don’t see any benefit or technical reason of r=
unning two separate adjacencies.  
=
 
1.      =
First of all, doing so does not provide fate s=
eparation any way. Both IPV4 and IPV6 fecs are still exchanged over same LD=
P sessions. 
&nb=
sp;
2.   =
;   This clause=
 mandates that a transit network that is carrying IPV6 LSPs must provi=
sion IPv6 interfaces.  It is not mandatory that the transport network =
itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a v=
ery narrow interpretation of section 2.5.5 in  RFC 5036. It’s no=
t necessary that an IPV6 FEC should be resolved by an IPV6 only route next-=
hop. The hello adjacency can still be over an IPV4 link and IPV6 prefix can=
 still be resolved by an IPV4 route next-hop. It’s not necessary that=
 source of hellos be IPv6 or transport address of TCP session be ipv6.=

 
3.   &nbs=
p;  This clause has =
unnecessary scalability implications. We do run very large number of LDP ad=
jacencies/sessions (e.g 10K) in mobility backhauls or similar deployments. =
This clause requires to run 20K hello adjacencies which has scalability imp=
lications. On theory there may not much difference between 10K and 20K but =
in real implementations there is. If we allow separation of sessions for fa=
te separation of IPV4 and IPV6 then it would become 40K adjacencies.
 
We can limit to o=
nly one hello adjacency per interface yet address the dual stack issue. A g=
raceful solution is to come up with a notion of LDP adjacency specific capa=
bilities (similar to LDP capabilities that applies to entire sessions) that=
 would benefit multiple purposes. For example, we have multiple ECMP Links =
between neighboring LSRs A and B as shows below.
 
      &=
nbsp;           &nbs=
p;            &=
nbsp;   +----------------L1------------------+<=
/FONT>
    &nb=
sp;            =
            &nb=
sp;     |       &nbs=
p;            &=
nbsp;           &nbs=
p;            |=

  &=
nbsp;           &nbs=
p;            &=
nbsp;      A ----------------L2----------------- B=

 &n=
bsp;            =
;            &n=
bsp;        |    &nb=
sp;            =
            &nb=
sp;            =
   |
           &=
nbsp;           &nbs=
p;           +-----------=
-----L3------------------+
 
The hello adjacencies over L1, L2 and L3 are IP4 interf=
aces are using either IPV4 OR ipv6 addresses but not both.
 <=
/FONT>
Link L1, L2 are multicast c=
apable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3 are IPv6 capable. 
 
Then hellos exchan=
ged over link would advertise capabilities as below:
<=
o:p> 
L1 would carry capabilities – Ipv4 + Mcast=

 &n=
bsp;    L2 would carry capabilities – ipv4 + ipv6 + Mc=
ast
 =
;     L3 would carry capabilities – ipv4 + ipv6 <=
o:p>
&nbs=
p;
<=
SPAN style=3D"FONT-FAMILY: Arial; COLOR: navy; FONT-SIZE: 10pt"> 
From an implemente=
r/system designer’s point of view I would think single hello adjacenc=
y with per adjacency capabilities would be right approach. 
 =

Thanks,<=
/FONT>
Pranjal <=
/FONT>


 










From:=20
Vishwas Manral=20
[mailto:vishwas.ietf@gmail.com] 
Sent: Wednesday, February 29, 2012 5=
:11=20
PM
To: Dutta, Pranjal K (Pranjal)
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org
Subject: Re: [mpls] Comments on=20
draft-ietf-mpls-ldp-ipv6-06


 


Hi Lizhong/ Pranja=
l/=20
Mustapha,

So the two main comments that have come after last call=20
are:

1. Allow for separation of sessions along with the adjacency.2.=20
Allow for an IPv6 based LSR-ID.

The second could lead to changes req=
uired=20
in both OSPF and IS-IS, as well because the new LSR ID would then need to b=
e=20
exchanged. We could treat it as an enhancement instead in my view. Do you=20
agree?

Thanks,
Vishwas




On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-luce=
nt.com>=20
wrote:






Yes, I support t=
hat=20
too. There would be network management issues with mapping of 4 byte LSR-ID=
 to=20
an IPV6 remote address.


Most of the=20
implementations I know off usually maps 4 byte of the LSR-ID with a local i=
pv4=20
interface address in the system.


 


Thanks,


Pranjal


 










From: Lizhong=20
Jin [mailto:lizhong.jin@zte.com.cn] 
Sent: Wednesday, February 29, 2012 4=
:57=20
PM
To: Aissaoui, Mustapha (Mustapha)
Cc: mpls@ietf.org; Dutta, Pranj=
al=20
K (Pranjal); vishwas.ietf@gmail.com





Subject: RE: [mpls] Comments on=20
draft-ietf-mpls-ldp-ipv6-06


 


 






Hi Mustapha, I=
 agree, and=20
I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in my fi=
rst=20
email. 

Thanks 
Lizhong 
  
"=
Aissaoui,=20
Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> wrote 2012/03/=
01=20
04:35:41:

> Hi Lizhong, 
> I act=
ually=20
think that we would need to define a new one which will 
> accomodate=
 an=20
IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6=20
network will not be possible. I cannot see that operators
> will star=
t=20
maintaining a mapping of some global non routable LSR-id 
> value to =
an=20
IPv6 loopback interface on each router in the network. 
&=
gt;=20
  
> Mustapha.=
=20

> From: mpls-bounces@ietf.org=
=20
[mailto:mpls-bounces@ietf.org] On Behalf Of 
> Aissaoui, Mustapha (Mustapha)
> Sent: Tu=
esday,=20
February 07, 2012 10:12 AM
> To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
> Cc: mpls@ietf.org
> Sub=
ject: Re:=20
[mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>=20
Lizhong, 
> the existing LSR-id will=
 do the=20
job and should be supported since 
> the LSR-id need not be an IP add=
ress.=20
Most implementations will 
> actually populate the field with a /32=20
address in IPv4 and thus If 
> necessary we could define a new format=
 to=20
allow the use of /128 IPv6addresses. 
>=20
  
> Mustapha.=
=20

> 
> From: Lizhong J=
in=20
[mailto:lizhong.jin@zte.com.cn] 
> Sent: Monday, February=
 06,=20
2012 10:23 PM
> To: Dutta, Pranjal=20
K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, 
> Mustapha=20
(Mustapha)
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Comments on=20
draft-ietf-mpls-ldp-ipv6-06

> 
> Hi, 
> I =
wonder=20
if it is feasible to use LDP capability to advertise IPv6 
> FEC with=
out=20
IPv6 adjacency, and only use one adjacency for LDP 
> session in=20
dual-stack network. LDP capability is per node 
> capability, not per=
=20
interface capability. But for LDP to choose the 
> correct downstream=
=20
session and output interface for each FEC, it 
> should also check if=
 the=20
output interface is LDP enabled or not. The
> link adjacency could be=
 used=20
to assist such kind of checking. 
> 
> However, IMO, it is valu=
able=20
to allow two independent LDP sessions 
> for IPv4 and IPv6 as an opti=
on.=20
Regarding the format definition in 
> RFC5036, we may need new LDP ve=
rsion=20
number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID fo=
r=20
IPv6 with IPv4, but I prefer 
> new format of LSR-ID. 
> 
&g=
t;=20
Regards 
> Lizhong 
> 
> 
> >=20
----------------------------------------------------------------------
&=
gt;=20
> 
> > Message: 1
> > Date: Tue, 7 Feb 2012 05:28:21=20
+0530
> > From: "Dutta, Pranjal=20
K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > To:=20
Vishwas Manral <vishwas.ietf@gmail.com>
> > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > =
 =20
 <mustapha.aissaoui@alcatel-lucent.com>,   "mpls@ietf.org"
> &g=
t;  =20
 <mpls@ietf.org>
> > Subject: Re: [mpls] Comm=
ents on=20
draft-ietf-mpls-ldp-ipv6-06
> > Message-ID:
> >  =20
 <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.
=
>=20
> alcatel-lucent.com>
> >    
&g=
t; >=20
Content-Type: text/plain; charset=3D"us-ascii"
> > 
> > I=
 would=20
rather for complete separation with multiple lsr-id because 
> > h=
aving=20
separate link adjacencies does not really solved any problem.
> > =
Since=20
hello adjacencies are associated with a link, still fate 
> > shar=
ing=20
would continue over the single ldp/tcp session for IPV4 and IPV6.
> &=
gt;=20
Having IPV4 and IPV6 specific hello adjacencies over a link would 
> =
>=20
only decide whether such a link is to be programmed for IPV4 or IPV6
>=
;=20
> egress traffic but I see it as overkill and unnecessary scalability=20
impacts.
> > 
> > Thanks,
> > Pranjal
> &g=
t;=20

>=20
--------------------------------------------------------
> ZTE Inform=
ation=20
Security Notice: The information contained in this 
> mail is solely=
=20
property of the sender's organization. This mail 
> communication is=
=20
confidential. Recipients named above are obligated 
> to maintain sec=
recy=20
and are not permitted to disclose the contents 
> of this communicati=
on to=20
others.
> This email and any files transmitted with it are confidenti=
al=20
and 
> intended solely for the use of the individual or entity to who=
m=20
they
> are addressed. If you have received this email in error please=
=20

> notify the originator of the message. Any views expressed in this=
=20

> message are those of the individual sender.
> This message h=
as=20
been scanned for viruses and Spam by ZTE Anti-Spam=20
system.


 
<= /HTML> --_000_5DF53972F7E9134782DCE51624466FE50AD58117BBUSNAVSXCHMBSC_-- From pranjal.dutta@alcatel-lucent.com Fri Mar 2 11:37:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6D221F85FB for ; Fri, 2 Mar 2012 11:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.078 X-Spam-Level: X-Spam-Status: No, score=-7.078 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdXQppakjBFB for ; Fri, 2 Mar 2012 11:37:32 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 886AD21F85F8 for ; Fri, 2 Mar 2012 11:37:32 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q22JbMDC029608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 13:37:25 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22JbMW6001570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2012 01:07:22 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 3 Mar 2012 01:07:22 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , Vishwas Manral Date: Sat, 3 Mar 2012 01:07:18 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CAB88INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Tue, 06 Mar 2012 19:12:29 -0800 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:37:38 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CAB88INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, this approach would lead to all "kludgy" implementations. Due to race = conditions between UDP based LDP hellos and TCP connections (since they are= independent channels) it may lead to states of continually flapping sessio= ns. Thanks, Pranjal ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Friday, March 02, 2012 11:26 AM To: Dutta, Pranjal K (Pranjal); Vishwas Manral Cc: Lizhong Jin; mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 I also have an issue with the stability of such an implementation. The draf= t suggests in Section 6.1 - Transport connection establishment, that a TCP = connection with IPv6 should be preferred to one with IPv4 if both IPv4 and = IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first= and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is esta= blished, we tear down the IPv4 TCP connection and signal the IPv6 one. This= of course is not acceptable. In RFC 5036 compliant implementations, when a= new adjacency comes up to the same LSR-ID, we just associate it with the e= xisting TCP connection which was bootstrapped by the first Hello adjacency. Mustapha. ________________________________ From: Dutta, Pranjal K (Pranjal) Sent: Friday, March 02, 2012 1:22 PM To: Vishwas Manral Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Viswas, We raised one more point earlier on the following clau= se in the draft. Section 6.2 As outlined in section 2.5.5 of RFC5036, this draft describes that if an LSR has a dual-stack interface, which is enabled with both IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 LDP Link Hellos and must separately maintain the Hello adjacency for IPv4 and IPv6 on that interface. This ensures successful labeled IPv4 and labeled IPv6 traffic forwarding on a dual-stacked interface, as well as successful LDP peering using the appropriate transport on a multi-access interface (even if there are IPv4-only, IPv6-only and dual-stack LSRs connected to that multi-access interface). The draft mandates that two separate hello adjacencies should be maintained= on dual-stack - one for IPV4 and another for IPV6. We don't see any benefi= t or technical reason of running two separate adjacencies. 1. First of all, doing so does not provide fate separat= ion any way. Both IPV4 and IPV6 fecs are still exchanged over same LDP sess= ions. 2. This clause mandates that a transit network that is = carrying IPV6 LSPs must provision IPv6 interfaces. It is not mandatory tha= t the transport network itself be IPV6 in order to carry IPV6 traffic over = its tunnels. This is a very narrow interpretation of section 2.5.5 in RFC = 5036. It's not necessary that an IPV6 FEC should be resolved by an IPV6 onl= y route next-hop. The hello adjacency can still be over an IPV4 link and IP= V6 prefix can still be resolved by an IPV4 route next-hop. It's not necessa= ry that source of hellos be IPv6 or transport address of TCP session be ipv= 6. 3. This clause has unnecessary scalability implications= . We do run very large number of LDP adjacencies/sessions (e.g 10K) in mobi= lity backhauls or similar deployments. This clause requires to run 20K hell= o adjacencies which has scalability implications. On theory there may not m= uch difference between 10K and 20K but in real implementations there is. If= we allow separation of sessions for fate separation of IPV4 and IPV6 then = it would become 40K adjacencies. We can limit to only one hello adjacency per interface yet address the dual= stack issue. A graceful solution is to come up with a notion of LDP adjace= ncy specific capabilities (similar to LDP capabilities that applies to enti= re sessions) that would benefit multiple purposes. For example, we have mul= tiple ECMP Links between neighboring LSRs A and B as shows below. +----------------L1------------------+ | = | A ----------------L2----------------- B | = | +----------------L3------------------+ The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe= r IPV4 OR ipv6 addresses but not both. Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3= are IPv6 capable. Then hellos exchanged over link would advertise capabilities as below: L1 would carry capabilities - Ipv4 + Mcast L2 would carry capabilities - ipv4 + ipv6 + Mcast L3 would carry capabilities - ipv4 + ipv6 >From an implementer/system designer's point of view I would think single he= llo adjacency with per adjacency capabilities would be right approach. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 5:11 PM To: Dutta, Pranjal K (Pranjal) Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwa= s.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org" > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > > alcatel-lucent.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. --_000_C584046466ED224CA92C1BC3313B963E09F00CAB88INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, this approach would lead to all &= #8220;kludgy” implementations. Due to race conditions between UDP based LDP hellos and TC= P connections (since they are independent channels) it may lead to states of continually flapping sessions.

 

Thanks,

Pranjal

 

From: Aissaoui, Mustapha (Mustapha)
Sent: Friday, March 02, 2012= 11:26 AM
To: Dutta, Pranjal K (Pranjal); Vishwas = Manral
Cc: Lizhong Jin; mpls@ietf.org
Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

I also have an issue with the stability of such an implementation. The draft suggests in Section 6= .1 - Transport connection establishment, that a TCP connection with IPv6 should = be preferred to one with IPv4 if both IPv4 and IPv6 adjacencies exist. Th= is means that if the IPv4 adjacency came up first and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is established, we tear down the IPv4= TCP connection and signal the IPv6 one. This of course is not acceptable. In RF= C 5036 compliant implementations, when a new adjacency comes up to the same LSR-ID, we just associate it with the existing TCP connection which was bootstrapped by the first Hello adjacency.

 

Mustapha.

 

From:= = Dutta, Pranjal K (Pranjal)
Sent: Friday, March 02, 2012= 1:22 PM
To: Vishwas Manral
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org
Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

Hi Viswas,

      &n= bsp;            = ;  We raised one more point earlier on the following clause in the draft.=

 

Section 6.2 <= /p>

 

&=
nbsp;  As outlined in section 2.5.5 of RFC5036, this draft describes t=
hat
  =
 if an LSR has a dual-stack interface, which is enabled with both
  =
 IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and<=
/o:p>
  =
 IPv6 LDP Link Hellos and must separately maintain the Hello
  =
 adjacency for IPv4 and IPv6 on that interface.
 <=
/o:p>
  =
   This ensures successful labeled IPv4 and labeled IPv6 traffic<=
o:p>
  =
   forwarding on a dual-stacked interface, as well as successful =
LDP
  =
   peering using the appropriate transport on a multi-access=

  =
   interface (even if there are IPv4-only, IPv6-only and dual-sta=
ck
  =
   LSRs connected to that multi-access interface).
 <=
/o:p>
 <=
/o:p>
The draft mandates that two separate hello adjacencies should b=
e maintained on dual-stack – one for IPV4 and another for IPV6. We do=
n’t see any benefit or technical reason of running two separate adjac=
encies.  
 
1.      =
            &nb=
sp;  Firs=
t of all, doing so does not provide fate separation any way. Both IPV4 and =
IPV6 fecs are still exchanged over same LDP sessions. 
 
2.      =
            &nb=
sp;  This=
 clause mandates that a transit network that=
 is carrying IPV6 LSPs must provision IPv6 interfaces.  It is not mand=
atory that the transport network itself be IPV6 in order to carry IPV6 traf=
fic over its tunnels. This is a very narrow interpretation of section 2.5.5=
 in  RFC 5036. It’s not necessary that an IPV6 FEC should be res=
olved by an IPV6 only route next-hop. The hello adjacency can still be over=
 an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-h=
op. It’s not necessary that source of hellos be IPv6 or transport add=
ress of TCP session be ipv6.
 
3.      =
            &nb=
sp;  This=
 clause has unnecessary scalability implications. We do run very large numb=
er of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar d=
eployments. This clause requires to run 20K hello adjacencies which has sca=
lability implications. On theory there may not much difference between 10K =
and 20K but in real implementations there is. If we allow separation of ses=
sions for fate separation of IPV4 and IPV6 then it would become 40K adjacen=
cies.
 
=
We can limit to only one hello adjacency per interface yet address the dual=
 stack issue. A graceful solution is to come up with a notion of LDP adjace=
ncy specific capabilities (similar to LDP capabilities that applies to enti=
re sessions) that would benefit multiple purposes. For example, we have mul=
tiple ECMP Links between neighboring LSRs A and B as shows below.
 
=
            &nb=
sp;            =
          +----------------L1-=
-----------------+
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
           A ------------=
----L2----------------- B
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
            +-------=
---------L3------------------+
 
=
The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe=
r IPV4 OR ipv6 addresses but not both.
<=
font
size=3D2 color=3Dnavy face=3DArial> 
=
Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3=
 are IPv6 capable. 
 
=
Then hellos exchanged over link would advertise capabilities as below:=

 
L1 would carry capa=
bilities – Ipv4 + Mcast
      L2 would carry capabilities R=
11; ipv4 + ipv6 + Mcast
      L3 would carry capabilities R=
11; ipv4 + ipv6 
 
=
 
From an implementer/system designer’s point of view I wou=
ld think single hello adjacency with per adjacency capabilities would be ri=
ght approach. 
 
=
Thanks,
Pranjal 



 















From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=
 

Sent: Wednesday, February 29=
, 2012
5:11 PM

To: Dutta,
 Pranjal K (Pranjal)

Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org

Subject: Re: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06






 



Hi Lizhong/ Pranj=
al/
Mustapha,



So the two main comments that have come after last call are:



1. Allow for separation of sessions along with the adjacency.

2. Allow for an IPv6 based LSR-ID.



The second could lead to changes required in both OSPF and IS-IS, as well
because the new LSR ID would then need to be exchanged. We could treat it a=
s an
enhancement instead in my view. Do you agree?



Thanks,

Vishwas






On Wed, Feb 29, 2012 at 5:03 PM, Dutta,
 Pranjal K (Pranjal) <pranjal.dutta@alcatel-luce=
nt.com>
wrote:









Yes, I support that too. There would be network management issu=
es
with mapping of 4 byte LSR-ID to an IPV6 remote address.=




Most of the implementations I know off usually maps 4 byte of t=
he
LSR-ID with a local ipv4 interface address in the system.



 



Thanks,



Pranjal



 















From: Lizhong Jin [mailto:lizhong.jin@zte.co=
m.cn]


Sent: Wednesday, February 29=
, 2012
4:57 PM

To: Aissaoui,
 Mustapha (Mustapha)

Cc: mpls@ietf.org; Dutta, Pra=
njal K
(Pranjal); vish=
was.ietf@gmail.com








Subject: RE: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06









 



&nb=
sp;









Hi Mustapha, 

I
agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed o=
ut
in my first email. 



Thanks


Lizhong


 




"Aissaoui, Mustapha (Mustapha)" <must=
apha.aissaoui@alcatel-lucent.com>
wrote 2012/03/01 04:35:41:



> Hi Lizhong, 

> I
actually think that we would need to define a new one which will 

> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id 
> value to an IPv6 loopback interface on each router in the network.


>
  

>
Mustapha. 

>
From: mpls-bounc=
es@ietf.org
[mailto:mpls-bou=
nces@ietf.org]
On Behalf Of 

> Aissaoui, Mustapha (Musta=
pha)

> Sent: Tuesday, February 07, 2012 10:12 AM

> To: Lizhong Jin; Dutta, Pranjal K
(Pranjal); vish=
was.ietf@gmail.com

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



>
Lizhong, 

>
the existing LSR-id will do the job and should be supported since 

> the LSR-id need not be an IP address. Most implementations will 

> actually populate the field with a /32 address in IPv4 and thus If 
> necessary we could define a new format to allow the use of /128
IPv6addresses. 

>
  

>
Mustapha. 

> 

> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] 

> Sent: Monday, February 06, 2012 10:23 PM

> To: Dutta, Pranjal K (Pra=
njal);
vishwas.ietf@gm=
ail.com;
Aissaoui, 

> Mustapha (Mustapha)

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



> 

> Hi, 

> I wonder if it is feasible to use LDP capability to advertise IPv6 
> FEC without IPv6 adjacency, and only use one adjacency for LDP 

> session in dual-stack network. LDP capability is per node 

> capability, not per interface capability. But for LDP to choose the 
> correct downstream session and output interface for each FEC, it 

> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking. 

> 

> However, IMO, it is valuable to allow two independent LDP sessions 
> for IPv4 and IPv6 as an option. Regarding the format definition in 
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer 

> new format of LSR-ID. 

> 

> Regards 

> Lizhong 

> 

> 

> >
----------------------------------------------------------------------

> > 

> > Message: 1

> > Date: Tue, 7 Feb 2012 05:28:21 +0530

> > From: "Dutta, Pranjal K
(Pranjal)" <pranjal.dutta@alcatel-lucent.com>

> > To: Vishwas Manral &=
lt;vishwas.ietf@gmail=
.com>

> > Cc: "Aissaoui, Mustapha
\(Mustapha\)"

> >    <mustapha.aissaoui@alcatel-lucent.com>,   &quo=
t;mpls@ietf.org"

> >    <mpls@ietf.org>

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> > Message-ID:

> >  
 <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.

> > alcatel-l=
ucent.com>

> >    

> > Content-Type: text/plain; charset=3D"us-ascii"

> > 

> > I would rather for complete separation with multiple lsr-id becau=
se 

> > having separate link adjacencies does not really solved any probl=
em.

> > Since hello adjacencies are associated with a link, still fate 
> > sharing would continue over the single ldp/tcp session for IPV4 a=
nd
IPV6.

> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
 

> > only decide whether such a link is to be programmed for IPV4 or I=
PV6

> > egress traffic but I see it as overkill and unnecessary scalabili=
ty
impacts.

> > 

> > Thanks,

> > Pranjal

> > 

>
--------------------------------------------------------

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 

> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.

> This email and any files transmitted with it are confidential and 

> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 

> notify the originator of the message. Any views expressed in this 

> message are those of the individual sender.

> This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.


















 
--_000_C584046466ED224CA92C1BC3313B963E09F00CAB88INBANSXCHMBSA_-- From vishwas.ietf@gmail.com Fri Mar 2 11:50:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2621F84A0 for ; Fri, 2 Mar 2012 11:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpBgN6-dRjJV for ; Fri, 2 Mar 2012 11:49:58 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7D6621F849A for ; Fri, 2 Mar 2012 11:49:57 -0800 (PST) Received: by obbta4 with SMTP id ta4so973obb.31 for ; Fri, 02 Mar 2012 11:49:57 -0800 (PST) Received-SPF: pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.13.8 as permitted sender) client-ip=10.182.13.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of vishwas.ietf@gmail.com designates 10.182.13.8 as permitted sender) smtp.mail=vishwas.ietf@gmail.com; dkim=pass header.i=vishwas.ietf@gmail.com Received: from mr.google.com ([10.182.13.8]) by 10.182.13.8 with SMTP id d8mr4656183obc.36.1330717797625 (num_hops = 1); Fri, 02 Mar 2012 11:49:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vzW1e1OJBmvYqa1g8rskOK0WEcrWhYfXG9LREAZclf0=; b=PuVzFvBaGtE4JhMkjoIz7zYnidTMN/nQ2sQBuvKUQcf0J3RB194vp/PpW79w0lLKuG uOlJBFeH50rYcwWCD9EEDK98hHq5ur/XajkrMtTFlU86FQR0oWyqQySLCSDvrBMAovXu tM36mNFfddAL9zwg6j1707CxLzi3x7/QZH5PDNQb53A3sof9VCddQUOjbXd7v/s42Zeb exxm7K9xOIYjtvNOyLrA965s5SomjogCUFtsQmaBIFAAk4paaGyWpiRW1mjqB2hu4HAI +/yVmlSRYhSNSABxUkrtOq1/Hpy1FFiRm4/7hEFxdrN6/nUJJNXeFDSvvZqOL9G0x6Bt dBGg== MIME-Version: 1.0 Received: by 10.182.13.8 with SMTP id d8mr3966757obc.36.1330717797487; Fri, 02 Mar 2012 11:49:57 -0800 (PST) Received: by 10.182.165.1 with HTTP; Fri, 2 Mar 2012 11:49:57 -0800 (PST) In-Reply-To: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Date: Fri, 2 Mar 2012 11:49:57 -0800 Message-ID: From: Vishwas Manral To: "Dutta, Pranjal K (Pranjal)" Content-Type: multipart/alternative; boundary=f46d044481639d942d04ba47e1a9 X-Mailman-Approved-At: Tue, 06 Mar 2012 19:12:29 -0800 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:50:00 -0000 --f46d044481639d942d04ba47e1a9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pranjal/ Mustapha, This has been discussed a few times over already. If we use the option of not preferring an address family over the other (configurable of course), what can end up happening, is that we do not know what transport a session is running over. Thanks, Vishwas On Fri, Mar 2, 2012 at 11:37 AM, Dutta, Pranjal K (Pranjal) < pranjal.dutta@alcatel-lucent.com> wrote: > ** > > Yes, this approach would lead to all =93kludgy=94 implementations. Due to= race > conditions between UDP based LDP hellos and TCP connections (since they a= re > independent channels) it may lead to states of continually flapping > sessions.**** > > ** ** > > Thanks,**** > > Pranjal**** > > ** ** > ------------------------------ > > *From:* **Aissaoui, Mustapha** (Mustapha) > *Sent:* Friday, March 02, 2012 11:26 AM > *To:* **Dutta, Pranjal K** (Pranjal); **Vishwas Manral** > *Cc:* Lizhong Jin; **mpls@ietf.org > ** > *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > **** > > ** ** > > I also have an issue with the stability of such an implementation. The > draft suggests in Section 6.1 - Transport connection establishment, that > a TCP connection with IPv6 should be preferred to one with IPv4 if both > IPv4 and IPv6 adjacencies exist. This means that if the IPv4 adjacency ca= me > up first and boot straps the IPv4 TCP connection, as soon as the IPv6 hel= lo > is established, we tear down the IPv4 TCP connection and signal the IPv6 > one. This of course is not acceptable. In RFC 5036 compliant > implementations, when a new adjacency comes up to the same LSR-ID, we jus= t > associate it with the existing TCP connection which was bootstrapped by t= he > first Hello adjacency.**** > > **** > > Mustapha.**** > > ** ** > ------------------------------ > > *From:* **Dutta, Pranjal K** (Pranjal) > *Sent:* Friday, March 02, 2012 1:22 PM > *To:* **Vishwas Manral** > *Cc:* Lizhong Jin; **Aissaoui, Mustapha** (Mustapha); **mpls@ietf.org** > *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06**** > > Hi Viswas,**** > > We raised one more point earlier on the following > clause in the draft.**** > > ** ** > > Section 6.2 **** > > ** ** > > As outlined in section 2.5.5 of RFC5036, this draft describes that**** > > if an LSR has a dual-stack interface, which is enabled with both**** > > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and**= ** > > IPv6 LDP Link Hellos and must separately maintain the Hello**** > > adjacency for IPv4 and IPv6 on that interface.**** > > ** ** > > This ensures successful labeled IPv4 and labeled IPv6 traffic**** > > forwarding on a dual-stacked interface, as well as successful LDP***= * > > peering using the appropriate transport on a multi-access**** > > interface (even if there are IPv4-only, IPv6-only and dual-stack**** > > LSRs connected to that multi-access interface).**** > > ** ** > > ** ** > > The draft mandates that two separate hello adjacencies should be maintain= ed on dual-stack =96 one for IPV4 and another for IPV6. We don=92t see any = benefit or technical reason of running two separate adjacencies. **** > > ** ** > > **1. **First of all, doing so does not provide fate s= eparation any way. Both IPV4 and IPV6 fecs are still exchanged over same LD= P sessions. **** > > ** ** > > **2. **This clause mandates that a transit network th= at is carrying IPV6 LSPs must provision IPv6 interfaces. It is not mandato= ry that the transport network itself be IPV6 in order to carry IPV6 traffic= over its tunnels. This is a very narrow interpretation of section 2.5.5 in= RFC 5036. It=92s not necessary that an IPV6 FEC should be resolved by an = IPV6 only route next-hop. The hello adjacency can still be over an IPV4 lin= k and IPV6 prefix can still be resolved by an IPV4 route next-hop. It=92s n= ot necessary that source of hellos be IPv6 or transport address of TCP sess= ion be ipv6.**** > > ** ** > > **3. **This clause has unnecessary scalability implic= ations. We do run very large number of LDP adjacencies/sessions (e.g 10K) i= n mobility backhauls or similar deployments. This clause requires to run 20= K hello adjacencies which has scalability implications. On theory there may= not much difference between 10K and 20K but in real implementations there = is. If we allow separation of sessions for fate separation of IPV4 and IPV6= then it would become 40K adjacencies.**** > > ** ** > > We can limit to only one hello adjacency per interface yet address the du= al stack issue. A graceful solution is to come up with a notion of LDP adja= cency specific capabilities (similar to LDP capabilities that applies to en= tire sessions) that would benefit multiple purposes. For example, we have m= ultiple ECMP Links between neighboring LSRs A and B as shows below.**** > > ** ** > > +----------------L1------------------+= **** > > | = |**** > > A ----------------L2----------------- B= **** > > | = |**** > > +----------------L3------------------+= **** > > ** ** > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eit= her IPV4 OR ipv6 addresses but not both.**** > > ** ** > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and = L3 are IPv6 capable. **** > > ** ** > > Then hellos exchanged over link would advertise capabilities as below:***= * > > ** ** > > L1 would carry capabilities =96 Ipv4 + Mcast**** > > L2 would carry capabilities =96 ipv4 + ipv6 + Mcast**** > > L3 would carry capabilities =96 ipv4 + ipv6 **** > > ** ** > > **** > > From an implementer/system designer=92s point of view I would think singl= e hello adjacency with per adjacency capabilities would be right approach. = **** > > ** ** > > Thanks,**** > > Pranjal **** > > ** ** > ------------------------------ > > *From:* **Vishwas Manral** [mailto:vishwas.ietf@gmail.com] > *Sent:* Wednesday, February 29, 2012 5:11 PM > *To:* **Dutta, Pranjal K** (Pranjal) > *Cc:* Lizhong Jin; **Aissaoui, Mustapha** (Mustapha); **mpls@ietf.org** > *Subject:* Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06**** > > ** ** > > Hi Lizhong/ Pranjal/ Mustapha, > > So the two main comments that have come after last call are: > > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. > > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? > > Thanks, > Vishwas**** > > On Wed, Feb 29, 2012 at 5:03 PM, **Dutta, Pranjal K** (Pranjal) < > pranjal.dutta@alcatel-lucent.com> wrote:**** > > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address.**** > > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system.**** > > **** > > Thanks,**** > > Pranjal**** > > **** > ------------------------------ > > *From:* Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > *Sent:* Wednesday, February 29, 2012 4:57 PM > *To:* **Aissaoui, Mustapha** (Mustapha) > *Cc:* mpls@ietf.org; **Dutta, Pranjal K** (Pranjal); > vishwas.ietf@gmail.com**** > > > *Subject:* RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06**** > > **** > > ** ** > > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out in my first email. > > Thanks > Lizhong > > > "**Aissaoui, Mustapha** (Mustapha)" > wrote 2012/03/01 04:35:41: > > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > **Aissaoui, Mustapha** (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; **Dutta, Pranjal K** (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: **Dutta, Pranjal K** (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------= - > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "**Dutta, Pranjal K** (Pranjal)" < > pranjal.dutta@alcatel-lucent.com> > > > To: **Vishwas Manral** > > > Cc: "**Aissaoui, Mustapha** \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and > IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability > impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system.**** > > ** ** > --f46d044481639d942d04ba47e1a9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pranjal/ Mustapha,

This has been discussed a few times over alrea= dy.

If we use the option of not preferring an address family over th= e other (configurable of course), what can end up happening, is that we do = not know what transport a session is running over.

Thanks,
Vishwas

On Fri, Mar 2, 201= 2 at 11:37 AM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com> wrote:

Yes, this approach would lead= to all =93kludgy=94 implementations. Due to race conditions between UDP based LDP hellos and TC= P connections (since they are independent channels) it may lead to states of continually flapping sessions.

=A0

Thanks,<= /font>

Pranjal<= /font>

=A0

=A0

I also have an issue with the stability of such an implementation. The draft suggests in Section=A06.1 = - Transport connection establishment, that a TCP connection with IPv6 should = be preferred to one with IPv4=A0if both IPv4 and IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is established, we tear down the IPv4= TCP connection and signal the IPv6 one. This of course is not acceptable. In RF= C 5036 compliant implementations, when a new adjacency comes up to the same LSR-ID, we just associate it with the existing TCP connection which was bootstrapped by the first Hello adjacency.

=A0

Mustapha.

=A0

Fr= om: Dutta, Pranjal K (Pranjal)
Sent: Friday, March 02, 2012= 1:22 PM
To: Vishwas Manral
Cc: Lizhong Jin; Aiss= aoui, Mustapha (Mustapha); mpls@ietf.org
Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

Hi Viswas,

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 We raised one more point earlier on the following clause in the draft.

=A0

Section 6.2

=A0

=A0=A0 As =
outlined in section 2.5.5 of RFC5036, this draft describes that
=A0=A0 if an LSR has a dual-stack interface, which is enabled w=
ith both
=A0=A0 IPv=
4 and IPv6 LDP, then the LSR must periodically send both IPv4 and=

=A0=A0 IPv6 LDP Link Hellos and must separately maintain the =
Hello
=A0=A0 adj=
acency for IPv4 and IPv6 on that interface.
=
=A0


=A0=A0=A0=
=A0 This ensures successful labeled IPv4 and labeled IPv6 traffic=

=A0=A0=A0=A0 forwarding on a dual-stacked interface, as well =
as successful LDP


=A0=A0=A0=
=A0 peering using the appropriate transport on a multi-access=

=A0=A0=A0=A0 interface (even if there are IPv4-only, IPv6-only an=
d dual-stack


=A0=A0=A0=
=A0 LSRs connected to that multi-access interface).
=
=A0


=A0=

The draft mandates t=
hat two separate hello adjacencies should be maintained on dual-stack =96 o=
ne for IPV4 and another for IPV6. We don=92t see any benefit or technical r=
eason of running two separate adjacencies. =A0<=
/pre>

=A0
1.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 First of all, doing so does not p=
rovide fate separation any way. Both IPV4 and IPV6 fecs are still exchanged=
 over same LDP sessions. 


=A0
2.=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This clause mandates that a transit n=
etwork that is carrying IPV6 LSPs must provision IPv6 interfaces. =A0It is =
not mandatory that the transport network itself be IPV6 in order to carry I=
PV6 traffic over its tunnels. This is a very narrow interpretation of secti=
on 2.5.5 in =A0RFC 5036. It=92s not necessary that an IPV6 FEC should be re=
solved by an IPV6 only route next-hop. The hello adjacency can still be ove=
r an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-=
hop. It=92s not necessary that source of hellos be IPv6 or transport addres=
s of TCP session be ipv6.


=A0
3.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This clause has unnecessary scala=
bility implications. We do run very large number of LDP adjacencies/session=
s (e.g 10K) in mobility backhauls or similar deployments. This clause requi=
res to run 20K hello adjacencies which has scalability implications. On the=
ory there may not much difference between 10K and 20K but in real implement=
ations there is. If we allow separation of sessions for fate separation of =
IPV4 and IPV6 then it would become 40K adjacencies.


=A0
We can limit to only one hello adjacency per interface ye=
t address the dual stack issue. A graceful solution is to come up with a no=
tion of LDP adjacency specific capabilities (similar to LDP capabilities th=
at applies to entire sessions) that would benefit multiple purposes. For ex=
ample, we have multiple ECMP Links between neighboring LSRs A and B as show=
s below.


=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +----------------L1----------=
--------+


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A ---------------=
-L2----------------- B


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------------=
---L3------------------+


=A0
The hello adjacencies over L1, L2 and L3 are IP4 interfac=
es are using either IPV4 OR ipv6 addresses but not both.


=A0
Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP=
2MP_DN). L2 and L3 are IPv6 capable. 


=A0
Then hellos exchanged over link would advertise capabilit=
ies as below:


=A0
L=
1 would carry capabilities =96 Ipv4 + Mcast

=A0=A0 =A0=A0=A0L2 would carry capabilities =96=
 ipv4 + ipv6 + Mcast
=A0=A0=A0=A0=A0 L3 would carry capabilities =96 ipv4 + ipv6 <=
u>


=A0
 


From an implementer/system designer=92s point o=
f view I would think single hello adjacency with per adjacency capabilities=
 would be right approach. 


=A0
Thanks,


Pranjal 



=A0















From: Vis=
hwas Manral [mailto:vishwas.ietf@gmail.com] 


Sent: Wednesday, February 29=
, 2012
5:11 PM

To: Dutta,
 Pranjal K (Pranjal)

Cc: Lizhong Jin; Aiss=
aoui, Mustapha (Mustapha); mpls@ietf.org

Subject: Re: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06






=A0



Hi Lizhong/ Pranjal/
Mustapha,



So the two main comments that have come after last call are:



1. Allow for separation of sessions along with the adjacency.

2. Allow for an IPv6 based LSR-ID.



The second could lead to changes required in both OSPF and IS-IS, as well
because the new LSR ID would then need to be exchanged. We could treat it a=
s an
enhancement instead in my view. Do you agree?



Thanks,

Vishwas






On Wed, Feb 29, 2012 at 5:03 PM, Dutta,
 Pranjal K (Pranjal) <pranjal.dutta@alcatel-lucent.com>
wrote:









Yes, I support that too. Ther=
e would be network management issues
with mapping of 4 byte LSR-ID to an IPV6 remote address.



Most of the implementations I=
 know off usually maps 4 byte of the
LSR-ID with a local ipv4 interface address in the system.<=
/u>



=A0



Thanks,<=
u>



Pranjal<=
u>



=A0















From: Lizhong Ji=
n [mailto:lizho=
ng.jin@zte.com.cn]


Sent: Wednesday, February 29=
, 2012
4:57 PM

To: Aissaoui,
 Mustapha (Mustapha)

Cc: mpls@ietf.org; Dutta, Pranjal K
(Pranjal); vish=
was.ietf@gmail.com








Subject: RE: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06









=A0



=A0









Hi Mustapha, 

I
agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed o=
ut
in my first email. 



Tha=
nks


Liz=
hong


=A0




&qu=
ot;Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@a=
lcatel-lucent.com>
wrote 2012/03/01 04:35:41:



> Hi Lizhong, 

>=
; I
actually think that we would need to define a new one which will 

> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id 
> value to an IPv6 loopback interface on each router in the network.


>=
;
=A0 

>=
;
Mustapha. 

>=
;
From: mpls-bounc=
es@ietf.org
[mailto:mpls-bou=
nces@ietf.org]
On Behalf Of 

> Aissaoui, Mustapha (Mustapha)

> Sent: Tuesday, February 07, 2012 10:12 AM

> To: Lizhong Jin; Dutta, Pranjal K
(Pranjal); vish=
was.ietf@gmail.com

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



>=
;
Lizhong, 

>=
;
the existing LSR-id will do the job and should be supported since 

> the LSR-id need not be an IP address. Most implementations will 

> actually populate the field with a /32 address in IPv4 and thus If 
> necessary we could define a new format to allow the use of /128
IPv6addresses. 

>=
;
=A0 

>=
;
Mustapha. 

>=
; 

> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] 

> Sent: Monday, February 06, 2012 10:23 PM

> To: Dutta, Pranjal K (Pranjal);
vishwas.ietf@gm=
ail.com;
Aissaoui, 

> Mustapha (Mustapha)

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



>=
; 

> Hi, 

> I wonder if it is feasible to use LDP capability to advertise IPv6 
> FEC without IPv6 adjacency, and only use one adjacency for LDP 

> session in dual-stack network. LDP capability is per node 

> capability, not per interface capability. But for LDP to choose the 
> correct downstream session and output interface for each FEC, it 

> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking. 

> 

> However, IMO, it is valuable to allow two independent LDP sessions 
> for IPv4 and IPv6 as an option. Regarding the format definition in 
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer 

> new format of LSR-ID. 

> 

> Regards 

> Lizhong 

> 

> 

> >
----------------------------------------------------------------------

> > 

> > Message: 1

> > Date: Tue, 7 Feb 2012 05:28:21 +0530

> > From: "Dutta, Pranjal K
(Pranjal)" <pranjal.dutta@alcatel-lucent.com>

> > To: Vishwas Manral <vishwas.ietf@gmail.com>

> > Cc: "Aissaoui, Mustapha
\(Mustapha\)"

> > =A0 =A0<mustapha.aissaoui@alcatel-lucent.com>, =A0 "=
;mpls@ietf.org"=


> > =A0 =A0<mpl=
s@ietf.org>

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> > Message-ID:

> > =A0
=A0<C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.

> > alcatel-l=
ucent.com>

> > =A0 =A0

> > Content-Type: text/plain; charset=3D"us-ascii"

> > 

> > I would rather for complete separation with multiple lsr-id becau=
se 

> > having separate link adjacencies does not really solved any probl=
em.

> > Since hello adjacencies are associated with a link, still fate 
> > sharing would continue over the single ldp/tcp session for IPV4 a=
nd
IPV6.

> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
 

> > only decide whether such a link is to be programmed for IPV4 or I=
PV6

> > egress traffic but I see it as overkill and unnecessary scalabili=
ty
impacts.

> > 

> > Thanks,

> > Pranjal

> > 

>=
;
--------------------------------------------------------

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.

> This email and any files transmitted with it are confidential and 

> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 

> notify the originator of the message. Any views expressed in this 

> message are those of the individual sender.

> This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.


















=A0

--f46d044481639d942d04ba47e1a9-- From pranjal.dutta@alcatel-lucent.com Fri Mar 2 12:16:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BED21F85D7 for ; Fri, 2 Mar 2012 12:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.027 X-Spam-Level: X-Spam-Status: No, score=-7.027 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owBUdEl1WMbE for ; Fri, 2 Mar 2012 12:16:37 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1E19521F85CC for ; Fri, 2 Mar 2012 12:16:36 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q22KGTeh009181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Mar 2012 14:16:31 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q22KGSB2002483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 3 Mar 2012 01:46:28 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 3 Mar 2012 01:46:28 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Vishwas Manral Date: Sat, 3 Mar 2012 01:46:26 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4ra5vsaMFnzOFTXmuJSSaGJG4twAA26UQ Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CAB91INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Mailman-Approved-At: Tue, 06 Mar 2012 19:12:29 -0800 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 20:16:43 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CAB91INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Viswas, However the key issue is running of two separate = hello adjacencies for IPV4 and IPV6 over single interface between same peer= ing LSRs. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Friday, March 02, 2012 11:50 AM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Pranjal/ Mustapha, This has been discussed a few times over already. If we use the option of not preferring an address family over the other (co= nfigurable of course), what can end up happening, is that we do not know wh= at transport a session is running over. Thanks, Vishwas On Fri, Mar 2, 2012 at 11:37 AM, Dutta, Pranjal K (Pranjal) > wrote: Yes, this approach would lead to all "kludgy" implementations. Due to race = conditions between UDP based LDP hellos and TCP connections (since they are= independent channels) it may lead to states of continually flapping sessio= ns. Thanks, Pranjal ________________________________ From: Aissaoui, Mustapha (Mustapha) Sent: Friday, March 02, 2012 11:26 AM To: Dutta, Pranjal K (Pranjal); Vishwas Manral Cc: Lizhong Jin; mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 I also have an issue with the stability of such an implementation. The draf= t suggests in Section 6.1 - Transport connection establishment, that a TCP = connection with IPv6 should be preferred to one with IPv4 if both IPv4 and = IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first= and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is esta= blished, we tear down the IPv4 TCP connection and signal the IPv6 one. This= of course is not acceptable. In RFC 5036 compliant implementations, when a= new adjacency comes up to the same LSR-ID, we just associate it with the e= xisting TCP connection which was bootstrapped by the first Hello adjacency. Mustapha. ________________________________ From: Dutta, Pranjal K (Pranjal) Sent: Friday, March 02, 2012 1:22 PM To: Vishwas Manral Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Viswas, We raised one more point earlier on the following clau= se in the draft. Section 6.2 As outlined in section 2.5.5 of RFC5036, this draft describes that if an LSR has a dual-stack interface, which is enabled with both IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and IPv6 LDP Link Hellos and must separately maintain the Hello adjacency for IPv4 and IPv6 on that interface. This ensures successful labeled IPv4 and labeled IPv6 traffic forwarding on a dual-stacked interface, as well as successful LDP peering using the appropriate transport on a multi-access interface (even if there are IPv4-only, IPv6-only and dual-stack LSRs connected to that multi-access interface). The draft mandates that two separate hello adjacencies should be maintained= on dual-stack - one for IPV4 and another for IPV6. We don't see any benefi= t or technical reason of running two separate adjacencies. 1. First of all, doing so does not provide fate separat= ion any way. Both IPV4 and IPV6 fecs are still exchanged over same LDP sess= ions. 2. This clause mandates that a transit network that is = carrying IPV6 LSPs must provision IPv6 interfaces. It is not mandatory tha= t the transport network itself be IPV6 in order to carry IPV6 traffic over = its tunnels. This is a very narrow interpretation of section 2.5.5 in RFC = 5036. It's not necessary that an IPV6 FEC should be resolved by an IPV6 onl= y route next-hop. The hello adjacency can still be over an IPV4 link and IP= V6 prefix can still be resolved by an IPV4 route next-hop. It's not necessa= ry that source of hellos be IPv6 or transport address of TCP session be ipv= 6. 3. This clause has unnecessary scalability implications= . We do run very large number of LDP adjacencies/sessions (e.g 10K) in mobi= lity backhauls or similar deployments. This clause requires to run 20K hell= o adjacencies which has scalability implications. On theory there may not m= uch difference between 10K and 20K but in real implementations there is. If= we allow separation of sessions for fate separation of IPV4 and IPV6 then = it would become 40K adjacencies. We can limit to only one hello adjacency per interface yet address the dual= stack issue. A graceful solution is to come up with a notion of LDP adjace= ncy specific capabilities (similar to LDP capabilities that applies to enti= re sessions) that would benefit multiple purposes. For example, we have mul= tiple ECMP Links between neighboring LSRs A and B as shows below. +----------------L1------------------+ | = | A ----------------L2----------------- B | = | +----------------L3------------------+ The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe= r IPV4 OR ipv6 addresses but not both. Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3= are IPv6 capable. Then hellos exchanged over link would advertise capabilities as below: L1 would carry capabilities - Ipv4 + Mcast L2 would carry capabilities - ipv4 + ipv6 + Mcast L3 would carry capabilities - ipv4 + ipv6 >From an implementer/system designer's point of view I would think single he= llo adjacency with per adjacency capabilities would be right approach. Thanks, Pranjal ________________________________ From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, February 29, 2012 5:11 PM To: Dutta, Pranjal K (Pranjal) Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Lizhong/ Pranjal/ Mustapha, So the two main comments that have come after last call are: 1. Allow for separation of sessions along with the adjacency. 2. Allow for an IPv6 based LSR-ID. The second could lead to changes required in both OSPF and IS-IS, as well b= ecause the new LSR ID would then need to be exchanged. We could treat it as= an enhancement instead in my view. Do you agree? Thanks, Vishwas On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: Yes, I support that too. There would be network management issues with mapp= ing of 4 byte LSR-ID to an IPV6 remote address. Most of the implementations I know off usually maps 4 byte of the LSR-ID wi= th a local ipv4 interface address in the system. Thanks, Pranjal ________________________________ From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] Sent: Wednesday, February 29, 2012 4:57 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwa= s.ietf@gmail.com Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed= out in my first email. Thanks Lizhong "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > Hi Lizhong, > I actually think that we would need to define a new one which will > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > a all-IPv6 network will not be possible. I cannot see that operators > will start maintaining a mapping of some global non routable LSR-id > value to an IPv6 loopback interface on each router in the network. > > Mustapha. > From: mpls-bounces@ietf.org [mailto:mpls-bo= unces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Tuesday, February 07, 2012 10:12 AM > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > Lizhong, > the existing LSR-id will do the job and should be supported since > the LSR-id need not be an IP address. Most implementations will > actually populate the field with a /32 address in IPv4 and thus If > necessary we could define a new format to allow the use of /128 IPv6addre= sses. > > Mustapha. > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Monday, February 06, 2012 10:23 PM > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > Mustapha (Mustapha) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi, > I wonder if it is feasible to use LDP capability to advertise IPv6 > FEC without IPv6 adjacency, and only use one adjacency for LDP > session in dual-stack network. LDP capability is per node > capability, not per interface capability. But for LDP to choose the > correct downstream session and output interface for each FEC, it > should also check if the output interface is LDP enabled or not. The > link adjacency could be used to assist such kind of checking. > > However, IMO, it is valuable to allow two independent LDP sessions > for IPv4 and IPv6 as an option. Regarding the format definition in > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > new format of LSR-ID. > > Regards > Lizhong > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > >, "mpls@ietf.org" > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Message-ID: > > > alcatel-lucent.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > I would rather for complete separation with multiple lsr-id because > > having separate link adjacencies does not really solved any problem. > > Since hello adjacencies are associated with a link, still fate > > sharing would continue over the single ldp/tcp session for IPV4 and IPV= 6. > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > egress traffic but I see it as overkill and unnecessary scalability imp= acts. > > > > Thanks, > > Pranjal > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. --_000_C584046466ED224CA92C1BC3313B963E09F00CAB91INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Viswas,

      &n= bsp;            = ;       However the key issue is running of two separate hello adjacencies for IPV4 and IPV6 over single interface between same peering LSRs.

Thanks,

Pranjal

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=
Sent: Friday, March 02, 2012= 11:50 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

Hi Pranjal/ Musta= pha,

This has been discussed a few times over already.

If we use the option of not preferring an address family over the other (configurable of course), what can end up happening, is that we do not know what transport a session is running over.

Thanks,
Vishwas

On Fri, Mar 2, 2012 at 11:37 AM, Dutta, Pranjal K (Pranjal) <pranjal.dutta@alcatel-luce= nt.com> wrote:

Yes, this approach would lead to all “kludgy” imple= mentations. Due to race conditions between UDP based LDP hellos and TCP connections (since = they are independent channels) it may lead to states of continually flapping sessions.

 

Thanks,

Pranjal

 

From: Aissaoui, Mustapha<= /st1:PersonName> (Mustapha)
Sent: Friday, March 02, 2012= 11:26 AM
To: Dutta, Pranjal K (Pranjal); Vishwas = Manral
Cc: Lizhong Jin; mpls@ietf.org


Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 

I = also have an issue with the stability of such an implementation. The draft suggests i= n Section 6.1 - Transport connection establishment, that a TCP connection with IPv6 should be preferred to one w= ith IPv4 if both IPv4 and IPv6 adjacencies exist. This means that if the I= Pv4 adjacency came up first and boot straps the IPv4 TCP connection, as soon as= the IPv6 hello is established, we tear down the IPv4 TCP connection and signal = the IPv6 one. This of course is not acceptable. In RFC 5036 compliant implementations, when a new adjacency comes up to the same LSR-ID, we just = associate it with the existing TCP connection which was bootstrapped by the first Hel= lo adjacency.

 

Mustapha.

 

From: Dutta, Pranjal K (Pranjal)
Sent: Friday, March 02, 2012= 1:22 PM
To: Vishwas Manral
Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org
Subject: RE: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

Hi Viswas,

          &nb= sp;          We raised one more point earlier on the following clause in the draft.

 

Section 6.2

 

&=
nbsp;  As outlined in section 2.5.5 of RFC5036, this draft describes t=
hat
  =
 if an LSR has a dual-stack interface, which is enabled with both
  =
 IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and<=
/o:p>
  =
 IPv6 LDP Link Hellos and must separately maintain the Hello
  =
 adjacency for IPv4 and IPv6 on that interface.
 <=
/o:p>
  =
   This ensures successful labeled IPv4 and labeled IPv6 traffic<=
o:p>
  =
   forwarding on a dual-stacked interface, as well as successful =
LDP
  =
   peering using the appropriate transport on a multi-access=

  =
   interface (even if there are IPv4-only, IPv6-only and dual-sta=
ck
  =
   LSRs connected to that multi-access interface).
 <=
/o:p>
 <=
/o:p>
The draft mandates that two separate hello adjacencies should b=
e maintained on dual-stack – one for IPV4 and another for IPV6. We do=
n’t see any benefit or technical reason of running two separate adjac=
encies.  
 
1. &n=
bsp;            =
;       Firs=
t of all, doing so does not provide fate separation any way. Both IPV4 and =
IPV6 fecs are still exchanged over same LDP sessions. 
 
2.     &nb=
sp;            =
   This=
 clause mandates that a transit network that=
 is carrying IPV6 LSPs must provision IPv6 interfaces.  It is not mand=
atory that the transport network itself be IPV6 in order to carry IPV6 traf=
fic over its tunnels. This is a very narrow interpretation of section 2.5.5=
 in  RFC 5036. It’s not necessary that an IPV6 FEC should be res=
olved by an IPV6 only route next-hop. The hello adjacency can still be over=
 an IPV4 link and IPV6 prefix can still be resolved by an IPV4 route next-h=
op. It’s not necessary that source of hellos be IPv6 or transport add=
ress of TCP session be ipv6.
 
3. &n=
bsp;            =
;       This=
 clause has unnecessary scalability implications. We do run very large numb=
er of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar d=
eployments. This clause requires to run 20K hello adjacencies which has sca=
lability implications. On theory there may not much difference between 10K =
and 20K but in real implementations there is. If we allow separation of ses=
sions for fate separation of IPV4 and IPV6 then it would become 40K adjacen=
cies.
 
=
We can limit to only one hello adjacency per interface yet address the dual=
 stack issue. A graceful solution is to come up with a notion of LDP adjace=
ncy specific capabilities (similar to LDP capabilities that applies to enti=
re sessions) that would benefit multiple purposes. For example, we have mul=
tiple ECMP Links between neighboring LSRs A and B as shows below.
 
=
            &nb=
sp;            =
          +----------------L1-=
-----------------+
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
           A ------------=
----L2----------------- B
          &nb=
sp;            =
            | &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      |
          &nb=
sp;            =
            +-------=
---------L3------------------+
 
=
The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using eithe=
r IPV4 OR ipv6 addresses but not both.
<=
font
size=3D2 color=3Dnavy face=3DArial> 
=
Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 and L3=
 are IPv6 capable. 
 
=
Then hellos exchanged over link would advertise capabilities as below:
 
L1 would carry capa=
bilities – Ipv4 + Mcast
      L2 would carry capabilities R=
11; ipv4 + ipv6 + Mcast
      L3 would carry capabilities R=
11; ipv4 + ipv6 
 
=
 
From an implementer/system designer’s point of view I wou=
ld think single hello adjacency with per adjacency capabilities would be ri=
ght approach. 
 
=
Thanks,
Pranjal 



 















From: Vishwas Manral
[mailto:vishwas=
.ietf@gmail.com]


Sent: Wednesday, February 29=
, 2012
5:11 PM

To: Dutta,
 Pranjal K (Pranjal)

Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org

Subject: Re: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06






 



Hi Lizho=
ng/
Pranjal/ Mustapha,



So the two main comments that have come after last call are:



1. Allow for separation of sessions along with the adjacency.

2. Allow for an IPv6 based LSR-ID.



The second could lead to changes required in both OSPF and IS-IS, as well
because the new LSR ID would then need to be exchanged. We could treat it a=
s an
enhancement instead in my view. Do you agree?



Thanks,

Vishwas






On Wed, =
Feb 29,
2012 at 5:03 PM, Dutta, Pranjal K
(Pranjal) <pranjal.dutta@alcatel-lucent.com>
wrote:









Yes, I support that too. There would be network management issu=
es
with mapping of 4 byte LSR-ID to an IPV6 remote address.=




Most of the implementations I know off usually maps 4 byte of t=
he
LSR-ID with a local ipv4 interface address in the system.



 



Thanks,



Pranjal



 















From: Lizhong Jin [mailto:lizhong.jin@zte.co=
m.cn]


Sent: Wednesday, February 29=
, 2012
4:57 PM

To: Aissaoui,
 Mustapha (Mustapha)

Cc: mpls@ietf.org; Dutta, Pra=
njal K
(Pranjal); vish=
was.ietf@gmail.com






=


Subject: RE: [mpls] Comments=
 on
draft-ietf-mpls-ldp-ipv6-06









 



 









Hi=
 Mustapha,


I agree,
and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out in m=
y
first email. 



Thanks


Lizhong


 




"Aissaoui, Mustapha (Mustapha)" <must=
apha.aissaoui@alcatel-lucent.com>
wrote 2012/03/01 04:35:41:



> Hi Lizhong, 

> I
actually think that we would need to define a new one which will 

> accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in
> a all-IPv6 network will not be possible. I cannot see that operators
> will start maintaining a mapping of some global non routable LSR-id 
> value to an IPv6 loopback interface on each router in the network.


>
  

>
Mustapha. 

>
From: mpls-bounc=
es@ietf.org
[mailto:mpls-bou=
nces@ietf.org]
On Behalf Of 

> Aissaoui, Mustapha (Musta=
pha)

> Sent: Tuesday, February 07, 2012 10:12 AM

> To: Lizhong Jin; Dutta, Pranjal K
(Pranjal); vish=
was.ietf@gmail.com

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



>
Lizhong, 

>
the existing LSR-id will do the job and should be supported since 

> the LSR-id need not be an IP address. Most implementations will 

> actually populate the field with a /32 address in IPv4 and thus If 
> necessary we could define a new format to allow the use of /128
IPv6addresses. 

>
  

>
Mustapha. 

> 

> From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] 

> Sent: Monday, February 06, 2012 10:23 PM

> To: Dutta, Pranjal K (Pra=
njal);
vishwas.ietf@gm=
ail.com;
Aissaoui, 

> Mustapha (Mustapha)

> Cc: mpls@ietf.org

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06



> 

> Hi, 

> I wonder if it is feasible to use LDP capability to advertise IPv6 
> FEC without IPv6 adjacency, and only use one adjacency for LDP 

> session in dual-stack network. LDP capability is per node 

> capability, not per interface capability. But for LDP to choose the 
> correct downstream session and output interface for each FEC, it 

> should also check if the output interface is LDP enabled or not. The
> link adjacency could be used to assist such kind of checking. 

> 

> However, IMO, it is valuable to allow two independent LDP sessions 
> for IPv4 and IPv6 as an option. Regarding the format definition in 
> RFC5036, we may need new LDP version number to identify IPv6 LSR-ID.
> Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer 

> new format of LSR-ID. 

> 

> Regards 

> Lizhong 

> 

> 

> > -----------------------------------------------------------------=
-----

> > 

> > Message: 1

> > Date: Tue, 7 Feb 2012 05:28:21 +0530

> > From: "Dutta, Pranjal K
(Pranjal)" <pranjal.dutta@alcatel-lucent.com>

> > To: Vishwas Manral &=
lt;vishwas.ietf@gmail=
.com>

> > Cc: "Aissaoui, Mustapha
\(Mustapha\)"

> >    <mustapha.aissaoui@alcatel-lucent.com>,   &quo=
t;mpls@ietf.org"

> >    <mpls@ietf.org>

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> > Message-ID:

> >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBAN=
SXCHMBSA3.in.

> > alcatel-l=
ucent.com>

> >    

> > Content-Type: text/plain; charset=3D"us-ascii"

> > 

> > I would rather for complete separation with multiple lsr-id becau=
se 

> > having separate link adjacencies does not really solved any probl=
em.

> > Since hello adjacencies are associated with a link, still fate 
> > sharing would continue over the single ldp/tcp session for IPV4 a=
nd
IPV6.

> > Having IPV4 and IPV6 specific hello adjacencies over a link would=
 

> > only decide whether such a link is to be programmed for IPV4 or I=
PV6

> > egress traffic but I see it as overkill and unnecessary scalabili=
ty
impacts.

> > 

> > Thanks,

> > Pranjal

> > 

>
--------------------------------------------------------

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 

> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.

> This email and any files transmitted with it are confidential and 

> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 

> notify the originator of the message. Any views expressed in this 

> message are those of the individual sender.

> This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.


















 

 

--_000_C584046466ED224CA92C1BC3313B963E09F00CAB91INBANSXCHMBSA_-- From pranjal.dutta@alcatel-lucent.com Mon Mar 5 10:39:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10321F88E9 for ; Mon, 5 Mar 2012 10:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.994 X-Spam-Level: X-Spam-Status: No, score=-8.994 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELEakxkiIvHy for ; Mon, 5 Mar 2012 10:39:10 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9521F88E6 for ; Mon, 5 Mar 2012 10:39:10 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q25Id3gA018347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 12:39:05 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25Id2ls016538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 6 Mar 2012 00:09:02 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 6 Mar 2012 00:09:02 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Lizhong Jin Date: Tue, 6 Mar 2012 00:08:58 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz6mrcOLS6IxCVlR6a/axCSCcn5EQAZATKg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F00CAEA1INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Mailman-Approved-At: Tue, 06 Mar 2012 19:12:29 -0800 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:39:13 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F00CAEA1INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes this is what I have been mentioning for long. There are various FEC typ= e capabilities already defined in several other drafts in this WG. Just port them to advertise with Hellos to fit wherever applicable - and te= rm it as "LDP Hello Adjacency Capabilities". Then you have the ability to selectively pickup interfaces for programming the egress for specific fec t= ypes based on capabilities. Thanks, Pranjal ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Liz= hong Jin Sent: Sunday, March 04, 2012 10:39 PM To: Dutta, Pranjal K (Pranjal) Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 The two separate hello adjacency issue is caused by the current defined LDP= capability per node in RFC5561. Actually, capability per hello adjacency i= s a general requirement and not specific for LDP IPv6. We should update RFC= 5561 first, so as to have one hello adjacency for dual-stack interface. Regards Lizhong "Dutta, Pranjal K (Pranjal)" wrote 2012/= 03/03 02:22:22: > Hi Viswas, > We raised one more point earlier on the > following clause in the draft. > > Section 6.2 > > As outlined in section 2.5.5 of RFC5036, this draft describes that > if an LSR has a dual-stack interface, which is enabled with both > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and > IPv6 LDP Link Hellos and must separately maintain the Hello > adjacency for IPv4 and IPv6 on that interface. > > This ensures successful labeled IPv4 and labeled IPv6 traffic > forwarding on a dual-stacked interface, as well as successful LDP > peering using the appropriate transport on a multi-access > interface (even if there are IPv4-only, IPv6-only and dual-stack > LSRs connected to that multi-access interface). > > > The draft mandates that two separate hello adjacencies should be > maintained on dual-stack - one for IPV4 and another for IPV6. We > don't see any benefit or technical reason of running two separate > adjacencies. > > 1. First of all, doing so does not provide fate separation any > way. Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. > > 2. This clause mandates that a transit network that is carrying > IPV6 LSPs must provision IPv6 interfaces. It is not mandatory that > the transport network itself be IPV6 in order to carry IPV6 traffic > over its tunnels. This is a very narrow interpretation of section 2. > 5.5 in RFC 5036. It's not necessary that an IPV6 FEC should be > resolved by an IPV6 only route next-hop. The hello adjacency can > still be over an IPV4 link and IPV6 prefix can still be resolved by > an IPV4 route next-hop. It's not necessary that source of hellos be > IPv6 or transport address of TCP session be ipv6. > > 3. This clause has unnecessary scalability implications. We do > run very large number of LDP adjacencies/sessions (e.g 10K) in > mobility backhauls or similar deployments. This clause requires to > run 20K hello adjacencies which has scalability implications. On > theory there may not much difference between 10K and 20K but in real > implementations there is. If we allow separation of sessions for > fate separation of IPV4 and IPV6 then it would become 40K adjacencies. > > We can limit to only one hello adjacency per interface yet address > the dual stack issue. A graceful solution is to come up with a > notion of LDP adjacency specific capabilities (similar to LDP > capabilities that applies to entire sessions) that would benefit > multiple purposes. For example, we have multiple ECMP Links between > neighboring LSRs A and B as shows below. > > +----------------L1------------------+ > | = | > A ----------------L2----------------- B > | = | > +----------------L3------------------+ > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are > using either IPV4 OR ipv6 addresses but not both. > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > and L3 are IPv6 capable. > > Then hellos exchanged over link would advertise capabilities as below: > > L1 would carry capabilities - Ipv4 + Mcast > L2 would carry capabilities - ipv4 + ipv6 + Mcast > L3 would carry capabilities - ipv4 + ipv6 > > > From an implementer/system designer's point of view I would think > single hello adjacency with per adjacency capabilities would be > right approach. > > Thanks, > Pranjal > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, February 29, 2012 5:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Lizhong/ Pranjal/ Mustapha, > > So the two main comments that have come after last call are: > > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. > > The second could lead to changes required in both OSPF and IS-IS, as > well because the new LSR ID would then need to be exchanged. We > could treat it as an enhancement instead in my view. Do you agree? > > Thanks, > Vishwas > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) < > pranjal.dutta@alcatel-lucent.com> wrote: > Yes, I support that too. There would be network management issues > with mapping of 4 byte LSR-ID to an IPV6 remote address. > Most of the implementations I know off usually maps 4 byte of the > LSR-ID with a local ipv4 interface address in the system. > > Thanks, > Pranjal > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out in my first email. > > Thanks > Lizhong > > > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: > > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------= - > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and I= PV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > Thanks, > > > Pranjal --_000_C584046466ED224CA92C1BC3313B963E09F00CAEA1INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes this is what I have been mentionin= g for long. There are various FEC type capabilities already defined in severa= l other drafts in this WG.

Just port them to advertise with Hello= s to fit wherever applicable – and term it as “LDP Hello Adjacency C= apabilities”. Then you have the ability to

selectively pickup interfaces for programming the egress for specific fec types based on capabilities.

 

Thanks,

Pranjal

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Sunday, March 04, 2012= 10:39 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Aissaoui, Mustapha (Mustapha); mpls@iet= f.org
Subject: Re: [mpls] Comments= on draft-ietf-mpls-ldp-ipv6-06

 


The two separate hello adjacency issue is caused by= the current defined LDP capability per node in RFC5561. Actually, capability pe= r hello adjacency is a general requirement and not specific for= LDP IPv6. We should update RFC5561 first, so as to have one hello adjacency for dual-stack interface.

Regards
Lizhong


"Dutta, Pranjal K<= /st1:PersonName> (Pranjal)" <pranjal.dutta@alcatel-lucent.com> wrote 2012/03/03 02:22:22:

> Hi Viswas,
>      
> Section 6.2
>  
>    As outlined in section 2.5.5 of RFC5036, this draft describes that
>    if an LSR has a dual-stack interface, which is enabled with both
>    IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and
>    IPv6 LDP Link Hellos and must separately maintain the Hello
>    adjacency for IPv4 and IPv6 on that interface.
>  
>                      
>  
> The draft mandates that two separate hello adjacencies should be
> maintained on dual-stack – one for IPV4 and another for IPV6. We
> don= ’t see any benefit = or technical reason of running two separate
> adjacencies.  
>  
> 1. =      
> 2. =      It is not mandatory that
> the transport network itself be IPV6 in order = to carry IPV6 traffic
> over its tunnels. This is a very narrow interpretation of section 2.
> 5.5 in  RFC 5036. It’s not necessary that an IPV6 FEC should be
> resolved by an IPV6 only route next-hop. The h= ello adjacency can
> still be over an IPV4 link and IPV6 prefix can= still be resolved by
> an IPV4 route next-hop. It’s not necessary that source of hellos be
> IPv6 or transport address of TCP session be ip= v6.
>  
> 3. =      
> We can limit to only one hello adjacency per interface yet address
> the dual stack issue. A graceful solution is t= o come up with a
> notion of LDP adjacency specific capabilities (similar to LDP
> capabilities that applies to entire sessions) = that would benefit
> multiple purposes. For example, we have multip= le ECMP Links between
> neighboring LSRs A and B as shows below.
>  
>                      
> The hello adjacencies over L1, L2 and L3 are I= P4 interfaces are
> using either IPV4 OR ipv6 addresses but not bo= th.
>  
> Link L1, L2 are multicast capable (P2MP or MP2= MP_UP or MP2MP_DN). L2
> and L3 are IPv6 capable.
>  
> Then hellos exchanged over link would advertis= e capabilities as below:
>  
> L1 would carry capabilities – Ipv4 + Mcast
>     – ipv4 + ipv6 + Mca= st
>     – ipv4 + ipv6 =
>  
>  
> From an implementer/system designer’s point of view I would think
> single hello adjacency with per adjacency capabilities would be
> right approach.
>  
> Thanks,
> Pranjal
>  
>
> From: Vishwas Manral [mailto:vishwas.ietf@gmai= l.com]
> Sent: Wednesday, February 29, 2012 5:11 PM
> To: Dutta, Pranjal= K (Pranjal)
> Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha);= mpls@ietf.org
> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  
> Hi Lizhong/ Pranjal/ Mustapha,
>
> So the two main comments that have come after = last call are:
>
> 1. Allow for separation of sessions along with= the adjacency.
> 2. Allow for an IPv6 based LSR-ID.=
>
> The second could lead to changes required in b= oth OSPF and IS-IS, as
> well because the new LSR ID would then need to= be exchanged. We
> could treat it as an enhancement instead in my= view. Do you agree?
>
> Thanks,
> Vishwas
> On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) < > pranjal.dutta@alcatel-lucent.com> wrote:
> Yes, I support that too. There would be networ= k management issues
> with mapping of 4 byte LSR-ID to an IPV6 remot= e address.
> Most of the implementations I know off usually= maps 4 byte of the
> LSR-ID with a local ipv4 interface address in = the system.
>  
> Thanks,
> Pranjal
>  
>
> From: Lizhong Jin<= /st1:PersonName> [mailto:lizhong.jin@zte.com.cn]
> Sent: Wednesday, February 29, 2012 4:57 PM
> To: Aissaoui, Must= apha (Mustapha)
> Cc: mpls@ietf.org<= /st1:PersonName>; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
>
> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>  
>  
> Hi Mustapha,
> I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I
> pointed out in my first email. >
> Thanks
> Lizhong
>  
>
> "Aissaoui, Mu= stapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com
> > wrote 2012/03/01 04:35:41: >
> > Hi Lizhong,
> > I actually think that we would need to de= fine a new one which will
> > accomodate an IPv6 /128 address. Otherwis= e, targeted LDP sessions in
> > a all-IPv6 network will not be possible. = I cannot see that operators
> > will start maintaining a mapping of some = global non routable LSR-id
> > value to an IPv6 loopback interface on ea= ch router in the network.
> >  
> > Mustapha.
> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> > Aissaoui, Mus= tapha (Mustapha)
> > Sent: Tuesday, February 07, 2012 10:12 AM=
> > To: Lizhong J= in; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com
> > Cc: mpls@ietf= .org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> > Lizhong,
> > the existing LSR-id will do the job and s= hould be supported since
> > the LSR-id need not be an IP address. Mos= t implementations will
> > actually populate the field with a /32 ad= dress in IPv4 and thus If
> > necessary we could define a new format to= allow the use of /128
> IPv6addresses.
> >  
> > Mustapha.
> >
> > From: Lizhong= Jin [mailto:lizhong.jin@zte.com.cn]
> > Sent: Monday, February 06, 2012 10:23 PM<= /font>
> > To: Dutta, Pr= anjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui,
> > Mustapha (Mustapha)
> > Cc: mpls@ietf= .org
> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
>
> >
> > Hi,
> > I wonder if it is feasible to use LDP capability to advertise IPv6
> > FEC without IPv6 adjacency, and only use = one adjacency for LDP
> > session in dual-stack network. LDP capabi= lity is per node
> > capability, not per interface capability.= But for LDP to choose the
> > correct downstream session and output int= erface for each FEC, it
> > should also check if the output interface= is LDP enabled or not. The
> > link adjacency could be used to assist su= ch kind of checking.
> >
> > However, IMO, it is valuable to allow two independent LDP sessions
> > for IPv4 and IPv6 as an option. Regarding= the format definition in
> > RFC5036, we may need new LDP version numb= er to identify IPv6 LSR-ID.
> > Or we use different 32bit LSR-ID for IPv6= with IPv4, but I prefer
> > new format of LSR-ID.
> >
> > Regards
> > Lizhong
> >
> >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Tue, 7 Feb 2012 05:28:21 +0530=
> > > From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>
> > > To: Vishwas Manral <vishwas.ietf@gmail.com>
> > > Cc: "Aissaoui, Mustapha \(Mustapha\)"
> > >    <mustapha.aissaoui@alcatel-lucent.com>, mpls@ietf.org"=
> > >    <mpls@ietf.org>
> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06
> > > Message-ID:
> > >    <C584046466ED224CA92C1BC3313B963E09EFE8D667@INBANSXCHMBSA3.in.
> > > alcatel-lucent.com> > > >    
> > > Content-Type: text/plain; charset=3D"us-ascii"
> > >
> > > I would rather for complete separati= on with multiple lsr-id because
> > > having separate link adjacencies doe= s not really solved any problem.
> > > Since hello adjacencies are associat= ed with a link, still fate
> > > sharing would continue over the sing= le ldp/tcp session for IPV4 and IPV6.
> > > Having IPV4 and IPV6 specific hello adjacencies over a link would
> > > only decide whether such a link is t= o be programmed for IPV4 or IPV6
> > > egress traffic but I see it as overk= ill and unnecessary
> scalability impacts.
> > >
> > > Thanks,
> > > Pranjal

--_000_C584046466ED224CA92C1BC3313B963E09F00CAEA1INBANSXCHMBSA_-- From internet-drafts@ietf.org Tue Mar 6 19:57:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0D21E8047; Tue, 6 Mar 2012 19:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oplRbG3xPJAY; Tue, 6 Mar 2012 19:57:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E5121E8013; Tue, 6 Mar 2012 19:57:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307035734.28433.15260.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 19:57:34 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:57:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Author(s) : Siva Sivabalan Sami Boutros George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt Pages : 7 Date : 2012-03-06 LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt From hffellow@hotmail.com Wed Mar 7 01:26:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558DA21F8690 for ; Wed, 7 Mar 2012 01:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOsd51iGGjJN for ; Wed, 7 Mar 2012 01:26:27 -0800 (PST) Received: from snt0-omc4-s31.snt0.hotmail.com (snt0-omc4-s31.snt0.hotmail.com [65.55.90.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9832421F8684 for ; Wed, 7 Mar 2012 01:26:27 -0800 (PST) Received: from SNT110-W61 ([65.55.90.201]) by snt0-omc4-s31.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 01:26:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_3f1c1009-ae3b-4db8-9941-5590ed03d1e5_" X-Originating-IP: [60.228.55.137] From: Feng HUANG To: , , , , , Date: Wed, 7 Mar 2012 09:26:26 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Mar 2012 09:26:26.0959 (UTC) FILETIME=[5F0D61F0:01CCFC44] Subject: [mpls] garoutte X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 09:26:29 -0000 --_3f1c1009-ae3b-4db8-9941-5590ed03d1e5_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Discover how to earn money online from the comfort of your home http://www.senzarespiro.it/papstic.php?otoaolID=48 ______________ An Initial Movement or Impulse Necessary.AWedging Motion.No Mystery in the Wave Motion. brittnei aldred Wed, 7 Mar 2012 10:26:25 --_3f1c1009-ae3b-4db8-9941-5590ed03d1e5_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Discover how to earn money online from the comfort of your home
http://www.senzarespiro.it/papstic.php?otoaolID=48





______________
An Initial Movement or Impulse Necessary.AWedging Motion.No Mystery in the Wave Motion. brittnei aldred
Wed, 7 Mar 2012 10:26:25
--_3f1c1009-ae3b-4db8-9941-5590ed03d1e5_-- From mtinka@globaltransit.net Wed Mar 7 02:14:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204521F86F8 for ; Wed, 7 Mar 2012 02:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R91ETQihOwVL for ; Wed, 7 Mar 2012 02:14:22 -0800 (PST) Received: from the-host.globaltransit.net (the-net-15.globaltransit.net [203.223.132.222]) by ietfa.amsl.com (Postfix) with ESMTP id 0823F21F86FE for ; Wed, 7 Mar 2012 02:14:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5Dsl-0002Uz-HH; Wed, 07 Mar 2012 18:14:07 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Wed, 7 Mar 2012 18:14:03 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4845018.Rpgs2AVfg7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203071814.06540.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:14:23 -0000 --nextPart4845018.Rpgs2AVfg7 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday, March 03, 2012 03:26:00 AM Aissaoui, Mustapha=20 (Mustapha) wrote: > I also have an issue with the stability of such an > implementation. The draft suggests in Section 6.1 - > Transport connection establishment, that a TCP > connection with IPv6 should be preferred to one with > IPv4 if both IPv4 and IPv6 adjacencies exist. This means > that if the IPv4 adjacency came up first and boot straps > the IPv4 TCP connection, as soon as the IPv6 hello is > established, we tear down the IPv4 TCP connection and > signal the IPv6 one. This of course is not acceptable. > In RFC 5036 compliant implementations, when a new > adjacency comes up to the same LSR-ID, we just associate > it with the existing TCP connection which was > bootstrapped by the first Hello adjacency. Mustapha, I was reviewing the I-D and also found this piece=20 of spec. I have to admit that I'm not necessariy a fan of making IPv6=20 be the preferred transport mechanism in case the interface=20 is dual-stacked. As mentioned, if IPv4 bootstraps the adjacency and then the=20 addition of an IPv6 address changes this while in flight,=20 this is counter-intuitive from an operator perspective. I would rather we revise this text so that IPv4 and IPv6=20 adjacencies are started based on the presence of either AF=20 on an interface. Of course, if vendors want to provide=20 operators with knobs to change this behaviour so that it=20 conforms to the current spec. in the I-D, they may do so.=20 But IMHO, this will be giving operators more rope to hang=20 themselves with than they really need. Mark. --nextPart4845018.Rpgs2AVfg7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPVzTuAAoJEGcZuYTeKm+GKFkQAIUpHhJXUhyBceHKynrWku7E m3SnOahmHbf/tKoyNtX/gm+eZMPOYvPKiEFu3S9AuYWFz2ufMFNYeytxIqrPlXz0 8OrtglG2Lpr1CMaOYV/EhjzcyzCeMWSW1eqYNHIOgJUg9j8VR3OpP+iFhmYjZYFg Fooul0OSoJEotisPZhOA7XR+14u6kA88ZatvVS0aIHlp62Wg0ENHxPVsujXdt+ZJ hHKIObtS1zgc1VOAD2jTLRbIQ5a/yZc+kWGm3F1/IGyBej6R1XwzLrnBqys3flH+ kgqmoZ1hRDjqFjyYlceoFWdoRWVdZ5jWa5kkPN4tbsVz3cO4JhIiMeSnYRlaT1Xl QFrCXOq7y+6jXxgxEaEL2nGQ8HoYsYlqwpBAPh+EKy2updVHWWyPieKWIG15k3G6 qYzr9PmbniU+BhmADATwHTdGkZeZLFjLkUfGQBQT24xi5GJTrvY9gtwdj/PWojqX ROD+Ex+muaqm2x7rqDX2GbhFdcJ1QUjp8afCu0OK4H9QblOQ4JhtYOmj3CPOHpYp U9QCD2rj0yYjZ1p6MZ598TO/ZPm348+fvg53sP+Sh5m4+LEcPRZtpmGRM7JTvxg3 62r7wHOMbiJTNcsB8gI8kbOBGW2u2rKschVf23PfDpdxJNNU49cAJEyblGODzjKa RAfHBNyCLEPfNw1oUnO6 =VFh4 -----END PGP SIGNATURE----- --nextPart4845018.Rpgs2AVfg7-- From mtinka@globaltransit.net Wed Mar 7 02:16:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460B921F87C9 for ; Wed, 7 Mar 2012 02:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuSHiPTxAj7A for ; Wed, 7 Mar 2012 02:16:57 -0800 (PST) Received: from the-host.globaltransit.net (the-net-15.globaltransit.net [203.223.132.222]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88821F87BE for ; Wed, 7 Mar 2012 02:16:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5DvS-0002WM-Pq; Wed, 07 Mar 2012 18:16:54 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Wed, 7 Mar 2012 18:16:53 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1633871.t1otmGL4JB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203071816.54124.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:16:58 -0000 --nextPart1633871.t1otmGL4JB Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday, March 03, 2012 03:49:57 AM Vishwas Manral=20 wrote: > This has been discussed a few times over already. Sorry Vishwas, it would appear that I missed those earlier=20 discussions :-). > If we use the option of not preferring an address family > over the other (configurable of course), what can end up > happening, is that we do not know what transport a > session is running over. So are you suggesting that if we don't prefer IPv6 over IPv4=20 for adjacency creation (and we have separate adjacencies for=20 IPv4 and IPv6), we can't simply assume that the IPv4=20 adjacency is maintaining the IPv4 session, or that the IPv6=20 adjacency is maintaining the IPv6 session? Mark. --nextPart1633871.t1otmGL4JB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPVzWWAAoJEGcZuYTeKm+GNT4P/1toAKSw0SPZw5PHTsjiwf7u OuWW0VKTtJyj5j7FVkpL8ANXCJUZTn3GPcUcmNPqtAjuHN84owx7P3khRxvM0ds0 BWj3i4VgTWgQ2JDYleprW3ABVN0txLKzbpc88JOjzd71jPrSVHikyVpYVOXat4IZ h8U4jhBGgyIOHBlCJcVy/rcoNK5eVBIzOvI0Z2c1zhTMH+/rTXzjh6tZumPAy9Jl LIcmSYKo2N4+NbztoEvddNR24GDGWQQsoNqMKQQjQXZwi4Eftik0yKvNNYkuXJie tTtadfPatZ46UE6ifUEVP1jmX9qJ1Y50xoaxs7mYowzJFzRDUZZQ5xqPOSXPsNMp MuZg3Ol1aOUf4ycDv6UmTCTNSV2NzMoJ8VDbnMOnxl+HeGvZSlZOKN6ppxLsEhKA 8zSjNQ3Mlu66Ps8tCU+Rmo/RK5NlDi98XXlw0XaDqiIUPwB/wjt61bgCMg2R6idQ uqVJ3G8hEAzcwsOHaRdxY2cBoqNi7ZcItEY3H9417haZycue8awgQqMFYtHaK3De Os9rt6CPzPbY7rd4SeSqesCBkyKJRsOvD1Yn3oskB6olP1foyYNmMbi5eMWHQKpO 12NZ+UYhlJsfZwlPFgHF3LVO1GeRYSMDYlgMWRqQNrcHNdHopiM0DxfdbWwGi6GU Zudl9S1bkSRsDLs8T/Z7 =hed0 -----END PGP SIGNATURE----- --nextPart1633871.t1otmGL4JB-- From mtinka@globaltransit.net Wed Mar 7 02:22:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4021F87A5 for ; Wed, 7 Mar 2012 02:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWvF2COu0utN for ; Wed, 7 Mar 2012 02:22:57 -0800 (PST) Received: from the-host.globaltransit.net (the-net-15.globaltransit.net [203.223.132.222]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8321F87B3 for ; Wed, 7 Mar 2012 02:22:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5E1F-0002bq-S4; Wed, 07 Mar 2012 18:22:53 +0800 From: Mark Tinka Organization: Global Transit International To: "Dutta, Pranjal K (Pranjal)" Date: Wed, 7 Mar 2012 18:22:52 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1496881.UZ7Xrl04tu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203071822.52478.mtinka@globaltransit.net> Cc: "mpls@ietf.org" , Lizhong Jin , "Aissaoui, Mustapha \(Mustapha\)" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:22:58 -0000 --nextPart1496881.UZ7Xrl04tu Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday, March 06, 2012 02:31:23 AM Dutta, Pranjal K=20 (Pranjal) wrote: > We can satisfy both fate-shared and fate-separation > requirements using single hello adjacency (with per > adjacency capabilities) associated with a remote lsr-id. I think given that turning on LDP in a network will=20 immediately cause IPv4 (or IPv6) traffic to be forwarded=20 using LSP's that have been created as a result, I'm not sure=20 operators would be happy to find themselves in situations=20 where an adjacency is enabling both LDPv4 and LDPv6, and yet=20 they probably didn't want to forward IPv6 Internet traffic=20 using MPLS at that particular point in time. If vendors will provide options to toggle LDPv6 in new code=20 that implements it, we might as well separate the=20 adjacencies for IPv4 and IPv6 in the process. The example I=20 gave above is one case; but in general terms, it would be=20 good if issues affecting the adjacency don't take down both=20 versions of LDP due to fate-sharing of the session, and yet=20 perhaps only one of the AF's needed to be affected. At its most basic level, LDP will lead to forwarding of=20 global table IP packets via MPLS. This can be a big deal,=20 even before other fancy capabilities like mLDP, pw, e.t.c.,=20 are considered. Mark. --nextPart1496881.UZ7Xrl04tu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPVzb8AAoJEGcZuYTeKm+GcKwP/0NGCl3AJEYnC7iQSg9dsGOG RGAtzZT/h7tvJXM4/ywsRRsVmdBP4T37ACtCXH/k4uAjr7ZMFk8brK/obzA+KE8n uh5RNiDRo/D9S7E9ccbmtGws1jRaI2eWnDszHzw0gVG3CN6TW6z1izzNGNjTAzHc n58av9oTJ0nlkyngqaXg70HV28UWHdJpIMQm4DBZeTOKLKt+yJDwxmUu4XyggYS7 +FNKAqQkjio4cnPBRjEKgenIFkn6/mctgMeqNh5H7rRocHkdx2KG5llhZBMOa21F FPvBwyoUflPcGJodi7SxCCmBQHD96czFhs1XSp4NxHq6EghLNPiHk+aFrogZLzLU Pj1DbXrifhDtppy402ttZhQnaVU2+KYytz4qAGPSjb3swCFOnr8BtoSY1YLLQOBC E3cmAH+/qAF7ETNL65DOyuPbMUTxk+SLjgcpuChLSEfMUlTa6mL6cbID+i22+GDS FZDS/ksFf8rvA3e55+XlI0zWyuoBwSvhcv0Cuex9oNsplSE/348rgHXvk/3tBdpb KKjq/r3Mn2uyqTUbqayUUOA7nOxo6c5SCN6awKNHkcVcKZsG2Iswn3gASHXueCYD nLMpeF3e0xHuTxgcVsxV5Z4iPHqmlNiQX//Q5/ZgzR3QSD3AQ0mFd7ANw7o55KKx iRqd4GUL5LTMjeDJAGl/ =q7WT -----END PGP SIGNATURE----- --nextPart1496881.UZ7Xrl04tu-- From mtinka@globaltransit.net Wed Mar 7 02:27:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0A21F85F7 for ; Wed, 7 Mar 2012 02:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecHld50bgFy6 for ; Wed, 7 Mar 2012 02:27:14 -0800 (PST) Received: from the-host.globaltransit.net (the-net-15.globaltransit.net [203.223.132.222]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7ED21F85D4 for ; Wed, 7 Mar 2012 02:27:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5E5C-0002dA-Pf; Wed, 07 Mar 2012 18:26:58 +0800 From: Mark Tinka Organization: Global Transit International To: "Dutta, Pranjal K (Pranjal)" Date: Wed, 7 Mar 2012 18:26:55 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6693624.dmI0udlc34"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203071826.55538.mtinka@globaltransit.net> Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin , "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:27:14 -0000 --nextPart6693624.dmI0udlc34 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, March 07, 2012 02:27:39 AM Dutta, Pranjal K=20 (Pranjal) wrote: > If we run multiple ldp sessions between peering > systems for fate separation of ipv4 and ipv6 then there > can be two separate hello adjacencies over a single > interface (each one associated with separate sessions) > but in that case the LSR-IDS used would be different (we > need to work for an extension of RFC 5036). I would be in favour of the above. Vendors could go ahead and implement support for a single=20 adjacency that carries both sessions, but experience=20 suggests operators will choose the latter instead,=20 instinctively. LDP has also prided itself on being simple, so I'm not sure=20 whether providing all these options to operators via CLI=20 will be in keeping with that mantra (especially in relation=20 to the defaults various vendors may choose to run in multi- vendor-operated networks). Mark. --nextPart6693624.dmI0udlc34 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPVzfvAAoJEGcZuYTeKm+GhYIP/1z7CxsjRI7Rg9hhald5QWSP 2aIamgSACoqconek7IliI5QyyrgevueeAffJyBdbvVqdV9tEi//yHL+DQ9eMj3MQ MWZNtVmQ6B66hZ+oR62Nz90ej4AdGZu2d6FTvf6y0AqCLjBxMl+kY54svCABR1m+ zhIkUayMNwCEryrG5pAB919jzcOuaBfwXO7pZusTyD51ouq0WqVkOFUIfAHz1n1j TI7IvYCvq6ReeziFnvtjrOMizsU7QBu2njUiKmRiiIuD4xsczNdBgotI9HNHoq2j Zhm7KRFdKoxS4FTWU/w/xau6QLgEqYAoXiszV2uSECk6A3hOuMs0KnzgL4qCUE1M Ave0pzRaa8W8B3h/gjJU4Z9B0iIjThwKa35G53fzzw1RvQpftczWEPqDgYlglXc5 qn1+eHEJiss/eFcPqA1FpHDjyUvZ+8u3N9UW9TSz5feqeOKHhUSgQSOLcMc46Vxa 2jsR61AhXqFr6R7hEDnilrwsltx/dO85vI3cBanbtSwRqoZEciOh+lYtCa95y+CK GYgfdT2dqHwsH6DzYEl5B00Fand++02gtTr/HCJ4bdi+hiFbCptoIejRfoGmcZLR lncIR34IFXQ5716QT2/eLyyaWXfVyVY7Tp0da0MSMhNtqlfOA3OtVjc99WuxBUHV mKSMAOSn8E2Ki0OlEwJa =MfeC -----END PGP SIGNATURE----- --nextPart6693624.dmI0udlc34-- From acmorton@att.com Wed Mar 7 07:04:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFCA21F851B for ; Wed, 7 Mar 2012 07:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.42 X-Spam-Level: X-Spam-Status: No, score=-105.42 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiBOADxCmJ4v for ; Wed, 7 Mar 2012 07:04:52 -0800 (PST) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id A49BB21F84FB for ; Wed, 7 Mar 2012 07:04:52 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 419775f4.0.365239.00-472.908521.nbfkord-smmo04.seg.att.com (envelope-from ); Wed, 07 Mar 2012 15:04:52 +0000 (UTC) X-MXL-Hash: 4f57791429826317-3bd263aab21e3057538d5a98d279b4f8197bf32d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q27F5M3A025573 for ; Wed, 7 Mar 2012 10:05:22 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q27F5H9Z025519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Mar 2012 10:05:18 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Wed, 7 Mar 2012 10:04:35 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q27F4ZmM032114 for ; Wed, 7 Mar 2012 10:04:35 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q27F4Pwd031813 for ; Wed, 7 Mar 2012 10:04:25 -0500 Message-Id: <201203071504.q27F4Pwd031813@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-8-49.vpn.west.att.com[135.70.8.49](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120307150154gw1004or52e>; Wed, 7 Mar 2012 15:01:54 +0000 X-Originating-IP: [135.70.8.49] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Mar 2012 10:05:29 -0500 To: mpls-chairs@tools.ietf.org, mpls@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=jHABFUzYYPIA:10 a=oqxZR5qPPy4A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=MKq1rviIsmT6SBDfjCsA:9 a=] X-AnalysisOut: [wYp4zPpx1iuocBMiIzUA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: [mpls] Fwd: Last Call: (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:04:53 -0000 On this Last Call, bmwg requests any final comments. Al bmwg chair >Date: Tue, 06 Mar 2012 09:21:41 -0800 >Cc: bmwg@ietf.org >X-BeenThere: ietf-announce@ietf.org > >The IESG has received a request from the Benchmarking Methodology WG >(bmwg) to consider the following document: >- 'Methodology for benchmarking MPLS protection mechanisms' > as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2012-03-20. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > This draft describes the methodology for benchmarking MPLS Protection > mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. > This document provides test methodologies and testbed setup for > measuring failover times while considering all dependencies that > might impact faster recovery of real-time applications bound to MPLS > based traffic engineered tunnels. The benchmarking terms used in > this document are defined in [TERM-ID]. > > > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-bmwg-protection-meth/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-bmwg-protection-meth/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From ietfc@btconnect.com Wed Mar 7 07:10:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45CA21F8611 for ; Wed, 7 Mar 2012 07:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM5zlkYga0hL for ; Wed, 7 Mar 2012 07:10:37 -0800 (PST) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id AF3E521F8609 for ; Wed, 7 Mar 2012 07:10:36 -0800 (PST) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2beaomr08.btconnect.com with SMTP id GMT59211; Wed, 07 Mar 2012 15:10:18 +0000 (GMT) Message-ID: <008001ccfc6b$effdf540$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Rolf Winter" , References: <20120306095126.21520.33961.idtracker@ietfa.amsl.com> <791AD3077F94194BB2BDD13565B6295D25031AF4@DAPHNIS.office.hd> Date: Wed, 7 Mar 2012 15:09:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4F577A57.0195, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.7.143330:17:7.944, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4F577A5A.00FE,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:10:37 -0000 ----- Original Message ----- From: "Rolf Winter" To: Sent: Tuesday, March 06, 2012 10:57 AM MPLS WG, this new version has expanded a lot based on comments received from the list. While the amount of text has increased significantly, the actual content has changed little. Most IDs defined in the document are equal to the ones defined in RFC 6370 with the exception when global uniqueness is required (the Global_ID is exchanged with the ICC_Operator_ID, an ID which is based on the ICC rather than on the AS number). In addition the maintenance IDs differ. Feedback highly appreciated. The elephant in the room is the lack of a Content Transfer Encoding that allows the ICC_Operator_Id to fit into the space allocated in the protocols for an AS number. Arguably, that is not part of this specification, but if not here, where? Tom Petch Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Dienstag, 6. März 2012 10:51 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-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 : MPLS-TP Identifiers Following ITU-T Conventions > Author(s) : Rolf Winter > Eric Gray > Huub van Helvoort > Malcolm Betts > Filename : draft-ietf-mpls-tp-itu-t-identifiers-03.txt > Pages : 12 > Date : 2012-03-06 > > This document specifies an extension to the identifiers to be used > in > the Transport Profile of Multiprotocol Label Switching (MPLS-TP). > Identifiers that follow IP/MPLS conventions have already been > defined. This memo augments that set of identifiers for MPLS-TP > management and OAM functions to include identifier information in a > format typically used by the ITU-T. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > identifiers-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > identifiers-03.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ietfc@btconnect.com Wed Mar 7 08:41:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E356C21F863C for ; Wed, 7 Mar 2012 08:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0ocEeLLHmRp for ; Wed, 7 Mar 2012 08:41:02 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64A21F84BD for ; Wed, 7 Mar 2012 08:40:59 -0800 (PST) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2beaomr10.btconnect.com with SMTP id GNF71975; Wed, 07 Mar 2012 16:40:33 +0000 (GMT) Message-ID: <030101ccfc78$8bb6f480$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Shane Amante" , "Kamran Raza" References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> Date: Wed, 7 Mar 2012 16:39:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4F578F81.000D, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.7.161231:17:7.944, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4F578F81.01E7,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:41:04 -0000 ----- Original Message ----- From: "t.petch" To: "Shane Amante" ; "Kamran Raza" Sent: Thursday, March 01, 2012 6:16 PM ----- Original Message ----- From: "Shane Amante" To: "Kamran Raza" skraza@cisco.com Sent: Thursday, March 01, 2012 4:45 PM Kamran, On Feb 29, 2012, at 9:39 PM, Kamran Raza wrote: > Firstly, I don’t agree that LSR Id be made IPv6 (address) based and/or route-able; LSR Id, as defined in the base spec, is just a 4 octet unique id and need not be routable, though most implementations currently populate it with /32 loopback address. Let’s not carry forward a wrong notion/usage. Although, in theory, the LSR-ID "need not be routable", I can say that in the networks I operate it is *always* routable. From a simple troubleshooting PoV, it's extremely easy to: a) ping the /32 (4-octet) LSR-ID; or, Had much experience lately of keying in a 128-bit IPv6 address with pinpoint accuracy in order to ping a device? Um, it stinks. With that wonderful timing of happenstance, this just got posted to the Operational Security WG list ------------------------------------------------------------------- Date: Tue, 6 Mar 2012 10:51:11 -0300 From: Fernando Gont fgont@si6networks.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt On 03/06/2012 10:06 AM, Andrew Yourtchenko wrote: >>> Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and >>> measure how much it takes to get this address over to someone over the >>> phone, without errors. That's the type of problem I had in mind. >> >> I know of quite a few folks that have already established the rule that >> "you don't tell IPv6 addresses over the phone" > > Indeed, precisely because of this problem, I suspect. Exactly. ----------------------------------------------------------------------- I see the world as divided into those who know IPv6 addresses are a nightmare and those who have yet to discover that IPv6 addresses are a nightmare:-) Tom Petch From stbryant@cisco.com Wed Mar 7 09:02:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AF621E801B; Wed, 7 Mar 2012 09:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.576 X-Spam-Level: X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7nBsDVkOKlz; Wed, 7 Mar 2012 09:02:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 649A121F861A; Wed, 7 Mar 2012 09:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=6270; q=dns/txt; s=iport; t=1331139757; x=1332349357; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=+Z01LIlb8EViqTXylZZRBlPu5/fqiJcTjiEx58ayf3w=; b=P2QckAjUVz303K9nE1GMq8Y+bjTKgeIptBH1DZhbwd2udONkB4Qnhnuq NCl34spYmVtbz7XobXEB2k3+SBT2K4XBgOWFu9afjy79wfjPumXt1SI1Z ZjFKVDWOOTXzBnMiP+OUNj5BPQd5wNvdEa7G282fbMYZ9ZJLaTcxQP71e A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADOUV0+Q/khM/2dsb2JhbABCtSmBB4IKAQEBBAEBAQ8BAgFYCgEMBBwDAQIKFgQLCQMCAQIBFR8HAggGAQwBBQIBAR6HZgugDAGDMQ8Bk3aQbwSVQZAXgmM X-IronPort-AV: E=Sophos;i="4.73,546,1325462400"; d="scan'208,217";a="67918220" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 17:02:36 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q27H2ah4014528; Wed, 7 Mar 2012 17:02:36 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q27H2VBp007435; Wed, 7 Mar 2012 17:02:31 GMT Message-ID: <4F5794A6.4020107@cisco.com> Date: Wed, 07 Mar 2012 17:02:30 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "l2vpn@ietf.org" References: <20120307163304.11989.2410.idtracker@ietfa.amsl.com> In-Reply-To: <20120307163304.11989.2410.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120307163304.11989.2410.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050705040201070605070501" Cc: "Ietf@ietf.org" Subject: [mpls] Fwd: Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:02:39 -0000 This is a multi-part message in MIME format. --------------050705040201070605070501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI MPLS and L2VPN WGs. Stewart -------- Original Message -------- Subject: Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard Date: Wed, 07 Mar 2012 08:33:04 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: pwe3@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------050705040201070605070501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI MPLS and L2VPN WGs.

Stewart

-------- Original Message --------
Subject: Last Call: (LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements) to Proposed Standard
Date: Wed, 07 Mar 2012 08:33:04 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: ietf@ietf.org
To: IETF-Announce <ietf-announce@ietf.org>
CC: pwe3@ietf.org 


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements'
  <draft-ietf-pwe3-pw-typed-wc-fec-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-03-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The "Typed Wildcard Forwarding Equivalence Class (FEC) Element"
   defines an extension to the Label Distribution Protocol (LDP) that
   can be used when it is desired to request or withdraw or release all
   label bindings for a given FEC Element type.  However, a typed
   wildcard FEC element must be individually defined for each FEC
   element type.  This specification defines the typed wildcard FEC
   elements for the PWid (0x80) and Generalized PWid (0x81) FEC element
   types.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pwe3-pw-typed-wc-fec/ballot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
--------------050705040201070605070501-- From Rolf.Winter@neclab.eu Wed Mar 7 11:56:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1083411E8098 for ; Wed, 7 Mar 2012 11:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ipwzw1mh+Kp for ; Wed, 7 Mar 2012 11:56:00 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2020B11E8072 for ; Wed, 7 Mar 2012 11:56:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1B218100796; Wed, 7 Mar 2012 20:55:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8kaT6V3vh-Z; Wed, 7 Mar 2012 20:55:58 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id ED7F71006ED; Wed, 7 Mar 2012 20:55:47 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 7 Mar 2012 20:55:48 +0100 From: Rolf Winter To: t.petch , "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt Thread-Index: AQHM+37Mbur7weEc0kSDEiRbQBa1t5ZdBxYQgAHsqBaAAEx+0A== Date: Wed, 7 Mar 2012 19:55:48 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D2503276F@DAPHNIS.office.hd> References: <20120306095126.21520.33961.idtracker@ietfa.amsl.com> <791AD3077F94194BB2BDD13565B6295D25031AF4@DAPHNIS.office.hd> <008001ccfc6b$effdf540$4001a8c0@gateway.2wire.net> In-Reply-To: <008001ccfc6b$effdf540$4001a8c0@gateway.2wire.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:56:01 -0000 Hi, Like here http://tools.ietf.org/html/draft-cui-mpls-tp-on-demand-cv-id-00 e= .g. Or other places where it is actually used. Just like it was done for th= e IP-based IDs (e.g. RFC 6426).=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Mittwoch, 7. M=E4rz 2012 15:10 > To: Rolf Winter; mpls@ietf.org > Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-itu-t-identifiers- > 03.txt >=20 > ----- Original Message ----- > From: "Rolf Winter" > To: > Sent: Tuesday, March 06, 2012 10:57 AM >=20 > MPLS WG, >=20 > this new version has expanded a lot based on comments received from the > list. > While the amount of text has increased significantly, the actual > content has changed little. Most IDs defined in the document are equal > to the ones defined in RFC 6370 with the exception when global > uniqueness is required (the Global_ID is exchanged with the > ICC_Operator_ID, an ID which is based on the ICC rather than on the AS > number). In addition the maintenance IDs differ. Feedback highly > appreciated. >=20 > > The elephant in the room is the lack of a Content Transfer Encoding > that allows the ICC_Operator_Id to fit into the space allocated in the > protocols for an AS number. Arguably, that is not part of this > specification, but if not here, where? >=20 > Tom Petch >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: Dienstag, 6. M=E4rz 2012 10:51 > > To: i-d-announce@ietf.org > > Cc: mpls@ietf.org > > Subject: I-D Action: draft-ietf-mpls-tp-itu-t-identifiers-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 : MPLS-TP Identifiers Following ITU-T Conventions > > Author(s) : Rolf Winter > > Eric Gray > > Huub van Helvoort > > Malcolm Betts > > Filename : draft-ietf-mpls-tp-itu-t-identifiers-03.txt > > Pages : 12 > > Date : 2012-03-06 > > > > This document specifies an extension to the identifiers to be used > > in > > the Transport Profile of Multiprotocol Label Switching (MPLS-TP). > > Identifiers that follow IP/MPLS conventions have already been > > defined. This memo augments that set of identifiers for MPLS-TP > > management and OAM functions to include identifier information in > a > > format typically used by the ITU-T. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > > identifiers-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-itu-t- > > identifiers-03.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From mtinka@globaltransit.net Wed Mar 7 19:15:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75521E801E for ; Wed, 7 Mar 2012 19:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T67TaT9+cVQT for ; Wed, 7 Mar 2012 19:15:56 -0800 (PST) Received: from the-host.globaltransit.net (unknown [203.121.106.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3DB21E800F for ; Wed, 7 Mar 2012 19:15:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5TpV-00049l-Tt; Thu, 08 Mar 2012 11:15:49 +0800 From: Mark Tinka Organization: Global Transit International To: mpls@ietf.org Date: Thu, 8 Mar 2012 11:15:49 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> <030101ccfc78$8bb6f480$4001a8c0@gateway.2wire.net> In-Reply-To: <030101ccfc78$8bb6f480$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3174066.Dc345KYu1D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203081115.49354.mtinka@globaltransit.net> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:15:57 -0000 --nextPart3174066.Dc345KYu1D Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, March 07, 2012 11:39:50 PM t.petch wrote: > I see the world as divided into those who know IPv6 > addresses are a nightmare and those who have yet to > discover that IPv6 addresses are a nightmare:-) But what else are you going to do? Unless vendors decide to start implementing DNS-based=20 Router-ID and LSR-ID definitions in CLI (just kidding, guys,=20 please don't do that) :-). Mark. --nextPart3174066.Dc345KYu1D Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPWCRlAAoJEGcZuYTeKm+GiKsQALdEhrn7bXNIZeZOcaNnHTpH wAUr9LCRrH5kyDNQ8N6EMuZXVazMLET2J+/S8ShEPEPnwyuWwwU65OGUSx2Q67Wx xhWqP5AadmT4puGQKVZtja64s2Jgb3L0RRYCkvHqpXghXMUVsfopB0waKj2mb/he mS1kukrunuhHIJ8GLrWVemcIiAEdriW9DJlF9GoDJACUVWHUL+d+1gp27mE9D8Q7 UhPxBT/jZPF/nOj8E9ie4Jc9NFgynJyR89usdKAycHQBmFvP4upvxFA4QZcyHmHw N3VemglZeXVurVYJ6r2uuWRxppG0cvcVN3qPD5c9LNGbXQ/gK2hOp2z8JpkkL29R l10a0AwSw9RovqnNTWe9l6untJyQ+LgRgqETp4BMeRd1AZz4x5+MI6fDUgn/mtsg khCYHejIUw47jGEmsc7n4RaytuyoD5qT6QK+6pXARmeihnoVn10ZkOiTW3cEjRNE nrgDgbe2Z9pCIB4oEBhc4U9O35fHWWf9VXywK9FOH6xv8D8MA4zvMkRG65El+rIB TQGS9FpfViBJLQPNAMdAyLJSrlt9ZCJkil9ksSFb7KEsRbMWZ2OImXWwSv6U1K8/ kGRpmFipB8DnsY5XecNj49YikE+DfV4LeFmc2y5SOiU3ffoXugkKVt0GsNxjY98z CKaHcgJsipb5m5Myt0Tu =ihf8 -----END PGP SIGNATURE----- --nextPart3174066.Dc345KYu1D-- From internet-drafts@ietf.org Thu Mar 8 03:46:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5728821F866B; Thu, 8 Mar 2012 03:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMVHzmFPOazx; Thu, 8 Mar 2012 03:46:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D973E21F8647; Thu, 8 Mar 2012 03:46:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308114619.20909.54154.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 03:46:19 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:46:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP= ) MIB-based Management Overview Author(s) : Daniel King Venkatesan Mahalingam Filename : draft-ietf-mpls-tp-mib-management-overview-07.txt Pages : 26 Date : 2012-03-08 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overv= iew-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi= ew-07.txt From mustapha.aissaoui@alcatel-lucent.com Thu Mar 8 07:46:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2A821F8799 for ; Thu, 8 Mar 2012 07:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.331 X-Spam-Level: X-Spam-Status: No, score=-7.331 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS-HzmausnRk for ; Thu, 8 Mar 2012 07:46:23 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6321F8798 for ; Thu, 8 Mar 2012 07:46:23 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q28Fk7YG008224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Mar 2012 09:46:07 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q28FjtaE020402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Mar 2012 09:46:07 -0600 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 8 Mar 2012 09:45:56 -0600 From: "Aissaoui, Mustapha (Mustapha)" To: "mtinka@globaltransit.net" , "mpls@ietf.org" Date: Thu, 8 Mar 2012 09:45:55 -0600 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz8Sw3OOXCbsrvvTASC/aPWNuA9hAA9eCEQ Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5811EFA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203071814.06540.mtinka@globaltransit.net> In-Reply-To: <201203071814.06540.mtinka@globaltransit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:46:24 -0000 Mark, It is bit awkward that some of the email postings are being delayed for som= e reason and as such the flow of exchange may not seem very natural. I think we all agree that having two adjacencies sharing the same LDP sessi= on is not a good thing. We should indeed allow operators to have an IPv6 ad= jacency bootstrap and IPv6 session separately from the IPv4 adjacency boots= trapping an IPv4 session. This is consistent with RFC 5036.=20 The knob that we were referring to is different. What we are saying is that= once say an IPv6 adjacency bootstrapped and IPv6 LDP session, we should al= low flexibility of which address family FECs can be advertized over that se= ssion. In other words, we can certainly exchange IPv6 unicast FECs, but als= o IPv4 unicast FECs, mLDP P2MP FECs, PW FECs, etc. This is all under the c= ontrol of the operator who can use the LDP node capability and/or the FEC f= ilters to decide which FEC families are allowed over that session. For inst= ance, you can decide that only IPv6 unicast FECs should be exchanged over t= his IPv6 LDP session and this is fine.=20 Think about it like in BGP which allows advertizing IPv4 NLRI over an IPv6 = TCP connection and vice-versa. You use it they way you think is appropriate= to you but it has the flexilbility to advertise routes of different addres= s families over the same IPv6 (or IPv4) TCP connection. Regards, Mustapha. -----Original Message----- From: Mark Tinka [mailto:mtinka@globaltransit.net]=20 Sent: Wednesday, March 07, 2012 5:14 AM To: mpls@ietf.org Cc: Aissaoui, Mustapha (Mustapha); Dutta, Pranjal K (Pranjal); Vishwas Manr= al; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Saturday, March 03, 2012 03:26:00 AM Aissaoui, Mustapha (Mustapha) wrote: > I also have an issue with the stability of such an implementation. The=20 > draft suggests in Section 6.1 - Transport connection establishment,=20 > that a TCP connection with IPv6 should be preferred to one with > IPv4 if both IPv4 and IPv6 adjacencies exist. This means that if the=20 > IPv4 adjacency came up first and boot straps the IPv4 TCP connection,=20 > as soon as the IPv6 hello is established, we tear down the IPv4 TCP=20 > connection and signal the IPv6 one. This of course is not acceptable. > In RFC 5036 compliant implementations, when a new adjacency comes up=20 > to the same LSR-ID, we just associate it with the existing TCP=20 > connection which was bootstrapped by the first Hello adjacency. Mustapha, I was reviewing the I-D and also found this piece of spec. I have to admit that I'm not necessariy a fan of making IPv6 be the preferr= ed transport mechanism in case the interface is dual-stacked. As mentioned, if IPv4 bootstraps the adjacency and then the addition of an = IPv6 address changes this while in flight, this is counter-intuitive from a= n operator perspective. I would rather we revise this text so that IPv4 and IPv6 adjacencies are st= arted based on the presence of either AF on an interface. Of course, if ven= dors want to provide operators with knobs to change this behaviour so that = it conforms to the current spec. in the I-D, they may do so.=20 But IMHO, this will be giving operators more rope to hang themselves with t= han they really need. Mark. From mtinka@globaltransit.net Thu Mar 8 08:03:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A7521F8678 for ; Thu, 8 Mar 2012 08:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0xMul4AZNk0 for ; Thu, 8 Mar 2012 08:03:03 -0800 (PST) Received: from the-host.globaltransit.net (the-net-6.globaltransit.net [203.223.132.213]) by ietfa.amsl.com (Postfix) with ESMTP id 14FC021F856F for ; Thu, 8 Mar 2012 08:03:02 -0800 (PST) Received: from [127.0.0.1] (helo=the-host.localnet) by the-host.globaltransit.net with esmtp (Exim 4.74) (envelope-from ) id 1S5fng-0006wE-Q3; Fri, 09 Mar 2012 00:02:44 +0800 From: Mark Tinka Organization: Global Transit International To: "Aissaoui, Mustapha (Mustapha)" Date: Fri, 9 Mar 2012 00:02:40 +0800 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; i686; ; ) References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203071814.06540.mtinka@globaltransit.net> <5DF53972F7E9134782DCE51624466FE50AD5811EFA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5811EFA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1892857.5o5TlzLuDW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201203090002.43852.mtinka@globaltransit.net> Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mtinka@globaltransit.net List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:03:04 -0000 --nextPart1892857.5o5TlzLuDW Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Thursday, March 08, 2012 11:45:55 PM Aissaoui, Mustapha=20 (Mustapha) wrote: > It is bit awkward that some of the email postings are > being delayed for some reason and as such the flow of > exchange may not seem very natural. Indeed :-). > I think we all agree that having two adjacencies sharing > the same LDP session is not a good thing. We should > indeed allow operators to have an IPv6 adjacency > bootstrap and IPv6 session separately from the IPv4 > adjacency bootstrapping an IPv4 session. This is > consistent with RFC 5036. Agreed. > The knob that we were referring to is different. What we > are saying is that once say an IPv6 adjacency > bootstrapped and IPv6 LDP session, we should allow > flexibility of which address family FECs can be > advertized over that session. In other words, we can > certainly exchange IPv6 unicast FECs, but also IPv4 > unicast FECs, mLDP P2MP FECs, PW FECs, etc. This is all > under the control of the operator who can use the LDP > node capability and/or the FEC filters to decide which > FEC families are allowed over that session. For > instance, you can decide that only IPv6 unicast FECs > should be exchanged over this IPv6 LDP session and this > is fine. Well, the operator assumption, in its default state, would=20 be that if any capabilities are available across a session,=20 they correspond to the AF running the session. So if my LDPv6 is signaling support for Unicast FEC's, mLDP=20 p2mp or mp2mp FEC's, pw FEC's and the rest, I'd naturally=20 assume that these are of the IPv6 AF variety. I suppose we can provide for mis-matched session-capability=20 flexibility here, which vendors can implement as a knob; I=20 wouldn't be entirely opposed to this idea, but would prefer=20 this not to be the default behaviour if at all possible,=20 across all implementations. > Think about it like in BGP which allows advertizing IPv4 > NLRI over an IPv6 TCP connection and vice-versa. You use > it they way you think is appropriate to you but it has > the flexilbility to advertise routes of different > address families over the same IPv6 (or IPv4) TCP > connection. Or like running 6PE :-). Like I mentioned in a previous post about choosing dual- stack over 6PE, we'd rather lose sleep building a dedicated=20 BGP policy per AF than share the same one for both IPv4 and=20 IPv6. Strange things have been known to happen when you=20 share policies, so much so that it ends up never being worth=20 the trouble for some installations. But I digress... :-). Cheers, Mark. --nextPart1892857.5o5TlzLuDW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iQIcBAABAgAGBQJPWNgjAAoJEGcZuYTeKm+GE+gP/1KSq/lRNgYZVgzw5xmuO/xk fWE7LKOX5pnbPAEjKmrs1c4Kv4IywT4xwk3OdhRxJu9v5cOgfv0O49SnVwNOe159 w3xlmP85UDC/pRDZ0fdJJeEPfnIYH/+Aew1mKGMUKcfuezj/M0Xk6vRNZDhBH6f4 bearv8OZ+9E/E5oeN7lo+86cCOxLzbm5kj9rQw+UQjUXCom6YyGSpr4ObgmE6UyD ysQtK+PuWqZw92OE+7iY3rUqIk68tFcyJAgHlU8jG9uW+aa04m5utRL3+B7n8jRA YZndcFTTYTCP1iDgbwT4oAR8i65n56fGYowvAOR4K0YksIz3f0LzVygGv1yokO33 RdkXshoPrAVfXamEV32Z3kisQ0yNEraM4zvx7GA39T+lhVhqUp2RtPi5/OxsQUSe VPcRMLpFcH17o10aWAmhbeYCH2w+sfABJGiXLaLMyDo6dmpKCQqrVZZ7z7VOmiRr A6QWToKe6NDrTprLr6G7F1CObaKTBUXOIbRDrEU7A+i6nBjjGiKtU5kAeJmtrHp0 gBIg+gYeb1DdDGIuV/fFWEV7+2sykkJ7vRlqqAWVmW0mCrlh5Aof5VyyvQFtI62c Khz8GeTRWnxckmKtwwHPtQwkQmoYnVSjVL8WOfoGNU3ukFpdi1c2zm1bQCxk8FeE sQuN+3oOOU/3V+R933U5 =0hZ5 -----END PGP SIGNATURE----- --nextPart1892857.5o5TlzLuDW-- From ietf-ipr@ietf.org Thu Mar 8 09:48:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86821F86B4; Thu, 8 Mar 2012 09:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtg2IPIsZo3U; Thu, 8 Mar 2012 09:48:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57C621F862B; Thu, 8 Mar 2012 09:48:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: lufang@cisco.com, rtorvi@juniper.net, quintin.zhao@huawei.com, ning.so@verizonbusiness.com, czhou@cisco.com, lilianyuan@chinamobile.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308174829.11091.56151.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 09:48:29 -0800 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org Subject: [mpls] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-mpls-ldp-multi-topology-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:48:30 -0000 Dear Luyuan Fang, Raveendra Torvi, Quintin Zhao, Ning So, Chao Zhou, Lianyu= an Li: An IPR disclosure that pertains to your Internet-Draft entitled "LDP Exten= sions for Multi Topology Routing" (draft-ietf-mpls-ldp-multi-topology) was submit= ted to the IETF Secretariat on 2012-03-08 and has been posted on the "IETF Page= of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1707/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-mp= ls- ldp-multi-topology-02.""); The IETF Secretariat From loa@pi.nu Fri Mar 9 01:27:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BD21F85D3 for ; Fri, 9 Mar 2012 01:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSPvsW63Zm+I for ; Fri, 9 Mar 2012 01:27:44 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 25F2621F85D2 for ; Fri, 9 Mar 2012 01:27:43 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 49E332A8002; Fri, 9 Mar 2012 10:27:42 +0100 (CET) Message-ID: <4F59CD0F.6060801@pi.nu> Date: Fri, 09 Mar 2012 10:27:43 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Reminder regarding IPR on draft-ietf-mpls-ldp-gtsm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:27:45 -0000 Working Group, The authors have asked for draft-ietf-mpls-ldp-gtsm to be sent to WG last call. Before doing this, we would like to check whether there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies todraft-ietf-mpls-ldp-gtsm? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From cpignata@cisco.com Fri Mar 9 06:23:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7E821F867F for ; Fri, 9 Mar 2012 06:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Lzjz-FnTvKA for ; Fri, 9 Mar 2012 06:23:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3399221F867E for ; Fri, 9 Mar 2012 06:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=1618; q=dns/txt; s=iport; t=1331302986; x=1332512586; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=R5BTWdrUUgDQNQYQD2goSRuxLzFirxkll5JkBUU4QYM=; b=C8TrowFhanAJDD7CAxfzY0ESlUK2qZ5LaJ7A8Ab3N1fSlH54NGuAsK9V JotW0ywLyb6jrmSOhs8qOK5fsgDV8/XVUGe8NBwRZ+P2OZwGeCKjgYxwv crmCkpKvGZvOTAdggQr1+bvqcIllkPYpVzEy1cBnP517eKWYnXh13v6vg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMYRWk+tJV2Y/2dsb2JhbABDtTKBB4IKAQEBAwEBAQEPASc0BgUOAgtGGwwwBhMih2MFC5wPAZ59BASPc2MEiFOMdpAcgwGBPg X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="scan'208";a="65115071" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2012 14:23:05 +0000 Received: from rtp-cpignata-89110.cisco.com (rtp-cpignata-89110.cisco.com [10.117.115.59]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29EN5vg018593; Fri, 9 Mar 2012 14:23:05 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Carlos Pignataro In-Reply-To: <4F59CD0F.6060801@pi.nu> Date: Fri, 9 Mar 2012 09:23:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F59CD0F.6060801@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" Subject: Re: [mpls] Reminder regarding IPR on draft-ietf-mpls-ldp-gtsm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:23:07 -0000 Chairs, WG, I am not aware of any IPR (including patent rights) applicable to this = document. Thanks, -- Carlos. On Mar 9, 2012, at 4:27 AM, Loa Andersson wrote: >=20 > Working Group, >=20 >=20 > The authors have asked for draft-ietf-mpls-ldp-gtsm to be sent to > WG last call. Before doing this, we would like to check whether > there is IPR on the document that needs to be disclosed. >=20 > Are you aware of any IPR that applies todraft-ietf-mpls-ldp-gtsm? > If so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond = to this email regardless of whether or not you are aware of any relevant = IPR. This document will not advance to the next stage until a response = has been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of = any IPR that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, Loa >=20 > (as MPLS WG co-chair) >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: = loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From iesg-secretary@ietf.org Fri Mar 9 12:51:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B969121E8044; Fri, 9 Mar 2012 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v5kwroiG6ub; Fri, 9 Mar 2012 12:51:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEB21E803F; Fri, 9 Mar 2012 12:51:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309205157.8304.55419.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 12:51:57 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (An Overview of the OAM Tool Set for MPLS based Transport Networks) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 20:51:59 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'An Overview of the OAM Tool Set for MPLS based Transport Networks' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From nurit.sprecher@nsn.com Sun Mar 11 03:24:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4679921F8617 for ; Sun, 11 Mar 2012 03:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNkEPPW81uEo for ; Sun, 11 Mar 2012 03:24:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF4721F8607 for ; Sun, 11 Mar 2012 03:24:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2BAOfo8027376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Mar 2012 11:24:41 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2BAOdWq020163; Sun, 11 Mar 2012 11:24:41 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 11:24:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 11:24:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-ietf-mpls-tp-oam-analysis-08.txt Thread-Index: Acz7vxUegE1oPf4ATvapafjHu4siKQDscmDg From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 11 Mar 2012 10:24:39.0512 (UTC) FILETIME=[2A6DAD80:01CCFF71] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2297 X-purgate-ID: 151667::1331461481-000033AC-FE21A8DB/0-0/0-0 Cc: "ext Luyuan Fang \(lufang\)" Subject: [mpls] FW: I-D Action: draft-ietf-mpls-tp-oam-analysis-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 10:24:47 -0000 Hello, Please note to a new version of the document. This version was updated to resolve the comments provided on the list by the AD. Best regards, Nurit and Luyuan -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext internet-drafts@ietf.org Sent: Tuesday, March 06, 2012 7:32 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: I-D Action: draft-ietf-mpls-tp-oam-analysis-08.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 : An Overview of the OAM Tool Set for MPLS based Transport Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-08.txt Pages : 22 Date : 2012-03-06 This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-08.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-08.tx t _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From daniel@olddog.co.uk Sun Mar 11 12:57:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCBF21F86CF for ; Sun, 11 Mar 2012 12:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGeDVjeUnXMX for ; Sun, 11 Mar 2012 12:57:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3657021F86CE for ; Sun, 11 Mar 2012 12:57:09 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2BJv8lt004276 for ; Sun, 11 Mar 2012 19:57:08 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2BJv7tB004265 for ; Sun, 11 Mar 2012 19:57:07 GMT From: "Daniel King" To: References: <20120308114619.20909.54154.idtracker@ietfa.amsl.com> In-Reply-To: <20120308114619.20909.54154.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 19:57:06 -0000 Message-ID: <001f01ccffc1$2317b8f0$69472ad0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWu9PD1kAlaOkWUFvvaKM9Vlx8spXSCeSw Content-Language: en-gb Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:57:10 -0000 Hi All, This document was recently updated to address recent IESG Telechat comments. The authors feel all remaining Discuss points have now been addressed. Br, Dan. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: 08 March 2012 11:46 To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-07.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 : Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview Author(s) : Daniel King Venkatesan Mahalingam Filename : draft-ietf-mpls-tp-mib-management-overview-07.txt Pages : 26 Date : 2012-03-08 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi ew-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvie w-07.txt _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Sun Mar 11 15:21:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92521F8601 for ; Sun, 11 Mar 2012 15:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiiXkpUBCbIr for ; Sun, 11 Mar 2012 15:21:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0E24821F85A3 for ; Sun, 11 Mar 2012 15:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1386; q=dns/txt; s=iport; t=1331504466; x=1332714066; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=3G4C5oYCL6gGyQ1lE+OXDtJGu5Yc6LHzBu9Tu9Dq7do=; b=lrcS9Iom42vvRHyQ4SDOEg/dqjFGDKZPK4ZnM6/KiGgzMOjZlziMpBNu inT8NJwZbOSQgIFbC8CVFVv7RAvOfuAWT3fW8aazUlbhgpNro2xQ29PZW 0yzjZjJGQAHrFIMpxSMmRGIOdUPvhaADDpF9acVlk/akGrItLwC2FTtVn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEckXU+tJV2d/2dsb2JhbABBtVKBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHaAufagGNMohNBJAeYwSIVJ0bgwGBNgc X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="65504887" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 11 Mar 2012 22:21:04 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2BML4gg008291; Sun, 11 Mar 2012 22:21:04 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 17:21:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Mar 2012 17:21:03 -0500 Message-ID: <238542D917511A45B6B8AA806E875E2508219BC1@XMB-RCD-201.cisco.com> In-Reply-To: <4F43A56E.1080606@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Slots requests for IETF 83 - Paris Thread-Index: Aczwomfwc5LUlT/WS9CioSDJSjRAWQPLw4cQ References: <4F43A56E.1080606@alcatel-lucent.com> From: "Luyuan Fang (lufang)" To: "Martin Vigoureux" , "MPLS @ IETF" X-OriginalArrivalTime: 11 Mar 2012 22:21:04.0064 (UTC) FILETIME=[3F37CC00:01CCFFD5] Subject: Re: [mpls] Slots requests for IETF 83 - Paris X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 22:21:06 -0000 Martin, Draft name: draft-ietf-mpls-tp-security-framework-03 Speaker: Luyuan Fang Desired duration: 10m Hope we are not too late requesting. I initially planned to upload new version which addresses all comments in the last call, be done, no presentation needed. But look like we are going to have substantial changes in the new version, need to update the WG. BTW, we are still working on 03, would not be able to upload tomorrow, but definitely will be uploaded when system re-opens in Paris. Thanks, Luyuan > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Martin Vigoureux > Sent: Tuesday, February 21, 2012 9:09 AM > To: MPLS @ IETF > Subject: [mpls] Slots requests for IETF 83 - Paris >=20 > All, >=20 > it is time we start building the agenda for Paris. > Please send *me* (cc: chairs) your request for a presentation slot, > indicating: > draft name, speaker and desired duration (presentation + Q&As). >=20 > Requests with missing information will not be considered. >=20 > Please send the requests before March 12th. >=20 > Please be aware that we might not be able to satisfy all requests. >=20 > Thank you. >=20 > regards, > martin >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From fu.xihua@zte.com.cn Sun Mar 11 19:38:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5801C21F8600 for ; Sun, 11 Mar 2012 19:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.826 X-Spam-Level: X-Spam-Status: No, score=-90.826 tagged_above=-999 required=5 tests=[AWL=4.209, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id da+MIOdSUaHW for ; Sun, 11 Mar 2012 19:38:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id C030B21F85AA for ; Sun, 11 Mar 2012 19:38:15 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Mon, 12 Mar 2012 10:05:42 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 65905.806486374; Mon, 12 Mar 2012 10:38:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2C2bthS035397 for ; Mon, 12 Mar 2012 10:37:55 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Mon, 12 Mar 2012 10:38:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-12 10:37:56, Serialize complete at 2012-03-12 10:37:56 Content-Type: multipart/alternative; boundary="=_alternative 000E8681482579BF_=" X-MAIL: mse02.zte.com.cn q2C2bthS035397 Subject: Re: [mpls] I-D Action: draft-fuxh-mpls-delay-loss-te-framework-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 02:38:17 -0000 This is a multipart message in MIME format. --=_alternative 000E8681482579BF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSBoYXZlIHVwbG9hZGVkIHRoZSAwNCB2ZXJzaW9uIHdoaWNoIGFkZHJlc3Nl cyBhbGwgY29tbWVudHMgcmFzZWQgaW4gdGhlIA0KbGFzdCBtZWV0aW5nIGFuZCBtYWlsaW5nLWxp c3QuDQpPbmUgbm90ZSBpcyB0aGF0IHdlIGNoYW5nZWQgdGhlIHRpdGxlIHRvICJMb3NzIGFuZCBE ZWxheSBUcmFmZmljIA0KRW5naW5lZXJpbmcgRnJhbWV3b3JrIGZvciBNUExTIi4NCkFueSBjb21t ZW50cyBhcmUgd2VsY29tZS4NCg0KQmVzdCBSZWdhcmRzLA0KDQpYaWh1YQ0KDQoNCmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyANCreivP7IyzogIGktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3Jn DQoyMDEyLTAzLTA5IM/CzucgMDI6MjkNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KDQoNCsrV vP7Iyw0KaS1kLWFubm91bmNlQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCkktRCBBY3Rpb246IGRy YWZ0LWZ1eGgtbXBscy1kZWxheS1sb3NzLXRlLWZyYW1ld29yay0wNC50eHQNCg0KDQoNCg0KDQoN Cg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQoNCiAgICAgICAgICAgICAgICAgVGl0bGUgICAg ICAgICAgIDogTG9zcyBhbmQgRGVsYXkgVHJhZmZpYyBFbmdpbmVlcmluZyANCkZyYW1ld29yayBm b3IgTVBMUw0KICAgICAgICAgICAgICAgICBBdXRob3IocykgICAgICAgOiBYaWh1YSBGdQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICBWaXNod2FzIE1hbnJhbA0KICAgICAgICAgICAgICAgICAg ICAgICAgICBEYXZlIE1jRHlzYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kcmV3IE1h bGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNwZW5jZXIgR2lhY2Fsb25lDQogICAgICAg ICAgICAgICAgICAgICAgICAgIE1hbGNvbG0gQmV0dHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgUWlsZWkgV2FuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIERyYWtlDQogICAg ICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IA0KZHJhZnQtZnV4aC1tcGxzLWRlbGF5LWxv c3MtdGUtZnJhbWV3b3JrLTA0LnR4dA0KICAgICAgICAgICAgICAgICBQYWdlcyAgICAgICAgICAg OiAxNQ0KICAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEyLTAzLTA4DQoNCiAg IFdpdGggbW9yZSBhbmQgbW9yZSBlbnRlcnByaXNlcyB1c2luZyBjbG91ZCBiYXNlZCBzZXJ2aWNl cywgdGhlDQogICBkaXN0YW5jZXMgYmV0d2VlbiB0aGUgdXNlciBhbmQgdGhlIGFwcGxpY2F0aW9u cyBhcmUgZ3Jvd2luZy4gIEEgbG90DQogICBvZiB0aGUgY3VycmVudCBhcHBsaWNhdGlvbnMgYXJl IGRlc2lnbmVkIHRvIHdvcmsgYWNyb3NzIExBTidzIGFuZA0KICAgaGF2ZSB2YXJpb3VzIGluaGVy ZW50IGFzc3VtcHRpb25zLiAgRm9yIG11bHRpcGxlIGFwcGxpY2F0aW9ucyBzdWNoIGFzDQogICBI aWdoIFBlcmZvcm1hbmNlIENvbXB1dGluZyBhbmQgRWxlY3Ryb25pYyBGaW5hbmNpYWwgbWFya2V0 cywgdGhlDQogICByZXNwb25zZSB0aW1lcyBhcmUgY3JpdGljYWwgYXMgaXMgcGFja2V0IGxvc3Ms IHdoaWxlIG90aGVyDQogICBhcHBsaWNhdGlvbnMgcmVxdWlyZSBtb3JlIHRocm91Z2hwdXQuDQoN CiAgIFtSRkMzMDMxXSBkZXNjcmliZXMgdGhlIGFyY2hpdGVjdHVyZSBvZiBNUExTIGJhc2VkIG5l dHdvcmtzLiAgVGhpcw0KICAgZHJhZnQgZXh0ZW5kcyB0aGUgTVBMUyBhcmNoaXRlY3R1cmUgdG8g YWxsb3cgZm9yIGxhdGVuY3ksIGxvc3MgYW5kDQogICBqaXR0ZXIgYXMgcHJvcGVydGllcy4gIEl0 IGRlc2NyaWJlcyByZXF1aXJlbWVudHMgYW5kIGNvbnRyb2wgcGxhbmUNCiAgIGltcGxpY2F0aW9u IGZvciBsYXRlbmN5IGFuZCBwYWNrZXQgbG9zcyBhcyBhIHRyYWZmaWMgZW5naW5lZXJpbmcNCiAg IHBlcmZvcm1hbmNlIG1ldHJpYyBpbiB0b2RheSdzIG5ldHdvcmsgd2hpY2ggaXMgY29uc2lzdGlu ZyBvZg0KICAgcG90ZW50aWFsbHkgbXVsdGlwbGUgbGF5ZXJzIG9mIHBhY2tldCB0cmFuc3BvcnQg bmV0d29yayBhbmQgb3B0aWNhbA0KICAgdHJhbnNwb3J0IG5ldHdvcmsgaW4gb3JkZXIgdG8gbWFr ZSBhIGFjY3VyYXRlIGVuZC10by1lbmQgbGF0ZW5jeSBhbmQNCiAgIGxvc3MgcHJlZGljdGlvbiBi ZWZvcmUgYSBwYXRoIGlzIGVzdGFibGlzaGVkLg0KDQogICBOb3RlIE1QTFMgYXJjaGl0ZWN0dXJl IGZvciBNdWx0aWNhc3Qgd2lsbCBiZSB0YWtlbiB1cCBpbiBhIGZ1dHVyZQ0KICAgdmVyc2lvbiBv ZiB0aGUgZHJhZnQuDQoNCg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZ1eGgtbXBscy1kZWxheS1s b3NzLXRlLWZyYW1ld29yay0wNC50eHQNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KDQpUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQpmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZ1eGgtbXBscy1kZWxheS1sb3Nz LXRlLWZyYW1ld29yay0wNC50eHQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5v dW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoN Cg0K --=_alternative 000E8681482579BF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFjZT0iQ2FsaWJyaSI+SGkgQWxsLDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzgwMDA4MCBmYWNlPSJDYWxpYnJp Ij5XZSBoYXZlIHVwbG9hZGVkIHRoZSAwNCB2ZXJzaW9uDQp3aGljaCBhZGRyZXNzZXMgYWxsIGNv bW1lbnRzIHJhc2VkIGluIHRoZSBsYXN0IG1lZXRpbmcgYW5kIG1haWxpbmctbGlzdC48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFjZT0iQ2FsaWJyaSI+T25lIG5vdGUg aXMgdGhhdCB3ZSBjaGFuZ2VkDQp0aGUgdGl0bGUgdG8gJnF1b3Q7TG9zcyBhbmQgRGVsYXkgVHJh ZmZpYyBFbmdpbmVlcmluZyBGcmFtZXdvcmsgZm9yIE1QTFMmcXVvdDsuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jODAwMDgwIGZhY2U9IkNhbGlicmkiPkFueSBjb21tZW50cyBhcmUg d2VsY29tZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSM4MDAwODAgZmFj ZT0iQ2FsaWJyaSI+QmVzdCBSZWdhcmRzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9IzgwMDA4MCBmYWNlPSJDYWxpYnJpIj5YaWh1YTwvZm9udD4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2I+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7 aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMi0wMy0wOSDPws7nIDAyOjI5PC9mb250Pg0KPHRhYmxlIGJvcmRl cj4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIGJnY29sb3I9d2hpdGU+DQo8ZGl2IGFsaWduPWNlbnRl cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PC9mb250PjwvZGl2PjwvdGFibGU+DQo8YnI+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+aS1kLWFubm91bmNlQGlldGYub3JnPC9mb250Pg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5JLUQgQWN0aW9uOiBk cmFmdC1mdXhoLW1wbHMtZGVsYXktbG9zcy10ZS1mcmFtZXdvcmstMDQudHh0PC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiBMb3NzIGFuZCBEZWxheSBUcmFmZmljIEVuZ2luZWVyaW5nDQpGcmFt ZXdvcmsgZm9yIE1QTFM8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogWGlo dWEgRnU8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1Zpc2h3YXMgTWFu cmFsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtEYXZlIE1jRHlzYW48 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO0FuZHJldyBNYWxpczxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7U3BlbmNlciBHaWFjYWxvbmU8YnI+ DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO01hbGNvbG0gQmV0dHM8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO1FpbGVpIFdhbmc8YnI+DQogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO0pvaG4gRHJha2U8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KRmlsZW5hbWUgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1mdXhoLW1wbHMtZGVsYXktbG9zcy10ZS1m cmFtZXdvcmstMDQudHh0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgOiAxNTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQpEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7OiAyMDEyLTAzLTA4PGJyPg0KPGJyPg0KICZuYnNwOyBXaXRoIG1vcmUgYW5kIG1vcmUg ZW50ZXJwcmlzZXMgdXNpbmcgY2xvdWQgYmFzZWQgc2VydmljZXMsIHRoZTxicj4NCiAmbmJzcDsg ZGlzdGFuY2VzIGJldHdlZW4gdGhlIHVzZXIgYW5kIHRoZSBhcHBsaWNhdGlvbnMgYXJlIGdyb3dp bmcuICZuYnNwO0ENCmxvdDxicj4NCiAmbmJzcDsgb2YgdGhlIGN1cnJlbnQgYXBwbGljYXRpb25z IGFyZSBkZXNpZ25lZCB0byB3b3JrIGFjcm9zcyBMQU4ncyBhbmQ8YnI+DQogJm5ic3A7IGhhdmUg dmFyaW91cyBpbmhlcmVudCBhc3N1bXB0aW9ucy4gJm5ic3A7Rm9yIG11bHRpcGxlIGFwcGxpY2F0 aW9ucw0Kc3VjaCBhczxicj4NCiAmbmJzcDsgSGlnaCBQZXJmb3JtYW5jZSBDb21wdXRpbmcgYW5k IEVsZWN0cm9uaWMgRmluYW5jaWFsIG1hcmtldHMsIHRoZTxicj4NCiAmbmJzcDsgcmVzcG9uc2Ug dGltZXMgYXJlIGNyaXRpY2FsIGFzIGlzIHBhY2tldCBsb3NzLCB3aGlsZSBvdGhlcjxicj4NCiAm bmJzcDsgYXBwbGljYXRpb25zIHJlcXVpcmUgbW9yZSB0aHJvdWdocHV0Ljxicj4NCjxicj4NCiAm bmJzcDsgW1JGQzMwMzFdIGRlc2NyaWJlcyB0aGUgYXJjaGl0ZWN0dXJlIG9mIE1QTFMgYmFzZWQg bmV0d29ya3MuICZuYnNwO1RoaXM8YnI+DQogJm5ic3A7IGRyYWZ0IGV4dGVuZHMgdGhlIE1QTFMg YXJjaGl0ZWN0dXJlIHRvIGFsbG93IGZvciBsYXRlbmN5LCBsb3NzDQphbmQ8YnI+DQogJm5ic3A7 IGppdHRlciBhcyBwcm9wZXJ0aWVzLiAmbmJzcDtJdCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIGFu ZCBjb250cm9sDQpwbGFuZTxicj4NCiAmbmJzcDsgaW1wbGljYXRpb24gZm9yIGxhdGVuY3kgYW5k IHBhY2tldCBsb3NzIGFzIGEgdHJhZmZpYyBlbmdpbmVlcmluZzxicj4NCiAmbmJzcDsgcGVyZm9y bWFuY2UgbWV0cmljIGluIHRvZGF5J3MgbmV0d29yayB3aGljaCBpcyBjb25zaXN0aW5nIG9mPGJy Pg0KICZuYnNwOyBwb3RlbnRpYWxseSBtdWx0aXBsZSBsYXllcnMgb2YgcGFja2V0IHRyYW5zcG9y dCBuZXR3b3JrIGFuZCBvcHRpY2FsPGJyPg0KICZuYnNwOyB0cmFuc3BvcnQgbmV0d29yayBpbiBv cmRlciB0byBtYWtlIGEgYWNjdXJhdGUgZW5kLXRvLWVuZCBsYXRlbmN5DQphbmQ8YnI+DQogJm5i c3A7IGxvc3MgcHJlZGljdGlvbiBiZWZvcmUgYSBwYXRoIGlzIGVzdGFibGlzaGVkLjxicj4NCjxi cj4NCiAmbmJzcDsgTm90ZSBNUExTIGFyY2hpdGVjdHVyZSBmb3IgTXVsdGljYXN0IHdpbGwgYmUg dGFrZW4gdXAgaW4gYSBmdXR1cmU8YnI+DQogJm5ic3A7IHZlcnNpb24gb2YgdGhlIGRyYWZ0Ljxi cj4NCjxicj4NCjxicj4NCjxicj4NCkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxi cj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZ1eGgtbXBscy1k ZWxheS1sb3NzLXRlLWZyYW1ld29yay0wNC50eHQ8YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQo8YnI+DQpUaGlzIEludGVybmV0LURyYWZ0IGNh biBiZSByZXRyaWV2ZWQgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1mdXhoLW1wbHMtZGVsYXktbG9zcy10ZS1mcmFtZXdvcmstMDQudHh0PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJ LUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPg0KSS1ELUFubm91bmNlQGlldGYub3JnPGJyPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8YnI+DQpJ bnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bDxicj4NCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PGJyPg0K PGJyPg0KPC90dD48L2ZvbnQ+DQo= --=_alternative 000E8681482579BF_=-- From internet-drafts@ietf.org Sun Mar 11 19:57:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D349921F85D7; Sun, 11 Mar 2012 19:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 331d36SoRyeU; Sun, 11 Mar 2012 19:57:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738A321F85B1; Sun, 11 Mar 2012 19:57:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312025717.13597.99945.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 19:57:17 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 02:57:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Ning So Filename : draft-ietf-mpls-ldp-multi-topology-03.txt Pages : 18 Date : 2012-03-11 Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-03.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-multi-topology-03.txt From cts@etri.re.kr Mon Mar 12 01:41:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C321F8687 for ; Mon, 12 Mar 2012 01:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.851 X-Spam-Level: X-Spam-Status: No, score=-100.851 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1NBBGvkpVZN for ; Mon, 12 Mar 2012 01:41:45 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3921F86CF for ; Mon, 12 Mar 2012 01:41:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 12 Mar 2012 17:41:41 +0900 Message-ID: <4E45B4AAC0E1F04CAADDC9B606BB198F02AD3668@email1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-cheung-mpls-tp-mesh-protection-05.txt thread-index: Ac0AJPZxbKyc0hhWSD6JnLgA/jtOOgABqxdA From: =?utf-8?B?7KCV7YOc7Iud?= To: Subject: [mpls] FW: New Version Notification fordraft-cheung-mpls-tp-mesh-protection-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:41:45 -0000 RGVhciBNUExTIFdHLCANCg0KUGxlYXNlIG5vdGUgdGhhdCB3ZSBzdWJtaXR0ZWQgYSBuZXcgdmVy c2lvbiBvZiB0aGUgTVBMUy1UUCBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uLiANCg0KSW4gdGhpcyB2 ZXJzaW9uLCBmb2xsb3dpbmcgY2hhbmdlcyB3ZXJlIG1hZGU6IA0KICAtIFVwZGF0ZSB0byB0aGUg U01QIG9wZXJhdGlvbiBhcyBwcmVzZW50ZWQgaW4gdGhlIGxhc3QgVGFpcGVpIG1lZXRpbmcgDQog IC0gRGVmaW5lIFNNUCBtZXNzYWdlIGZvcm1hdCANCiAgLSBFZGl0b3JpYWwgY2hhbmdlcyANCg0K QSBVUkwgZm9yIHRoaXMgSS1EIGlzOiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWNoZXVuZy1tcGxzLXRwLW1lc2gtcHJvdGVjdGlvbi0wNS50eHQNCg0KV2Ugd291 bGQgYXBwcmVjaWF0ZSB5b3VyIHJldmlldyBhbmQgY29tbWVudHMgb24gb3VyIGRvY3VtZW50LiAN CiAgDQpCZXN0IHJlZ2FyZHMsIA0KVGFlc2lrDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDEyLCAyMDEyIDQ6NTIgUE0NClRvOiDs oJXtg5zsi50NCkNjOiB3eWFhY292QGdtYWlsLmNvbTsg66WY7KCV64+ZOyBudXJpdC5zcHJlY2hl ckBuc24uY29tOyBkYW5pZWxAb2xkZG9nLmNvLnVrDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yZHJhZnQtY2hldW5nLW1wbHMtdHAtbWVzaC1wcm90ZWN0aW9uLTA1LnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGV1bmctbXBscy10cC1tZXNoLXByb3Rl Y3Rpb24tMDUudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFlLXNpayBD aGV1bmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRy YWZ0LWNoZXVuZy1tcGxzLXRwLW1lc2gtcHJvdGVjdGlvbg0KUmV2aXNpb246CSAwNQ0KVGl0bGU6 CQkgTVBMUy1UUCBTaGFyZWQgTWVzaCBQcm90ZWN0aW9uDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0w My0xMg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIz DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gdG8g YWRkcmVzcyB0aGUgcmVxdWlyZW1lbnQgdG8NCiAgIHN1cHBvcnQgcHJvdGVjdGlvbiBvZiBMYWJl bCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW4gYW4gTVBMUw0KICAgVHJhbnNwb3J0IFByb2ZpbGUg KE1QTFMtVFApIG1lc2ggdG9wb2xvZ3kuICBUaGUgc2hhcmVkIG1lc2gNCiAgIHByb3RlY3Rpb24g bWVjaGFuaXNtIGVuYWJsZXMgbXVsdGlwbGUgcHJvdGVjdGlvbiBwYXRocyB3aXRoaW4gYQ0KICAg c2hhcmVkIG1lc2ggcHJvdGVjdGlvbiBkb21haW4gdG8gc2hhcmUgcHJvdGVjdGlvbiByZXNvdXJj ZXMgZm9yIHRoZQ0KICAgcHJvdGVjdGlvbiBvZiB3b3JraW5nIHBhdGhzIGJ5IGNvb3JkaW5hdGlu ZyBwcm90ZWN0aW9uIHN3aXRjaGluZw0KICAgb3BlcmF0aW9ucyBhY2NvcmRpbmcgdG8gdGhlIHBy aW9yaXR5IGFzc2lnbmVkIHRvIGVhY2ggZW5kLXRvLWVuZA0KICAgbGluZWFyIHByb3RlY3Rpb24g ZG9tYWluLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiBhIGpvaW50IEludGVy bmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UNCiAgIChJRVRGKSAvIEludGVybmF0aW9uYWwgVGVs ZWNvbW11bmljYXRpb25zIFVuaW9uIFRlbGVjb21tdW5pY2F0aW9ucw0KICAgU3RhbmRhcmRpemF0 aW9uIFNlY3RvciAoSVRVLVQpIGVmZm9ydCB0byBpbmNsdWRlIGFuIE1QTFMgVHJhbnNwb3J0DQog ICBQcm9maWxlIHdpdGhpbiB0aGUgSUVURiBNUExTIGFuZCBQV0UzIGFyY2hpdGVjdHVyZXMgdG8g c3VwcG9ydCB0aGUNCiAgIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzIG9mIGEgcGFj a2V0IHRyYW5zcG9ydCBuZXR3b3JrIGFzDQogICBkZWZpbmVkIGJ5IHRoZSBJVFUtVC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From internet-drafts@ietf.org Mon Mar 12 01:53:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87021F8720; Mon, 12 Mar 2012 01:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2B7REZPsukN; Mon, 12 Mar 2012 01:53:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B8821F8716; Mon, 12 Mar 2012 01:53:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312085303.31706.10320.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 01:53:03 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:53:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Traffic Engineering (TE) Management Information = Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-02.txt Pages : 46 Date : 2012-03-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-02.txt From internet-drafts@ietf.org Mon Mar 12 04:44:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3723B21F870A; Mon, 12 Mar 2012 04:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUB2-8mGVSqh; Mon, 12 Mar 2012 04:44:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E821F86EA; Mon, 12 Mar 2012 04:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312114454.16571.94730.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 04:44:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 11:44:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Handling MPLS-TP OAM Packets Targeted at Internal MIPs Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-01.txt Pages : 15 Date : 2012-03-12 The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mip-mep-map-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mip-mep-map-01.txt From Rolf.Winter@neclab.eu Mon Mar 12 04:51:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C9621F8775 for ; Mon, 12 Mar 2012 04:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqiY-Q-lfGNM for ; Mon, 12 Mar 2012 04:51:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 180F221F8778 for ; Mon, 12 Mar 2012 04:51:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1743910084C for ; Mon, 12 Mar 2012 12:51:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG4NJnI-ajL4 for ; Mon, 12 Mar 2012 12:51:46 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id EEB05100830 for ; Mon, 12 Mar 2012 12:51:40 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 12:51:32 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: I-D Action: draft-ietf-mpls-tp-mip-mep-map-01.txt Thread-Index: AQHNAEWiSJe2/Z1N+UmGZi6I81KWLJZmiuaQ Date: Mon, 12 Mar 2012 11:51:33 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D250345A7@DAPHNIS.office.hd> References: <20120312114454.16571.94730.idtracker@ietfa.amsl.com> In-Reply-To: <20120312114454.16571.94730.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 11:51:42 -0000 Hi WG, text-wise a few things have changed here and there but nothing fundamental.= At this point we would like to solicit feedback from the WG. Thanks in adv= ance! Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Montag, 12. M=E4rz 2012 12:45 > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: I-D Action: draft-ietf-mpls-tp-mip-mep-map-01.txt >=20 >=20 > 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. >=20 > Title : Handling MPLS-TP OAM Packets Targeted at > Internal MIPs > Author(s) : Adrian Farrel > Hideki Endo > Rolf Winter > Yoshinori Koike > Manuel Paul > Filename : draft-ietf-mpls-tp-mip-mep-map-01.txt > Pages : 15 > Date : 2012-03-12 >=20 > The Framework for Operations, Administration and Maintenance (OAM) > within the MPLS Transport Profile (MPLS-TP) describes how > Maintenance > Entity Group Intermediate Points (MIPs) may be situated within > network nodes at the incoming and outgoing interfaces. >=20 > This document describes a way of forming OAM messages so that they > can be targeted at MIPs on incoming or MIPs on outgoing interfaces, > forwarded correctly through the "switch fabric", and handled > efficiently in node implementations where there is no distinction > between the incoming and outgoing MIP. >=20 > This document is a product of a joint Internet Engineering Task > Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mip-mep-map- > 01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mip-mep-map- > 01.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wwwrun@rfc-editor.org Mon Mar 12 05:56:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFEC21F86EB for ; Mon, 12 Mar 2012 05:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tINyxeSoEALL for ; Mon, 12 Mar 2012 05:56:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A7DC121F86C8 for ; Mon, 12 Mar 2012 05:56:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 39EE772E002; Mon, 12 Mar 2012 05:56:03 -0700 (PDT) To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20120312125603.39EE772E002@rfc-editor.org> Date: Mon, 12 Mar 2012 05:56:03 -0700 (PDT) Cc: mpls@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC5036 (3155) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:56:30 -0000 The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=3155 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.5.1.2.1 Original Text ------------- - The LDP protocol version is not supported by the receiver, d or it is supported but is not the version negotiated for the session during session establishment. This is a fatal error signaled by the Bad Protocol Version Status Code. Corrected Text -------------- - The LDP protocol version is not supported by the receiver, or it is supported but is not the version negotiated for the session during session establishment. This is a fatal error signaled by the Bad Protocol Version Status Code. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From rajiva@cisco.com Mon Mar 12 07:03:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2940121E8027 for ; Mon, 12 Mar 2012 07:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.762 X-Spam-Level: X-Spam-Status: No, score=-9.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaaQ0-AfOIWr for ; Mon, 12 Mar 2012 07:03:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 45BC321E8011 for ; Mon, 12 Mar 2012 07:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5819; q=dns/txt; s=iport; t=1331561014; x=1332770614; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yxUXQ4CkQ7K5L/egW1gVeSYpAjx/F5+DZylEmKcIYUk=; b=FzS1q55P18lZdq4XdnMj2eSlkmrhv36alrNqS++mGS5yvwMDTVtwXZ07 47PX2i/oCufD0OSGpK9h3h3OGxbK7h7otEeOtKZDNEjc2XPUmRmHuTxi7 xOy+u/sJbv56f9Ll59NaSXaVZ356Mrf/hTLpnXVjl1izh+8cgjvMNAYd9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABYBXk+tJXG+/2dsb2JhbABDtUyBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah2MFnRcBnlmKNYVpYwSIVJ0bgwGBPg X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65674960" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 14:03:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CE3XAJ030135; Mon, 12 Mar 2012 14:03:33 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:03:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:03:33 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA087@XMB-RCD-111.cisco.com> In-Reply-To: <2D026530-B8AD-4E40-BC45-0842388C8FFA@castlepoint.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Qmv+HkHqUp0AQjeEDendsAsqvAAAMoSA References: <00c101ccf7cf$1af422c0$4001a8c0@gateway.2wire.net> <7F2A789A-D8C6-47C6-9B09-85038B949E67@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C078BE609@XMB-RCD-111.cisco.com> <2D026530-B8AD-4E40-BC45-0842388C8FFA@castlepoint.net> From: "Rajiv Asati (rajiva)" To: "Shane Amante" X-OriginalArrivalTime: 12 Mar 2012 14:03:33.0742 (UTC) FILETIME=[E973E0E0:01CD0058] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:03:36 -0000 Hi Shane, Please see inline, > So, please tell me how I'm supposed to ping/traceroute to this 32-bit "Router > ID" in this new IPv6-only world, just like I do today in IPv4 today, to verify > reachability? =20 Good question. We should be pinging/tracerouting peer's Transport address or TCP connection address, not Router ID. This is similar to what we typically do with OSPF, for ex. I am pasting the sample show command output (from Cisco and Juniper routers) to better illustrate this (notice ^^^^^^). While the output shows IPv4 transport address since the session is LDPoIPv4, it would be an IPv6 addresses if the session was LDPoIPv6. =20 // JUNIPER ROUTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D user@host> show ldp neighbor extensive ... Transport address: 10.255.245.5, Configuration sequence: 6 ^^^^^^^^^^^^^^^^^^^^^^^^ .. // CISCO ROUTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RP/0/RP0/CPU0:router# show mpls ldp neighbor =20 =20 Peer LDP Identifier: 10.44.44.44:0 TCP connection: 10.44.44.44:65535 - 10.33.33.33:646 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Graceful Restart: No State: Oper; Msgs sent/rcvd: 49/46 Up time: 00:33:33 LDP Discovery Sources:=20 POS 0/1/0/0 ... // > Usually, this is one of the first steps in troubleshooting a > problem. I'm curious if we've gotten lazy by assuming dual-stack v4 + v6 will > "always be there", so I can just use v4 to ping/traceroute to a 32-bit Router ID Not at all. In fact, we continue to consider IPv6-only (which will exist for long long time) and add the relevant/missing pieces to accommodate dual-stack (which will disappear sooner or later) while thinking about IPv6 LDP.=20 Again, the router ID is a 32-bit quantity, whether it is used for IPv6 BGP, or IPv6 OSPF or IPv6 LDP or all of them. > FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically, a > protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire; > however, "out-of-band" I assign a IPv4-mapped IPv6 address to a Loopback > interface on a router and inject it into my "IPv6-only" IGP in order to > preserve my ability to see it in the topology (in the routing table), and > simultaneously am able to ping/traceroute to it to ensure that the Loopback > interface is "alive". But, this is a kludge, because now I have to keep the > ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address on a > Loopback interface ... Aaah, I follow it now. Thanks for clarifying it. This could be a reasonable option for a deployment, but certainly not pretty. =20 Interestingly, there are few deployments that actually use the last (non-zero) 32-bits of the assigned "IPv6 prefix" as the Router Id for IPv6 BGP and IPv6 OSPF. This doesn't require any IPv4-mapped-IPv6 address usage and works reasonably well for consistency. This depends on the addressing schema though. Cheers, Rajiv > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Friday, March 02, 2012 2:02 AM > To: Rajiv Asati (rajiva) > Cc: t.petch; Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, >=20 > On Mar 1, 2012, at 11:02 PM, Rajiv Asati (rajiva) wrote: > > Hi Shane, > > > > Thankfully, neither approaches are embraced/recommended/considered. > > > >> a) Do I need to keep IS-IS or OSPFv3 kicking around IPv4, just so I > > can > >> transport IPv4 "Router ID's" around my network? Or, > > > > No. > > > > Router-ID is no longer a routable entity in IPv6 networks. Please refer > > to BGP (RFC6286) & OSPF (RFC5340). > > In fact, OSPF (RFC5340) explicitly prohibits Router ID to be any IPv6 > > address. > > > > BGP RFC6286 > > // > > The BGP Identifier is a 4-octet, unsigned, non-zero integer that > > should be unique within an AS. The value of the BGP Identifier > > // > > > > > > OSPF RFC5340 > > // > > o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the > > IPv4 size of 32 bits. They can no longer be assigned as (IPv6) > > addresses. > > // >=20 > Yes, I heard you before. Thanks, got that. >=20 > So, please tell me how I'm supposed to ping/traceroute to this 32-bit "Router > ID" in this new IPv6-only world, just like I do today in IPv4 today, to verify > reachability? Usually, this is one of the first steps in troubleshooting a > problem. I'm curious if we've gotten lazy by assuming dual-stack v4 + v6 will > "always be there", so I can just use v4 to ping/traceroute to a 32-bit Router ID > ... but, what happens when v4 is no longer there any more? >=20 >=20 > >> b) Will we have to settle for IPv4-mapped IPv6 addresses, just for the > >> purpose of carrying around an IPv4 Router ID in an IPv6 IGP for the > >> operational reasons I outlined in my previous e-mail? > > > > No. > > > > It wouldn't make any sense, nor would it help. > > v4-mapped v6 address is still a v6 address, after all and it wouldn't do > > any good for 32-bit router-id. >=20 > FWIW, I was suggesting another imperfect "hack" wrt (b). Specifically, a > protocol could use/exchange/etc. a 32-bit ROUTER_ID on-the-wire; > however, "out-of-band" I assign a IPv4-mapped IPv6 address to a Loopback > interface on a router and inject it into my "IPv6-only" IGP in order to > preserve my ability to see it in the topology (in the routing table), and > simultaneously am able to ping/traceroute to it to ensure that the Loopback > interface is "alive". But, this is a kludge, because now I have to keep the > ROUTER_ID in sync with the configuration of IPv4-mapped IPv6 address on a > Loopback interface ... >=20 > -shane From rajiva@cisco.com Mon Mar 12 07:03:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3480A21E8028 for ; Mon, 12 Mar 2012 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.781 X-Spam-Level: X-Spam-Status: No, score=-9.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzHukwpEMF4m for ; Mon, 12 Mar 2012 07:03:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 619D921E8011 for ; Mon, 12 Mar 2012 07:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2267; q=dns/txt; s=iport; t=1331561016; x=1332770616; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iw57FypMa1Y7XgRvlqOXvB63EhyoXWCdyIbq7ZNyW3A=; b=NdlR/b6EMqWlgqJc+/W/OOr4xvVncr6x/zPv28ONmkQ6GadHeRejWo0D avX/Lb1X3XiH6jEPGyYjyOD1hLrDGQRule8OmfrgZ9mW7ERX4QimgfjIa Y6DJfrMOcmMLJQ8jYhgvmbSEp9ePDbNAtHev3fRzV0u/d5tZsdOVgPvrS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABYBXk+tJXG9/2dsb2JhbABDtUyBB4IJAQEBBAEBAQ8BHQo0BgUMAgICAQgRBAEBAQoGFwEGARoMHwkIAQEEARIIGodoC50MAZ5VBASQGmMEiFSdG4MBgT4 X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65674969" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 14:03:36 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CE3aCD023230; Mon, 12 Mar 2012 14:03:36 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:03:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:03:35 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA08B@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Reminder regarding IPR on draft-ietf-mpls-ldp-gtsm Thread-Index: Acz+ACrJECYZPadZR3inYYjXQsPbgwBL2eqg References: <4F59CD0F.6060801@pi.nu> From: "Rajiv Asati (rajiva)" To: "Carlos Pignataro (cpignata)" , "Loa Andersson" X-OriginalArrivalTime: 12 Mar 2012 14:03:36.0049 (UTC) FILETIME=[EAD3E610:01CD0058] Cc: mpls@ietf.org, draft-ietf-mpls-ldp-gtsm@tools.ietf.org Subject: Re: [mpls] Reminder regarding IPR on draft-ietf-mpls-ldp-gtsm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:03:37 -0000 I am also not aware of any IPR (including patent rights) applicable to this document. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Carlos Pignataro (cpignata) > Sent: Friday, March 09, 2012 9:23 AM > To: Loa Andersson > Cc: mpls@ietf.org; draft-ietf-mpls-ldp-gtsm@tools.ietf.org > Subject: Re: [mpls] Reminder regarding IPR on draft-ietf-mpls-ldp-gtsm >=20 > Chairs, WG, >=20 > I am not aware of any IPR (including patent rights) applicable to this > document. >=20 > Thanks, >=20 > -- Carlos. >=20 > On Mar 9, 2012, at 4:27 AM, Loa Andersson wrote: >=20 > > > > Working Group, > > > > > > The authors have asked for draft-ietf-mpls-ldp-gtsm to be sent to > > WG last call. Before doing this, we would like to check whether > > there is IPR on the document that needs to be disclosed. > > > > Are you aware of any IPR that applies todraft-ietf-mpls-ldp-gtsm? > > If so, has this IPR been disclosed in compliance with IETF IPR > > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond to this > email regardless of whether or not you are aware of any relevant IPR. This > document will not advance to the next stage until a response has been > received from each author and contributor. > > > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any IPR > that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, Loa > > > > (as MPLS WG co-chair) > > > > > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 07:03:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7A721F8638 for ; Mon, 12 Mar 2012 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbgujJP1SEEL for ; Mon, 12 Mar 2012 07:03:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 700BE21F85F6 for ; Mon, 12 Mar 2012 07:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2701; q=dns/txt; s=iport; t=1331561018; x=1332770618; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hgpch7YUHIIOGipxxlJzBpaGyMRKW9Vr0tLoS6eRtnc=; b=SI5NCREgZNshUSY7AiB5xwzHq/aZBPt5/ZDEJBPYMg1hacIthZtTXpuY 5y6gyygh6QmZB/oAPbJZXkQoANTTtapj0nPt+lvhwGmeSdgdNNuwC/sZ1 vNFucYKrpRAQgnCgZjabtqG/jRe1WDKw3UqDSUMs7IYsteVcJXq19Htco c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALUBXk+tJV2a/2dsb2JhbABDtUyBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgah2MFnRoBnlmQHmMEiFSdG4MB X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65674749" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2012 14:03:38 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CE3cjG004099; Mon, 12 Mar 2012 14:03:38 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:03:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:03:37 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA08E@XMB-RCD-111.cisco.com> In-Reply-To: <201203021510.55974.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Q6acydgBrs74Rcum97o5LelFrgHW57TA References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <201203021510.55974.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: , "Henderickx, Wim (Wim)" X-OriginalArrivalTime: 12 Mar 2012 14:03:37.0791 (UTC) FILETIME=[EBDDB4F0:01CD0058] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:03:42 -0000 Mark, > But we also need to be concerned about consistency across > various protocols that operators are turning on. If 60% of > all the key protocols are relying on the presence of a 32- > bit integer, even in an IPv6-only network, and then LDP (or > some other protocol) has a different take on the matter, > does that make things easier or harder for operators? Thanks for putting it in a better perspective. When we eventually move to IPv6 only paradigm, then the inconsistency would continue to be an operational burden forever. =20 =09 > Personally, I'd have preferred Router-ID's for IPv4 and IPv6 > to be different per AF even for MP-BGP, OSPFv3 and others. Certainly. But as we know that the per-AF router-id turned out to be a minority viewpoint, as 32-bit integer for the router ID was chosen for those IPv6 protocols. Cheers, Rajiv > -----Original Message----- > From: Mark Tinka [mailto:mtinka@globaltransit.net] > Sent: Friday, March 02, 2012 2:11 AM > To: Henderickx, Wim (Wim) > Cc: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Friday, March 02, 2012 02:42:03 PM Henderickx, Wim (Wim) > wrote: >=20 > > Rajiv, I believe we need to provide both options to > > ensure both are possible. If we do not introduce the > > IPv6 LSR ID now I will be very hard to ad it in the > > future. >=20 > I do see where Shane and Wim are coming from, as I did find > it rather ambiguous that an IPv6-only router would need to > specify a 32-bit integer as the Router-ID for some IPv6- > based routing protocols to work. >=20 > But we also need to be concerned about consistency across > various protocols that operators are turning on. If 60% of > all the key protocols are relying on the presence of a 32- > bit integer, even in an IPv6-only network, and then LDP (or > some other protocol) has a different take on the matter, > does that make things easier or harder for operators? >=20 > Personally, I'd have preferred Router-ID's for IPv4 and IPv6 > to be different per AF even for MP-BGP, OSPFv3 and others. > But I realize this isn't the right thread for that, which is > why I'm open to having both options in LDP. >=20 > The BGP and OSPF specs. are clear on this issue, but I > certainly wouldn't mind them revisiting it in the future. If > making LDP "dual-stack" in the Router-ID perspective is what > may give the other working groups a kick-in-the-behind to > consider the operational value (and challenges) of doing > this in 2012 and beyond, I certainly won't stand in their > way. >=20 > Mark. From rajiva@cisco.com Mon Mar 12 07:05:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A06B21E8024 for ; Mon, 12 Mar 2012 07:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.819 X-Spam-Level: X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2LQpmk6PfVm for ; Mon, 12 Mar 2012 07:05:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CDC4021E802B for ; Mon, 12 Mar 2012 07:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=7482; q=dns/txt; s=iport; t=1331561133; x=1332770733; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=r7rfYEN0MzgrM9CD/vPwZJJ/6M2SlDKWNY5KLN3769o=; b=lgSE5nB35DHNQqsYEu8Ve2IZ9aTlmjUHhrnqcOSLQCY7IBPOXSSbzdQp FrmbpVE2RzsteZxZi0cHHHisS5LqmsYnHbhkcNCFB5naG5Ok9aF8QmMvQ COmwubhG3ADckYwqOFGjYGElskYM0S41IdL8hqBhWKppt/1KfEnLfP9Wa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGgCXk+tJXHB/2dsb2JhbABDtUyBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASAGHwkIAgQBEggah2MFC50WAZ5ZiUSGWmMEiFSYI4R4gwGBPg X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65673987" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 12 Mar 2012 14:05:33 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2CE5X60015910; Mon, 12 Mar 2012 14:05:33 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:05:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:05:32 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkA== References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Henderickx, Wim (Wim)" , X-OriginalArrivalTime: 12 Mar 2012 14:05:33.0177 (UTC) FILETIME=[30A43690:01CD0059] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:05:35 -0000 Pranjal, Mustapha, Wim, > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has to > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > LDP has to auto-create targeted sessions. We can't force to set-up another > ip4 network just for some applications. It won't be possible to map 4 byte ldp I hope that we are not misunderstanding 32-bit integer value in RouterID in an IPv6-only router to mean having IPv4 network.=20 Also, such applications must use 'transport IP address', not the Router-ID when it comes to setting up the session. If they don't, then they are incorrect and must be fixed. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Friday, March 02, 2012 12:02 PM > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, > We shouldn't be ruling out the fact that there are some differences in > applications of LDP compared to OSPF or BGP. If we have IPV6 only transport > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has to > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > LDP has to auto-create targeted sessions. We can't force to set-up another > ip4 network just for some applications. It won't be possible to map 4 byte ldp > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID is must > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility and better > to add it now. >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Friday, March 02, 2012 12:41 AM > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, >=20 > I understand we didn't add a IPv6 router ID option in BGP/OSPF but we > should look at the future to get to IPv6 only networks and as such it will be > required. So we are now at a point where we should add this option in all > protocols. Since LDP for Ipv6 is open we need to add it now. >=20 > My 2 cents >=20 > Cheers, > Wim >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: vrijdag 2 maart 2012 8:08 > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Wim, >=20 > That's a reasonable point, but no such proposal has been made for other > protocols. In fact, IPv6 deployments have already accommodated 4-octet > router-id for routing protocols (which was also a departure from the > common practice in IPv4 realm). As Mark T and I discussed in the > previous email, the router-id consistency across protocols would be an > operational benefit. >=20 > Focusing on the technicalities, Router ID is meant to ensure the > uniqueness of the router within the network while following the > protocol, so are we thinking that 4-octet is not good enough to ensure > the uniqueness? If so, then it would be worth having that discussion in > the Routing and Internet areas that have been focusing on IPv6 at large. >=20 >=20 > While I do agree to 128-bit future expandability as a benefit, the > benefit would be trivial (at the expense of message structure changes) > if we expanded it for the sake of it, but didn't address the root of the > problem. >=20 > Do you think otherwise? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > > Sent: Friday, March 02, 2012 1:42 AM > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, I believe we need to provide both options to ensure both are > possible. > > If we do not introduce the IPv6 LSR ID now I will be very hard to ad > it in the > > future. > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: vrijdag 2 maart 2012 7:39 > > To: mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mark, > > > > Well said. > > > > I take that we are in agreement wrt 4-octet entity for LDP router-id > in > > the context of IPv6, as specified. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > Sent: Friday, March 02, 2012 1:31 AM > > > To: Rajiv Asati (rajiva) > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > lizhong.jin@zte.com.cn; > > > vishwas.ietf@gmail.com > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > wrote: > > > > > > > In the past, implementations provided the router-id CLI > > > > for any interface IPv4 address to be chosen as router-id > > > > for various protocols including LDP. > > > > > > > However, many implementations already evolved the CLI to > > > > not even give an "interface" IP address for router-id, > > > > to accommodate IPv6. Almost all deployed networks > > > > already accommodated that. > > > > > > We do operate some implementations today that "still" allow > > > you to specify the Router-ID for various protocols as an > > > independent 32-bit integer (only), and also allow you to > > > define the LSR-ID for LDP as an interface (only). This is > > > current, shipping 2012 code. > > > > > > So both scenarios you mention above are still much in play > > > today. Whether operators are using them or not (I know we > > > are) is another matter entirely. > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > implementations could evolve LDP router-id as well to > > > > accommodate IPv6. This would make LDP router-id to be > > > > consistent with other protocols delving with IPv6. And > > > > this can certainly be operationally beneficial from IPv6 > > > > POV. > > > > > > Agree. > > > > > > > In fact, one of the implementations allow the router-id > > > > to be configured just once and let all protocols just > > > > use it, if they wanted. > > > > > > Yes, we operate some implementations that use this method > > > too. It's quite elegant, in that you configure once and > > > forget. Other implementations that are more structured means > > > operators could easily forget to specify the Router-ID for a > > > particular protocol, for better or worse. > > > > > > Cheers, > > > > > > Mark. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 07:12:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BB521F85AF for ; Mon, 12 Mar 2012 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.236 X-Spam-Level: X-Spam-Status: No, score=-9.236 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t2aQoYf8DGN for ; Mon, 12 Mar 2012 07:12:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 626E021F855F for ; Mon, 12 Mar 2012 07:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3879; q=dns/txt; s=iport; t=1331561571; x=1332771171; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gAW5sT5s58qST8djjkD55GkXnMwKgShOvKLbQXfVc+A=; b=djvwURjB8fpegGwEUTmwfVx/V3Izuf8re4zZc59gz9C0g1AY1nV3bUVU seHiphMxJHHpZWyVnIAl01atGKvYanb/XPHqGKrOC29Vtaw4hbn092Cfb OTfUk5ilhbSrwFP4FEIwp+KNBGbpuVEHelGnpIyBx+QazhLHDn4iYPmgX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAUEXk+tJV2a/2dsb2JhbABBtVmBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIGodjBaAKAZZ2iUSGWmMEiFSYI4R4gwE X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65668510" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 12 Mar 2012 14:12:51 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CECoX9012241; Mon, 12 Mar 2012 14:12:50 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:12:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:12:49 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA09C@XMB-RCD-111.cisco.com> In-Reply-To: <00f701ccf932$ab605540$4001a8c0@gateway.2wire.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz5Oy76DWqOK+WrR0Kksaj6FZHk+QHHnSKA References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE5C3@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116F3@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <00f701ccf932$ab605540$4001a8c0@gateway.2wire.net> From: "Rajiv Asati (rajiva)" To: "t.petch" , "Aissaoui, Mustapha (Mustapha)" , , X-OriginalArrivalTime: 12 Mar 2012 14:12:50.0811 (UTC) FILETIME=[357DDCB0:01CD005A] Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:12:52 -0000 Tom, > So please, do not repeat the mistake of the IETF all those years ago, which so > haunts us so today. BGP and OSPF have seen the light, with identifiers for > IPv6, and I respect their wisdom. This is certainly the path we must take at minimum with ldp-ipv6 draft. > So using a routable address as a router identifier was always short sighted > and dumb. =20 Well, that was the easiest way out in the IPv4 paradigm. The specification didn't intend to suggest so. Part of blame goes to us/vendors too.. Cheers, Rajiv > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Saturday, March 03, 2012 6:42 AM > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva); > lizhong.jin@zte.com.cn; vishwas.ietf@gmail.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > ----- Original Message ----- > From: "Aissaoui, Mustapha (Mustapha)" lucent.com> > To: "Rajiv Asati (rajiva)" ; ; > > Cc: > Sent: Friday, March 02, 2012 3:42 PM > > Rajiv, > > From a pure prootocol perspective, you are correct. > > > > This is however a practical matter. Many deployments today have the > router-id > default to a well known system loopback interface IPv4 address. This means > that > routing protocols, MPLS signaling protocols,and OAM protocols can operate > directly using this address. >=20 > > Stepping back, a, if not the, major problem of the Internet, is getting people > off the somewhat overloaded IPv4. And one of the reasons it is so difficult is > because that 32 bit dotted decimal has been used for system identifier, > system > address, system locator etc etc - it is called overloading and is a surefire way > of making migration expensive, bordering on the impossible (see the RRG > archives > for this lengthy discussion:-(. >=20 > So using a routable address as a router identifier was always short sighted > and > dumb. Using a separate namespace and a mapping system (ever heard of > DNS or > /etc/hosts/?) is so obviously the right way to go that ... well if you don't > get the message ... >=20 > The ancilliary point is that dotted decimal makes a 32 bit number almost user > friendly. Anyone who thinks that a generic 128 bit number is, well ..... see > above. >=20 > I realise that if you have complete control over your address structure you > can > choose a structure that reduces the number of characters to be comparable > to > dotted decimal, in general you cannot, and even when you can, you have to > get > those pesky double colons right - and as has been pointed already, every one > of > those colons is shift on most keyboards, while those dots are not shift on > most keyboards. >=20 > So please, do not repeat the mistake of the IETF all those years ago, which so > haunts us so today. BGP and OSPF have seen the light, with identifiers for > IPv6, and I respect their wisdom. >=20 > Tom Petch > >=20 >=20 > Certainly with BGP, the operator can configure a neighbour address which is > IPv6 > and is different from the router-id but that router-id is already required for > the operation of IPv4 BGP neighbours and other protocols and such this is > manageable. As we go into all IPv6 deployments, we need to have means for > deployments to have a similar default IPv6 system address. It is hardly > justifiable at that point in time to configure two different addresses to get > the prorotcols working by default. We may as well make this change now as > part > of allowing separate LDP sessions for IPv4 and IPv6 or we will create yet a > third LDP version number in the next few years. > > > > Regards, > > Mustapha. > > From rajiva@cisco.com Mon Mar 12 07:24:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9BB21F875B for ; Mon, 12 Mar 2012 07:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.84 X-Spam-Level: X-Spam-Status: No, score=-9.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7GJCJWUIZbP for ; Mon, 12 Mar 2012 07:24:17 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4921F87CD for ; Mon, 12 Mar 2012 07:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5889; q=dns/txt; s=iport; t=1331562257; x=1332771857; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BCCvbTqJo7Ws7DB0cICZbgBbDv5mOx5cpsqdvPaK1do=; b=ZqN52WYJ7m/FojPxHVGQUeOEHh4yLOxPd7V0fYYcEpIoMrwk9bvmKzWJ Wz679e++Z/mFmP9rn0NPUt5q3Y8grmoQCkz61hggbIbm0VV2Brt+umJnm Z8T8yzKmeZlnx/PV6HxI4CCveC0LIbL+odT73Lq1PC8MV/hA9RDbarSFn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO4FXk+tJV2b/2dsb2JhbABDtUyBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodoC50PAZ5YBJAeYwSIVJ0bgwE X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65681408" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 14:24:16 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEOGOw008086; Mon, 12 Mar 2012 14:24:16 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:24:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:24:14 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOA= References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" X-OriginalArrivalTime: 12 Mar 2012 14:24:16.0492 (UTC) FILETIME=[CE307AC0:01CD005B] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:24:18 -0000 Shane, Pranjal, Let's make sure that we don't have any disconnect here at least on the technicalities here (ignoring the draft discussion for a minute) Shane's Q is whether either v4 or v6 hello could help to establish v4 and/or v6 LDP session.=20 While Pranjal's assertion is correct on its own, it doesn't quite answer the subtlety in Shane's Q. Shane's Q: > With respect to LDP Hellos, you're suggesting that operators run either IPv4- > only Hello's or IPv6-only Hello's, (never both at the same time), but through > either one can discover the "(IPv4|IPv6) transport capabilities" of a LDP peer > and, based on that, establish an IPv4 and/or IPv6 LDP session. Correct? Not really. Using v4 hello MUST not lead to using v6 transport and v6 LDP session. That would be a fundamentally wrong approach. As Pranjal said, v4 hello usage must lead to v4 session establishment, whereas v6 hello usage must lead to v6 session establishment. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Tuesday, March 06, 2012 1:28 PM > To: Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Shane, > Yes, that's correct. We can run either ipv4 hellos or ipv6 hellos and > operator can choose whichever is best, based upon the operational needs. > Since the src ip addresses used by hello packets are not coupled with FEC > types so single hello can advertise various FEC capabilities. >=20 > If we run multiple ldp sessions between peering systems for fate > separation of ipv4 and ipv6 then there can be two separate hello adjacencies > over a single interface (each one associated with separate sessions) but in > that case the LSR-IDS used would be different (we need to work for an > extension of RFC 5036). >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Monday, March 05, 2012 10:13 PM > To: Dutta, Pranjal K (Pranjal) > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Pranjal, >=20 > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > Hi Shane, > > Yes, two separate LDP sessions are required for fate separation of ipv4 > and ipv6 fecs. > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > satisfy > > a) and b). Both can be achieved with single hello adjacency per > > interface per peering lsr-id with adjacency specific capabilities. >=20 > I'm in agreement with you with respect to LDP sessions. >=20 > With respect to LDP Hellos, you're suggesting that operators run either IPv4- > only Hello's or IPv6-only Hello's, (never both at the same time), but through > either one can discover the "(IPv4|IPv6) transport capabilities" of a LDP peer > and, based on that, establish an IPv4 and/or IPv6 LDP session. Correct? >=20 > -shane >=20 >=20 >=20 > > Thanks, > > Pranjal > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Shane Amante > > Sent: Friday, March 02, 2012 11:34 PM > > To: mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mark, > > > > I completely agree with all of your comments below. I too would (strongly) > prefer the option to allow operators to choose (via CLI) whether to: > > a) use separate transport to ensure there is no fate-sharing of IPv4 + > > IPv6; or, > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, other > AF's) on a single session, for scale reasons. > > > > -shane > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > >> (Pranjal) wrote: > >> > >>>> From an implementer/system designer's point of view I would think > >>>> single hello adjacency with per adjacency capabilities would be > >>>> right approach. > >> > >> Pranjal, I appreciate that from a vendor perspective, implementing it > >> this way would make sense for large scale deployments. > >> > >> However, for some operators who may be using BGP or RSVP to signal or > >> nest a large number of LSP's, we would like to have the option of > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for LDP. > >> > >> If there are operators who aren't going to be looking at scaling that > >> many LSP's anytime in their network, they might still prefer to > >> eliminate adjacency fate-sharing. > >> > >> I would propose that vendors implement both options, allowing > >> operators to choose (via CLI) which method they would like to deploy > >> in the field. There are many operators out there who maintain > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's to > >> protect themselves against the problems fate-sharing could bring. > >> This is why some of us prefer to make our lives harder by going > >> native, dual-stack rather than 6PE :-). > >> > >> So while I won't disagree with your opinion on using a single > >> adjacency for both AF's for scaling purposes, I would certainly like > >> to have the option to choose which method suits me best in the wild. > >> > >> Mark. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 07:31:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086321F8769 for ; Mon, 12 Mar 2012 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.556 X-Spam-Level: X-Spam-Status: No, score=-9.556 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+55X35fgYIV for ; Mon, 12 Mar 2012 07:31:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE421F875D for ; Mon, 12 Mar 2012 07:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=11865; q=dns/txt; s=iport; t=1331562682; x=1332772282; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2R/9hnd7iX9q3+EwXXtBuCTSB7YzCalDHWZFbcMfaIg=; b=R9s8lQq+NPaF6nWyyss8S15J6cud7UZwmJnmJYIQPcT/G3AwRo435NYc 5lZnDRaiAPRUHiZaUEZH4z2j+U9k6VOcuBhUQ3upeI2n/ZwPLeiD+iPKv cXgAmXXGlEonEFuyElml7CAoxcmYIhCQogXDeg9jsgsw1ixbcKbBheAOi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFAIXk+tJV2d/2dsb2JhbAA5CrVMgQeCCQEBAQQSAR0KPwwEAgEIEQMBAQEBCgYXAQYBICUJCAEBBAESCBMHh2idGgGeXYlEaAUEhWljBIhUmCOEeIMBgTcH X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65671253" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2012 14:31:21 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEVLW8022054; Mon, 12 Mar 2012 14:31:21 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:31:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:31:20 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0C4@XMB-RCD-111.cisco.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAB7Jzx0A== References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" , "Dutta, Pranjal K (Pranjal)" , "VishwasManral" X-OriginalArrivalTime: 12 Mar 2012 14:31:21.0530 (UTC) FILETIME=[CB8821A0:01CD005C] Cc: mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:31:27 -0000 Mustapha, That's not the correct interpretation of section 6.1.=20 If the session already exists (e.g. TCP socket is in place) for a peer, then any request for a new session using a different transport or not would be ignored. Please allow me to paste the relevant excerpt from the ldp-ipv6-06 : // 6. An LSR SHOULD NOT create (or honor the request for creating) a TCP connection for a new LDP session with a remote LSR, if they already have an LDP session (for the same LDP Identifier) established over whatever IP version transport. // Please let us know if this can be phrased better. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Friday, March 02, 2012 2:26 PM > To: Dutta, Pranjal K (Pranjal); VishwasManral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > I also have an issue with the stability of such an implementation. The draft > suggests in Section 6.1 - Transport connection establishment, that a TCP > connection with IPv6 should be preferred to one with IPv4 if both IPv4 and > IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is > established, we tear down the IPv4 TCP connection and signal the IPv6 one. > This of course is not acceptable. In RFC 5036 compliant implementations, > when a new adjacency comes up to the same LSR-ID, we just associate it > with the existing TCP connection which was bootstrapped by the first Hello > adjacency. >=20 > Mustapha. >=20 > ________________________________ >=20 > From: Dutta, Pranjal K (Pranjal) > Sent: Friday, March 02, 2012 1:22 PM > To: Vishwas Manral > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Hi Viswas, >=20 > We raised one more point earlier on the following clause in the > draft. >=20 >=20 >=20 > Section 6.2 >=20 >=20 >=20 > As outlined in section 2.5.5 of RFC5036, this draft describes that > if an LSR has a dual-stack interface, which is enabled with both > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and > IPv6 LDP Link Hellos and must separately maintain the Hello > adjacency for IPv4 and IPv6 on that interface. >=20 > This ensures successful labeled IPv4 and labeled IPv6 traffic > forwarding on a dual-stacked interface, as well as successful LDP > peering using the appropriate transport on a multi-access > interface (even if there are IPv4-only, IPv6-only and dual-stack > LSRs connected to that multi-access interface). >=20 >=20 > The draft mandates that two separate hello adjacencies should be > maintained on dual-stack - one for IPV4 and another for IPV6. We don't see > any benefit or technical reason of running two separate adjacencies. >=20 > 1. First of all, doing so does not provide fate separation any way. Both IPV4 > and IPV6 fecs are still exchanged over same LDP sessions. >=20 > 2. This clause mandates that a transit network that is carrying IPV6 LSPs > must provision IPv6 interfaces. It is not mandatory that the transport > network itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a > very narrow interpretation of section 2.5.5 in RFC 5036. It's not necessary > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. The > hello adjacency can still be over an IPV4 link and IPV6 prefix can still be > resolved by an IPV4 route next-hop. It's not necessary that source of hellos > be IPv6 or transport address of TCP session be ipv6. >=20 > 3. This clause has unnecessary scalability implications. We do run very large > number of LDP adjacencies/sessions (e.g 10K) in mobility backhauls or similar > deployments. This clause requires to run 20K hello adjacencies which has > scalability implications. On theory there may not much difference between > 10K and 20K but in real implementations there is. If we allow separation of > sessions for fate separation of IPV4 and IPV6 then it would become 40K > adjacencies. >=20 > We can limit to only one hello adjacency per interface yet address the dual > stack issue. A graceful solution is to come up with a notion of LDP adjacency > specific capabilities (similar to LDP capabilities that applies to entire sessions) > that would benefit multiple purposes. For example, we have multiple ECMP > Links between neighboring LSRs A and B as shows below. >=20 > +----------------L1------------------+ > | | > A ----------------L2----------------- B > | | > +----------------L3------------------+ >=20 > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using either > IPV4 OR ipv6 addresses but not both. >=20 > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > and L3 are IPv6 capable. >=20 > Then hellos exchanged over link would advertise capabilities as below: >=20 > L1 would carry capabilities - Ipv4 + Mcast > L2 would carry capabilities - ipv4 + ipv6 + Mcast > L3 would carry capabilities - ipv4 + ipv6 >=20 >=20 > From an implementer/system designer's point of view I would think single > hello adjacency with per adjacency capabilities would be right approach. >=20 > Thanks, > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, February 29, 2012 5:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: >=20 > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address. >=20 > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system. >=20 >=20 >=20 > Thanks, >=20 > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >=20 >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out > in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 From rajiva@cisco.com Mon Mar 12 07:33:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E1421F8819 for ; Mon, 12 Mar 2012 07:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.565 X-Spam-Level: X-Spam-Status: No, score=-9.565 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eylnzGgJbRfg for ; Mon, 12 Mar 2012 07:33:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 53A6821F8810 for ; Mon, 12 Mar 2012 07:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=12095; q=dns/txt; s=iport; t=1331562806; x=1332772406; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ocQqsGar1UHuNAPsmlvWadvxCMMZm2Jz1RVVcHDDrQI=; b=ch64g37lkeR6pnXAsOZL+1btDomOsYljDe9FyxzBJSAXCH7J+JyEBX46 ukBLCUcp6l5cgYNYNE+/+3CBzOhSWsU+TaroTbmLksrMxkP2hFKDiCrA8 /pYNaMHzDq4aSfukxyfQ1xJJfv6iznBqr8phITvy4U4joHu0anXS3fpuw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMIIXk+tJXG//2dsb2JhbAA3CrVZgQeCCQEBAQMBEgEdCj8MBAIBCBEDAQEBAQoGFwEGASAlCQgBAQQBEggTB4djBaAOAZZ3iURoBQSFaWMEiFSYI4R4gwGBNwc X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65674832" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Mar 2012 14:33:25 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEXPR8026337; Mon, 12 Mar 2012 14:33:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:33:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:33:23 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZA References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Aissaoui, Mustapha (Mustapha)" , "Vishwas Manral" X-OriginalArrivalTime: 12 Mar 2012 14:33:25.0456 (UTC) FILETIME=[1565BD00:01CD005D] Cc: mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:33:28 -0000 Pranjal, Certainly. That would be a sub-optimal protocol design, let alone the subsequent implementations. Thankfully, that's not what is prescribed. May I request you to review the verbiage a bit carefully? Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Friday, March 02, 2012 2:37 PM > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Yes, this approach would lead to all "kludgy" implementations. Due to race > conditions between UDP based LDP hellos and TCP connections (since they > are independent channels) it may lead to states of continually flapping > sessions. >=20 >=20 >=20 > Thanks, >=20 > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Aissaoui, Mustapha (Mustapha) > Sent: Friday, March 02, 2012 11:26 AM > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > Cc: Lizhong Jin; mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > I also have an issue with the stability of such an implementation. The draft > suggests in Section 6.1 - Transport connection establishment, that a TCP > connection with IPv6 should be preferred to one with IPv4 if both IPv4 and > IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is > established, we tear down the IPv4 TCP connection and signal the IPv6 one. > This of course is not acceptable. In RFC 5036 compliant implementations, > when a new adjacency comes up to the same LSR-ID, we just associate it > with the existing TCP connection which was bootstrapped by the first Hello > adjacency. >=20 >=20 >=20 > Mustapha. >=20 >=20 >=20 > ________________________________ >=20 > From: Dutta, Pranjal K (Pranjal) > Sent: Friday, March 02, 2012 1:22 PM > To: Vishwas Manral > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Viswas, >=20 > We raised one more point earlier on the following clause in the > draft. >=20 >=20 >=20 > Section 6.2 >=20 >=20 >=20 > As outlined in section 2.5.5 of RFC5036, this draft describes that > if an LSR has a dual-stack interface, which is enabled with both > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and > IPv6 LDP Link Hellos and must separately maintain the Hello > adjacency for IPv4 and IPv6 on that interface. >=20 > This ensures successful labeled IPv4 and labeled IPv6 traffic > forwarding on a dual-stacked interface, as well as successful LDP > peering using the appropriate transport on a multi-access > interface (even if there are IPv4-only, IPv6-only and dual-stack > LSRs connected to that multi-access interface). >=20 >=20 > The draft mandates that two separate hello adjacencies should be > maintained on dual-stack - one for IPV4 and another for IPV6. We don't see > any benefit or technical reason of running two separate adjacencies. >=20 > 1. First of all, doing so does not provide fate separation any way. > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. >=20 > 2. This clause mandates that a transit network that is carrying IPV6 > LSPs must provision IPv6 interfaces. It is not mandatory that the transport > network itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a > very narrow interpretation of section 2.5.5 in RFC 5036. It's not necessary > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. The > hello adjacency can still be over an IPV4 link and IPV6 prefix can still be > resolved by an IPV4 route next-hop. It's not necessary that source of hellos > be IPv6 or transport address of TCP session be ipv6. >=20 > 3. This clause has unnecessary scalability implications. We do run > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > backhauls or similar deployments. This clause requires to run 20K hello > adjacencies which has scalability implications. On theory there may not much > difference between 10K and 20K but in real implementations there is. If we > allow separation of sessions for fate separation of IPV4 and IPV6 then it > would become 40K adjacencies. >=20 > We can limit to only one hello adjacency per interface yet address the dual > stack issue. A graceful solution is to come up with a notion of LDP adjacency > specific capabilities (similar to LDP capabilities that applies to entire sessions) > that would benefit multiple purposes. For example, we have multiple ECMP > Links between neighboring LSRs A and B as shows below. >=20 > +----------------L1------------------+ > | | > A ----------------L2----------------- B > | | > +----------------L3------------------+ >=20 > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using either > IPV4 OR ipv6 addresses but not both. >=20 > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > and L3 are IPv6 capable. >=20 > Then hellos exchanged over link would advertise capabilities as below: >=20 > L1 would carry capabilities - Ipv4 + Mcast > L2 would carry capabilities - ipv4 + ipv6 + Mcast > L3 would carry capabilities - ipv4 + ipv6 >=20 >=20 > From an implementer/system designer's point of view I would think single > hello adjacency with per adjacency capabilities would be right approach. >=20 > Thanks, > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, February 29, 2012 5:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: >=20 > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address. >=20 > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system. >=20 >=20 >=20 > Thanks, >=20 > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >=20 >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out > in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 From rajiva@cisco.com Mon Mar 12 07:44:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D021E8025 for ; Mon, 12 Mar 2012 07:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.874 X-Spam-Level: X-Spam-Status: No, score=-9.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAqCU4JCWtyb for ; Mon, 12 Mar 2012 07:44:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 80FE921F8735 for ; Mon, 12 Mar 2012 07:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2950; q=dns/txt; s=iport; t=1331563441; x=1332773041; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=c8i772em2UmHun/II8w2kWrwu5+8/Sjr79qsORVlHm8=; b=gMvFyZognH4UfcTRPqMSzU2qpIQ+x/qFjC+5QZYRvzj+jCWWS2o95m93 oJuGrhcFCORJlGpQtnt0mVHtgQll6zDcWDMhVXFXdDBvs9P4OIQagidXL GaOLLdQjcby6SWih69ggJpGkQg2aNpluMm5AzC8DHxS8KrqOcbRmn5nZ5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKgKXk+tJXG9/2dsb2JhbABDtUyBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBRQkIAQEEARIIGodjBZ0RAZ5dkB5jBIhUnRuDAQ X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65675277" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2012 14:44:00 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEi0v7022488; Mon, 12 Mar 2012 14:44:00 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:43:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:43:58 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0DE@XMB-RCD-111.cisco.com> In-Reply-To: <201203071814.06540.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz8SxdIeI79dS42QvOi7T95h+ukiwEEkW7A References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203071814.06540.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 12 Mar 2012 14:43:59.0952 (UTC) FILETIME=[8F962500:01CD005E] Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:44:09 -0000 Mark, > I have to admit that I'm not necessariy a fan of making IPv6 > be the preferred transport mechanism in case the interface > is dual-stacked. We maintained the IPv6 as the preferred transport mechanism (during collision) after we polled the WG during IETF 80. Nonetheless, your preference is reasonable and that's why the draft has the following in section 6.1: // An implementation may provide an option to favor one AFI (IPv4, say) over another AFI (IPv6, say) for the TCP transport connection, so as to use the preferred IP version for the LDP session, and derive // > I would rather we revise this text so that IPv4 and IPv6 > adjacencies are started based on the presence of either AF > on an interface.=20 Of course, unless LDP for IPv4 or IPv6 is enabled on an interface, an LSR must not attempt to form LDP adjacency for that AFI.=20 Which section do you find the draft saying the opposite? Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Mark Tinka > Sent: Wednesday, March 07, 2012 5:14 AM > To: mpls@ietf.org > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Saturday, March 03, 2012 03:26:00 AM Aissaoui, Mustapha > (Mustapha) wrote: >=20 > > I also have an issue with the stability of such an > > implementation. The draft suggests in Section 6.1 - > > Transport connection establishment, that a TCP > > connection with IPv6 should be preferred to one with > > IPv4 if both IPv4 and IPv6 adjacencies exist. This means > > that if the IPv4 adjacency came up first and boot straps > > the IPv4 TCP connection, as soon as the IPv6 hello is > > established, we tear down the IPv4 TCP connection and > > signal the IPv6 one. This of course is not acceptable. > > In RFC 5036 compliant implementations, when a new > > adjacency comes up to the same LSR-ID, we just associate > > it with the existing TCP connection which was > > bootstrapped by the first Hello adjacency. >=20 > Mustapha, I was reviewing the I-D and also found this piece > of spec. >=20 > I have to admit that I'm not necessariy a fan of making IPv6 > be the preferred transport mechanism in case the interface > is dual-stacked. >=20 > As mentioned, if IPv4 bootstraps the adjacency and then the > addition of an IPv6 address changes this while in flight, > this is counter-intuitive from an operator perspective. >=20 > I would rather we revise this text so that IPv4 and IPv6 > adjacencies are started based on the presence of either AF > on an interface. Of course, if vendors want to provide > operators with knobs to change this behaviour so that it > conforms to the current spec. in the I-D, they may do so. > But IMHO, this will be giving operators more rope to hang > themselves with than they really need. >=20 > Mark. From rajiva@cisco.com Mon Mar 12 07:46:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42FF21F8804 for ; Mon, 12 Mar 2012 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWd2EUehxOsU for ; Mon, 12 Mar 2012 07:46:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B7C9721F87FA for ; Mon, 12 Mar 2012 07:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1374; q=dns/txt; s=iport; t=1331563594; x=1332773194; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=piL11V9Hs7FyKVgMUf7GTP+5PQYAUcCMLcg9kIorHnk=; b=fOf6BQRPhl1xtti7UCPVPJLklG1lrcqpM8tfmfD/qYdXI4q8uIiHiHch 42aO5QVshqzAfpNhs7TqESQHTedRzcr5qbgXmEeo0dwlFA/mC1hJdOLGf Lsd0ZVJ9S/jG2zQe/180fzJKSm014F7FU2L6PQiE1gYPxg3ScHbiQFeOD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFULXk+tJV2Y/2dsb2JhbABDtUyBB4IJAQEBBBIBHQo/DAQCAQgRBAEBAQoGFwEGAUUJCAEBBAESCBqHaJ0VAZ5dkB5jBIhUnRuDAQ X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65681785" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2012 14:46:34 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEkYx0011791; Mon, 12 Mar 2012 14:46:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:46:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:46:33 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0E3@XMB-RCD-111.cisco.com> In-Reply-To: <201203071816.54124.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz8S3LJqlBp36FdQKWDcZ4D0gzZ/wEEy/Ow References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203071816.54124.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 12 Mar 2012 14:46:34.0284 (UTC) FILETIME=[EB9356C0:01CD005E] Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:46:35 -0000 Mark, I think that Vishwas is referring to is this verbiage in section 6.1: // An implementation may provide an option to favor one AFI (IPv4, say) over another AFI (IPv6, say) for the TCP transport connection, so as to use the preferred IP version for the LDP session, and derive // Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Mark Tinka > Sent: Wednesday, March 07, 2012 5:17 AM > To: mpls@ietf.org > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Saturday, March 03, 2012 03:49:57 AM Vishwas Manral > wrote: >=20 > > This has been discussed a few times over already. >=20 > Sorry Vishwas, it would appear that I missed those earlier > discussions :-). >=20 > > If we use the option of not preferring an address family > > over the other (configurable of course), what can end up > > happening, is that we do not know what transport a > > session is running over. >=20 > So are you suggesting that if we don't prefer IPv6 over IPv4 > for adjacency creation (and we have separate adjacencies for > IPv4 and IPv6), we can't simply assume that the IPv4 > adjacency is maintaining the IPv4 session, or that the IPv6 > adjacency is maintaining the IPv6 session? >=20 > Mark. From internet-drafts@ietf.org Mon Mar 12 07:48:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823D21E8049; Mon, 12 Mar 2012 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGfk-DOMLQzs; Mon, 12 Mar 2012 07:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6314C21E8045; Mon, 12 Mar 2012 07:48:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312144816.20114.26063.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 07:48:16 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:48:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-01.txt Pages : 48 Date : 2012-03-12 This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mpls-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-seamless-mpls-01.txt From rajiva@cisco.com Mon Mar 12 07:51:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA18921F8857 for ; Mon, 12 Mar 2012 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.902 X-Spam-Level: X-Spam-Status: No, score=-9.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aj37z1f+G42 for ; Mon, 12 Mar 2012 07:51:43 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5895521F8850 for ; Mon, 12 Mar 2012 07:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1823; q=dns/txt; s=iport; t=1331563899; x=1332773499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HuuFo/xjI8BhrAyTaXj5kZKcz+iGOHs+32wMDD98ATc=; b=YLOMi/ODaMuKi62PIaEgAuq3eVK43EH2HN++gECn/PsHl+OP5CUla0WC WxiIp30GDq5nCW7AJodfQHCrr7J7VlCGAHRWbx1iUQFdsP8MpimsFCCsQ Q2VcQqTTVDrPyCRYBSYgUnOI942W3Yzp+x0qvwBQVi5zefXGvEVFY0Lde 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH4MXk+tJXHB/2dsb2JhbABDtUyBB4IJAQEBAwESAR0KLQsHBQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQTCBqHYwWdFwGeYZAeYwSIVJ0bgwE X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65683510" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2012 14:51:39 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2CEpcJY022022; Mon, 12 Mar 2012 14:51:38 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 09:51:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 09:51:37 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA0EE@XMB-RCD-111.cisco.com> In-Reply-To: <201203071826.55538.mtinka@globaltransit.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz8TOOxWLyDiIvqTHu6sUZrAmQSZAEEjazA References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <201203071826.55538.mtinka@globaltransit.net> From: "Rajiv Asati (rajiva)" To: , "Dutta, Pranjal K (Pranjal)" X-OriginalArrivalTime: 12 Mar 2012 14:51:38.0788 (UTC) FILETIME=[A112F640:01CD005F] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:51:44 -0000 Mark, > adjacency that carries both sessions, but experience > suggests operators will choose the latter instead, > instinctively. Interestingly, what we find is the dominance of single-session BGP for exchanging multiple AFI/SAFI information in deployments. In fact, many operators have justified moving (from OSPF) to ISIS to have a single process provide both v4 and v6. AFAIK, the multi-session BGP capability, which has existed for 7-8yrs, has seen minimal deployment.=20 Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Mark Tinka > Sent: Wednesday, March 07, 2012 5:27 AM > To: Dutta, Pranjal K (Pranjal) > Cc: Aissaoui, Mustapha (Mustapha); Lizhong Jin; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > On Wednesday, March 07, 2012 02:27:39 AM Dutta, Pranjal K > (Pranjal) wrote: >=20 > > If we run multiple ldp sessions between peering > > systems for fate separation of ipv4 and ipv6 then there > > can be two separate hello adjacencies over a single > > interface (each one associated with separate sessions) > > but in that case the LSR-IDS used would be different (we > > need to work for an extension of RFC 5036). >=20 > I would be in favour of the above. >=20 > Vendors could go ahead and implement support for a single > adjacency that carries both sessions, but experience > suggests operators will choose the latter instead, > instinctively. >=20 > LDP has also prided itself on being simple, so I'm not sure > whether providing all these options to operators via CLI > will be in keeping with that mantra (especially in relation > to the defaults various vendors may choose to run in multi- > vendor-operated networks). >=20 > Mark. From pranjal.dutta@alcatel-lucent.com Mon Mar 12 09:25:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AD21F85E3 for ; Mon, 12 Mar 2012 09:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.027 X-Spam-Level: X-Spam-Status: No, score=-7.027 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxG5S1dLO3kP for ; Mon, 12 Mar 2012 09:25:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7683A21F85DD for ; Mon, 12 Mar 2012 09:25:06 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2CGOwC8026174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 11:25:01 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CGOvoi001698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 21:54:58 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 12 Mar 2012 21:54:58 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Aissaoui, Mustapha (Mustapha)" , Vishwas Manral Date: Mon, 12 Mar 2012 21:54:54 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:25:08 -0000 Rajeev, We are not discussing about text rephrasing here and have been rais= ing technical issues. Could you please respond on my earlier mail on technical reasons on why it is MUST to have hello adjacency over=20 both IPV4 and IPV6 in order to be able to set-up IPV6 FECs?=20 Cheers, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: Monday, March 12, 2012 7:33 AM To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manr= al Cc: mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Certainly. That would be a sub-optimal protocol design, let alone the subsequent implementations. Thankfully, that's not what is prescribed. May I request you to review the verbiage a bit carefully? Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Friday, March 02, 2012 2:37 PM > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Yes, this approach would lead to all "kludgy" implementations. Due to race > conditions between UDP based LDP hellos and TCP connections (since they > are independent channels) it may lead to states of continually flapping > sessions. >=20 >=20 >=20 > Thanks, >=20 > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Aissaoui, Mustapha (Mustapha) > Sent: Friday, March 02, 2012 11:26 AM > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > Cc: Lizhong Jin; mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > I also have an issue with the stability of such an implementation. The draft > suggests in Section 6.1 - Transport connection establishment, that a TCP > connection with IPv6 should be preferred to one with IPv4 if both IPv4 and > IPv6 adjacencies exist. This means that if the IPv4 adjacency came up first > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is > established, we tear down the IPv4 TCP connection and signal the IPv6 one. > This of course is not acceptable. In RFC 5036 compliant implementations, > when a new adjacency comes up to the same LSR-ID, we just associate it > with the existing TCP connection which was bootstrapped by the first Hello > adjacency. >=20 >=20 >=20 > Mustapha. >=20 >=20 >=20 > ________________________________ >=20 > From: Dutta, Pranjal K (Pranjal) > Sent: Friday, March 02, 2012 1:22 PM > To: Vishwas Manral > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Viswas, >=20 > We raised one more point earlier on the following clause in the > draft. >=20 >=20 >=20 > Section 6.2 >=20 >=20 >=20 > As outlined in section 2.5.5 of RFC5036, this draft describes that > if an LSR has a dual-stack interface, which is enabled with both > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 and > IPv6 LDP Link Hellos and must separately maintain the Hello > adjacency for IPv4 and IPv6 on that interface. >=20 > This ensures successful labeled IPv4 and labeled IPv6 traffic > forwarding on a dual-stacked interface, as well as successful LDP > peering using the appropriate transport on a multi-access > interface (even if there are IPv4-only, IPv6-only and dual-stack > LSRs connected to that multi-access interface). >=20 >=20 > The draft mandates that two separate hello adjacencies should be > maintained on dual-stack - one for IPV4 and another for IPV6. We don't see > any benefit or technical reason of running two separate adjacencies. >=20 > 1. First of all, doing so does not provide fate separation any way. > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. >=20 > 2. This clause mandates that a transit network that is carrying IPV6 > LSPs must provision IPv6 interfaces. It is not mandatory that the transport > network itself be IPV6 in order to carry IPV6 traffic over its tunnels. This is a > very narrow interpretation of section 2.5.5 in RFC 5036. It's not necessary > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. The > hello adjacency can still be over an IPV4 link and IPV6 prefix can still be > resolved by an IPV4 route next-hop. It's not necessary that source of hellos > be IPv6 or transport address of TCP session be ipv6. >=20 > 3. This clause has unnecessary scalability implications. We do run > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > backhauls or similar deployments. This clause requires to run 20K hello > adjacencies which has scalability implications. On theory there may not much > difference between 10K and 20K but in real implementations there is. If we > allow separation of sessions for fate separation of IPV4 and IPV6 then it > would become 40K adjacencies. >=20 > We can limit to only one hello adjacency per interface yet address the dual > stack issue. A graceful solution is to come up with a notion of LDP adjacency > specific capabilities (similar to LDP capabilities that applies to entire sessions) > that would benefit multiple purposes. For example, we have multiple ECMP > Links between neighboring LSRs A and B as shows below. >=20 > +----------------L1------------------+ > | | > A ----------------L2----------------- B > | | > +----------------L3------------------+ >=20 > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using either > IPV4 OR ipv6 addresses but not both. >=20 > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > and L3 are IPv6 capable. >=20 > Then hellos exchanged over link would advertise capabilities as below: >=20 > L1 would carry capabilities - Ipv4 + Mcast > L2 would carry capabilities - ipv4 + ipv6 + Mcast > L3 would carry capabilities - ipv4 + ipv6 >=20 >=20 > From an implementer/system designer's point of view I would think single > hello adjacency with per adjacency capabilities would be right approach. >=20 > Thanks, > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Wednesday, February 29, 2012 5:11 PM > To: Dutta, Pranjal K (Pranjal) > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Hi Lizhong/ Pranjal/ Mustapha, >=20 > So the two main comments that have come after last call are: >=20 > 1. Allow for separation of sessions along with the adjacency. > 2. Allow for an IPv6 based LSR-ID. >=20 > The second could lead to changes required in both OSPF and IS-IS, as well > because the new LSR ID would then need to be exchanged. We could treat it > as an enhancement instead in my view. Do you agree? >=20 > Thanks, > Vishwas >=20 > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > wrote: >=20 > Yes, I support that too. There would be network management issues with > mapping of 4 byte LSR-ID to an IPV6 remote address. >=20 > Most of the implementations I know off usually maps 4 byte of the LSR-ID > with a local ipv4 interface address in the system. >=20 >=20 >=20 > Thanks, >=20 > Pranjal >=20 >=20 >=20 > ________________________________ >=20 > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > Sent: Wednesday, February 29, 2012 4:57 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com >=20 >=20 > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 >=20 >=20 > Hi Mustapha, > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I pointed out > in my first email. >=20 > Thanks > Lizhong >=20 >=20 > "Aissaoui, Mustapha (Mustapha)" > wrote 2012/03/01 04:35:41: >=20 > > Hi Lizhong, > > I actually think that we would need to define a new one which will > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > a all-IPv6 network will not be possible. I cannot see that operators > > will start maintaining a mapping of some global non routable LSR-id > > value to an IPv6 loopback interface on each router in the network. > > > > Mustapha. > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Tuesday, February 07, 2012 10:12 AM > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > Lizhong, > > the existing LSR-id will do the job and should be supported since > > the LSR-id need not be an IP address. Most implementations will > > actually populate the field with a /32 address in IPv4 and thus If > > necessary we could define a new format to allow the use of /128 > IPv6addresses. > > > > Mustapha. > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Monday, February 06, 2012 10:23 PM > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > Hi, > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > session in dual-stack network. LDP capability is per node > > capability, not per interface capability. But for LDP to choose the > > correct downstream session and output interface for each FEC, it > > should also check if the output interface is LDP enabled or not. The > > link adjacency could be used to assist such kind of checking. > > > > However, IMO, it is valuable to allow two independent LDP sessions > > for IPv4 and IPv6 as an option. Regarding the format definition in > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > new format of LSR-ID. > > > > Regards > > Lizhong > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > From: "Dutta, Pranjal K (Pranjal)" > > > To: Vishwas Manral > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > , "mpls@ietf.org" > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Message-ID: > > > > > > alcatel-lucent.com> > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > I would rather for complete separation with multiple lsr-id because > > > having separate link adjacencies does not really solved any problem. > > > Since hello adjacencies are associated with a link, still fate > > > sharing would continue over the single ldp/tcp session for IPV4 and IPV6. > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > only decide whether such a link is to be programmed for IPV4 or IPV6 > > > egress traffic but I see it as overkill and unnecessary scalability impacts. > > > > > > Thanks, > > > Pranjal > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > > mail is solely property of the sender's organization. This mail > > communication is confidential. Recipients named above are obligated > > to maintain secrecy and are not permitted to disclose the contents > > of this communication to others. > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please > > notify the originator of the message. Any views expressed in this > > message are those of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 09:25:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3C21F86B8 for ; Mon, 12 Mar 2012 09:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80Bj9dMieIlL for ; Mon, 12 Mar 2012 09:25:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A570B11E8079 for ; Mon, 12 Mar 2012 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=36619; q=dns/txt; s=iport; t=1331569519; x=1332779119; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lPRrypLdVFBbpr0gkNz3BQXRXz5P1y1X9Uy4NIu/Cro=; b=Swi6ED23pLBWKX+uHU+OygW36ZViSg8ZcmR0shhA1X6PCRQOBo6VA3Jf qvg7SF35qmVBxZeTojntHBwVzZJ0pSzTMVcahrkq45Ub0dlVUUJLnNnSa BQzXlkFnYDzRuP0q8cOZRpLKrlA159eKQozTwAl83K01QmK64Pw73e04r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC8jXk+tJXG8/2dsb2JhbABBtWSBB4IJAQEBAwEBAQEPAQcBFQotBwQHBQcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEEwgBEgeHYwULn3UBlwOKQIVeYwSIVIJckHCJT4MBgTYCBQ X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65726806" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 16:25:18 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2CGPI14025814; Mon, 12 Mar 2012 16:25:18 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 11:25:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 11:25:16 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA195@XMB-RCD-111.cisco.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdAB0mgbIAIJkWAA References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" X-OriginalArrivalTime: 12 Mar 2012 16:25:18.0327 (UTC) FILETIME=[B6949070:01CD006C] Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:25:23 -0000 Hi Mustapha, Thanks for the discussion. Please see inline, =09 1.=20 Given the lack of response for #1, I am assuming this we have agreed and closed the discussion on this point. Thanks. 2.=20 > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. It is not about the FEC. It is about the LSP, and rightfully so.=20 Hopefully, answering this Q will help us - If there are 3 links (LDP enabled) between two LSRs and only two have hello adj leading to the working LDP session, then would the LSRs use the 3rd link (which doesn't have valid hello adj) for MPLS packet forwarding? - If your answer is Yes, then we have a fundamental disagreement independent of LDP IPv6. - If the answer is No, then that's inline with what's described in the last para of section 3 - differentiating IPv4 hello adj from IPv6 hello adj.=20 Perhaps, the text needs a bit of rephrasing, so please feel free to suggest. The above has no bearing on FEC type e.g. IPv4 packet being sent over LSPv6 or vice versa.=20 Hence, we leave the text as-it-is. =20 3.=20 > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. Removing last paragraph of section 2.5.2 from RFC 5036 ?=20 That would fundamentally break RFC5036. > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first.=20 Correct and that's because each LSR uses the same LDP Identifier and qualifies for the point 1 of section 2.5.2 in RFC5036, which suggests to not establish a new session if there is already one existing using the same LDP Identifier:=20 // 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > It becomes an issue of association of multiple Hello > adjacencies with a single TCP connection.=20 And it is not an issue thanks to the last para of section 2.5.2. We can NOT afford to remove it. Hence, we leave the text as-it-is in section 4 of ldp-ipv6. 4. > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. That's incorrect. As you know, PW-FEC, as per RFC5036, already requires 'extended/targetted hello adj', not 'basic hello adj' with the peer before exchanging PW-FECs with that peer. In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is enabled on an interface. This is already implicit in RFC5036. And if the interface is a dual-stack interface, then the behavior shouldn't change.=20 5.=20 > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision.=20 Well, RFC5036 (LDP version 1) prescribes using a single session for exchanging FEC-label bindings for various FEC types. We could work on version 2 to move away from that intention e.g. allow using more than one session between two LSRs.=20 > BGP allows the exchage of IPv4 prefixes over an IPv6 > connection and vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be exchanged, as permitted. We are in agreement here. 6. Given the lack of response for #6, I am assuming this we have agreed and closed the discussion on this point. Thanks. 7. > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a Please see my response to #4. Nonetheless, this is moot, as it is a MAY, and is local to the LSR. FWIW, this point has been beaten to death last yr, and I would urge you to check the discussion on the mailing list from last yr. 8. > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? If the node still receives the unsupported FEC or address type, then it indicates that the peer has a bug, and it should follow the behavior specified in RFC5036 e.g. declare a fatal error. This is orthogonal to capability or FEC filter, since the assumption here is that an LSR is willing to send/receive FEC-label bindings for both IPv4 and IPv6 and more. The point is that the loophole that has existed all along is closed when an LSR gets upgraded with the code compliant with this specification.=20 9. Given the lack of response for #1, I am assuming this we have agreed and closed the discussion on this point. Thanks. 10. > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. You do make a good point about us not changing the LDP protocol version, so, it is not a new protocol, and I agree.=20 I will consider to change GTSM to optional (MAY), subjected to Carlos's opinion. We will revisit it if/when the consensus suggests otherwise prior to RFC publication. We can close this point as well. Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, March 02, 2012 1:09 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Rajiv, > See some follow-up inline. >=20 > Regards, > Mustapha. >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, February 29, 2012 10:28 PM > To: Aissaoui, Mustapha (Mustapha); Shane Amante > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Mustapha, >=20 > Thanks for the review of the document and the feedback. It is never too late. > :) Sorry about the delay in getting back to you. >=20 > Please see inline, >=20 > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. >=20 > Yes, they were discussed in the past and closed. >=20 > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. >=20 >=20 > No. >=20 > While it is a common practice to assign a host route to the loopback interface, > and it is a common practice to use loopback interface as the next-hop, we > must not assume the common practice to be the norm for the protocol. In > fact, there is NO technical argument against using the non-host route on a > loopback interface. >=20 > In fact, almost every implementation allows the next-hop to be a non-host > route, and I am aware of at least one implementation that allows LDP to > correctly resolve the next-hop when it uses a non-host route. >=20 >=20 > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. >=20 > RFC5036 actually does make a tie in section 2.5.5 in the sense that if hello adj > ceases to exist on an interface, then LDP concludes the lack of MPLS > forwarding on that interface. So, if IPv6 hello adj failed, then stop the IPv6 > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of blindly > stopping MPLS forwarding altogether. That wouldn't make sense. >=20 > // > when it receives a Hello that matches the adjacency. If the timer > expires without receipt of a matching Hello from the peer, LDP > concludes that the peer no longer wishes to label switch using that > label space for that link (or target, in the case of Targeted Hellos) > or that the peer has failed. The LSR then deletes the Hello // >=20 > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. >=20 > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. >=20 > I agree. It doesn't have anything to do with the address family, but it > becomes restrictive when having to accommodate transport of two different > address families (IPv4 and IPv6). Pls see more details on this later on. >=20 > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. >=20 > That's not correct (and the implementation is in violation of RFC5036). >=20 > We had good discussion on this early on. In fact, we had an editor's note on > this in initial versions of this document to solicit discussion on that. >=20 > The last para of section 2.5.2, as stated, would result in a particular IP address > (1.1.1.1, say) being encoded in the transport address in both > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared (which is > what the WG agreed to during IETF 80), then it prohibits IPv6 hello from > carrying IPv6 transport address (or IPv4 hello from carrying > IPv4 transport address). It would not make sense. >=20 > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport address > and vice versa. It wouldn't make sense and would be incorrect. >=20 > That's why the change was needed. >=20 > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. It becomes an issue of association of multiple Hello > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. >=20 > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. >=20 > We thought so too, but we uncovered various corner cases in which this > becomes problematic, not to mention that the indeterminism it would bring > into the picture. The easiest was to maintain hello adj per address-family per > peer. >=20 > For ex, consider three LDP enabled interfaces between R1 and R2, where > two are dual-stack, whereas the 3rd is single-stack (v4). If they maintain only > single adj, then they would have hello adj of one transport (v6, say) on dual- > stack interfaces, and another transport (v4, > say) on 3rd interface. >=20 > Hello adj is tightly coupled with the functional LDP peering. If (the > last) hello adj is lost, then LDP peering must be brought down. > Additionally, if hello adj is gone from an interface, then LDP should prohibit > MPLS forwarding from using that interface. >=20 > Another way to think about it is - if IPv4 stops functioning on an interface, but > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be penalized. > And vice versa. >=20 > Having separate hello adj maintenance is much cleaner/simpler and provides > deterministic behavior. >=20 > Nonetheless, an implementation could choose to optimize, if needed, to > keep both address-family related info in a single adjacency structure, but this > is all implementation specific. :) >=20 > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. >=20 > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. >=20 > Good point, but this is a different problem. It is not about the sequence > (which was ok if IPv4 hellow as carrying two IPv4 transport addresses). >=20 > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > transport address is fundamentally a wrong approach, IMO. How would IPv4 > know that IPv6 transport is even functional (and vice versa). IPv4 based > discovery should suggest IPv4 transport, and IPv6 based discovery should > suggest IPv6 transport. >=20 > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > connection and vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. >=20 > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. >=20 > We need the address-family awareness in peer hello adjacency/s, whether it > is a kept in a single adj structure or not. >=20 > Loosing the AFI awareness leads up the other problems that I mentioned > earlier. >=20 > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. >=20 > It is MAY. :) > It was changed to MAY based on the exhaustive discussion on mailing list in > 2011 for us to move forward. >=20 > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > different protocol. >=20 > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. >=20 > We initially thought so too, until we discovered the following very explicitly in > RFC5036. This is a recipe for a disaster, if left untreated. >=20 > // > Section 3.5.5.1 - > If an LSR does not support the Address Family specified in the Address List > TLV, it SHOULD send an Unsupported Address Family Notification to its LDP > signaling an error and abort processing the message. >=20 > Section 3.4.1.1 - > If in decoding a FEC TLV an LSR encounters a FEC Element with an Address > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > processing the message containing the TLV, and send an "Unsupported > Address Family" Notification message to its LDP peer signaling an error. > // >=20 > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? >=20 >=20 > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. >=20 > Because it is native in IPv6 to allow for link-local addresses that IPv4 never > allowed. > So, what was an anomaly with IPv4 is now a standard behavior with IPv6, > hence, that verbiage. >=20 >=20 > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. >=20 > We posed the Q about GTSM being the default or not during IETF 80, and > there were 10-yes and 0-no (mostly from operators) Pls see the minutes, > http://www.ietf.org/proceedings/80/minutes/mpls.txt >=20 > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Monday, February 06, 2012 3:21 PM > > To: Shane Amante > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > LDP as defined in RFC 5036 can carry multiple FEC types within an LDP > session > > from a peer which is identified by the LDP identifier tuple {LSR-id, > label-space- > > id}. If two LSR nodes using the same LSR-id want to advertise two > different label > > spaces, then they must use two different Hello adjacencies and LDP > sessions for > > that. Also, if an implementation supports virtualization of LDP, then > a different > > LDP identifier altogether can be used to establish a separate LDP > session. Other > > than that, there is no relation between the type of adjacency and the > FEC which > > are carried. For example, the same LDP Hello Adjacency and LDP session > are > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between > two > > directly connected peers. > > > > As far as I know BGP is not very different. It offers the ability to > carry IPv4 NLRI > > over a IPv6 session and vice versa. > > > > If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 > on an IPv4 > > session between two LSRs, then we should consider extending RFC 5036 > to > > allow for two different LSR-id values sharing the same global label > space. This > > way, we can have separate Hello adjacency and LDP session and it is up > to the > > user to assign which FEC type is allowed on which LDP session. This is > a new > > work item but in my view much cleaner and backward compatible with RFC > > 5036 than to try to tie the address family to the type of Hello > adjacency. > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > Hello > > adjacency but a single shared LDP session. It is not exactly what you > are asking > > for. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Friday, February 03, 2012 11:32 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mustapha, > > > > I am not an author, but I do want to provide some operational input on > some of > > your comments. Specifically, I get the sense from several of your > comments -- > > actually, moreso from #3 -- that you are opposed to maintaining > separate LDP > > Hello and/or Session Adjacencies: 1 for each address family. (If my > impression > > is incorrect I apologize). > > > > I actually *do* want to have separate LDP Hello and Session > adjacencies: one > > per address family, at least at this point in time. I'm concerned > about > > [operational] issues that may develop in, for example, v6 affecting > the > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one > more > > concrete example, 6man/v6ops are only right now working on improving > the > > robustness of IPv6 ND to DoS attacks. There are potentially other > areas where > > IPv6 will be hardened, as well. The bottom-line is I do not want > problems in v6 > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > FWIW, there has > > already been a precedent here wrt BGP where there it maintains > separate > > neighbors/sessions for each address family, so why aren't we doing the > same > > thing for LDP? > > > > Ultimately, having separate sessions over-the-wire is much more > intuitive to > > operators in lots of cases where they may expect that a configuration > change > > or bugs they /think/ are only going to affect one address family, > really do only > > affect one address family. Besides, LDP Hello & Sessions timers, when > set to > > default, are extremely relaxed (order of several seconds), so the > burden on > > implementations to maintain separate sessions should be miniscule. > > > > IMO, I would prefer that the default be separate Hellos & Sessions > over the > > wire to avoid "fate sharing". Only when an operator chooses to > explicitly > > configure their device to have hellos and sessions share fate should > the device > > do so. > > > > Just my $0.02, > > > > -shane > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > Dear authors, > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > > > > > Regards, > > > Mustapha. > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > > > > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 09:28:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598C411E8081 for ; Mon, 12 Mar 2012 09:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.628 X-Spam-Level: X-Spam-Status: No, score=-9.628 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GRYpqBZAnw4 for ; Mon, 12 Mar 2012 09:28:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A79C721F86B0 for ; Mon, 12 Mar 2012 09:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14014; q=dns/txt; s=iport; t=1331569720; x=1332779320; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AAh0TBdUba7sPbR/pIPMSJOP+qjkKU9fED7bUoS4s+M=; b=VAS1SnNQVstjsf30czcCLXkcxl2nR0NK2TLM+OdKlrr7zPHvoMmiUS2o 4ATbLGteKt1vgcxzDYkuGghHbdfrH7vXvIuIb69Obczov29bdc8yjmTQi 2FX+yu8vPF0Nh6WMyl98c/qQ0pqb+ehwVrztZQF1yg7+PfjNiDpt6QDtB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALIjXk+tJXG9/2dsb2JhbAA3CrVkgQeCCQEBAQMBAQEBDwEdCjQLBQcEAgEIEQMBAQEBCgYXAQYBIAYfCQgCBAESCBMHh2MFC591AZcDiURoBQSFaWMEiFSYI4R4gwGBNwc X-IronPort-AV: E=Sophos;i="4.73,570,1325462400"; d="scan'208";a="62684514" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2012 16:28:40 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CGSdsG023360; Mon, 12 Mar 2012 16:28:39 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 11:28:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 11:28:29 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQA== References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Aissaoui, Mustapha (Mustapha)" , "Vishwas Manral" X-OriginalArrivalTime: 12 Mar 2012 16:28:39.0816 (UTC) FILETIME=[2EAD5880:01CD006D] Cc: mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:28:42 -0000 Pranjal, > on technical reasons on why it is MUST to have hello adjacency over > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:25 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajeev, > We are not discussing about text rephrasing here and have been raising > technical issues. Could you please respond on my earlier mail > on technical reasons on why it is MUST to have hello adjacency over > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:33 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > Certainly. That would be a sub-optimal protocol design, let alone the > subsequent implementations. > Thankfully, that's not what is prescribed. >=20 > May I request you to review the verbiage a bit carefully? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Friday, March 02, 2012 2:37 PM > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Yes, this approach would lead to all "kludgy" implementations. Due to > race > > conditions between UDP based LDP hellos and TCP connections (since > they > > are independent channels) it may lead to states of continually > flapping > > sessions. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > ________________________________ > > > > From: Aissaoui, Mustapha (Mustapha) > > Sent: Friday, March 02, 2012 11:26 AM > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > Cc: Lizhong Jin; mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > I also have an issue with the stability of such an implementation. The > draft > > suggests in Section 6.1 - Transport connection establishment, that a > TCP > > connection with IPv6 should be preferred to one with IPv4 if both IPv4 > and > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came up > first > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is > > established, we tear down the IPv4 TCP connection and signal the IPv6 > one. > > This of course is not acceptable. In RFC 5036 compliant > implementations, > > when a new adjacency comes up to the same LSR-ID, we just associate it > > with the existing TCP connection which was bootstrapped by the first > Hello > > adjacency. > > > > > > > > Mustapha. > > > > > > > > ________________________________ > > > > From: Dutta, Pranjal K (Pranjal) > > Sent: Friday, March 02, 2012 1:22 PM > > To: Vishwas Manral > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Viswas, > > > > We raised one more point earlier on the following > clause in the > > draft. > > > > > > > > Section 6.2 > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes that > > if an LSR has a dual-stack interface, which is enabled with both > > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 > and > > IPv6 LDP Link Hellos and must separately maintain the Hello > > adjacency for IPv4 and IPv6 on that interface. > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > forwarding on a dual-stacked interface, as well as successful LDP > > peering using the appropriate transport on a multi-access > > interface (even if there are IPv4-only, IPv6-only and dual-stack > > LSRs connected to that multi-access interface). > > > > > > The draft mandates that two separate hello adjacencies should be > > maintained on dual-stack - one for IPV4 and another for IPV6. We don't > see > > any benefit or technical reason of running two separate adjacencies. > > > > 1. First of all, doing so does not provide fate > separation any way. > > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. > > > > 2. This clause mandates that a transit network > that is carrying IPV6 > > LSPs must provision IPv6 interfaces. It is not mandatory that the > transport > > network itself be IPV6 in order to carry IPV6 traffic over its > tunnels. This is a > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > necessary > > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. > The > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > still be > > resolved by an IPV4 route next-hop. It's not necessary that source of > hellos > > be IPv6 or transport address of TCP session be ipv6. > > > > 3. This clause has unnecessary scalability > implications. We do run > > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > > backhauls or similar deployments. This clause requires to run 20K > hello > > adjacencies which has scalability implications. On theory there may > not much > > difference between 10K and 20K but in real implementations there is. > If we > > allow separation of sessions for fate separation of IPV4 and IPV6 then > it > > would become 40K adjacencies. > > > > We can limit to only one hello adjacency per interface yet address the > dual > > stack issue. A graceful solution is to come up with a notion of LDP > adjacency > > specific capabilities (similar to LDP capabilities that applies to > entire sessions) > > that would benefit multiple purposes. For example, we have multiple > ECMP > > Links between neighboring LSRs A and B as shows below. > > > > > +----------------L1------------------+ > > | > | > > A > ----------------L2----------------- B > > | > | > > > +----------------L3------------------+ > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using > either > > IPV4 OR ipv6 addresses but not both. > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > > and L3 are IPv6 capable. > > > > Then hellos exchanged over link would advertise capabilities as below: > > > > L1 would carry capabilities - Ipv4 + Mcast > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > From an implementer/system designer's point of view I would think > single > > hello adjacency with per adjacency capabilities would be right > approach. > > > > Thanks, > > Pranjal > > > > > > > > ________________________________ > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Wednesday, February 29, 2012 5:11 PM > > To: Dutta, Pranjal K (Pranjal) > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > So the two main comments that have come after last call are: > > > > 1. Allow for separation of sessions along with the adjacency. > > 2. Allow for an IPv6 based LSR-ID. > > > > The second could lead to changes required in both OSPF and IS-IS, as > well > > because the new LSR ID would then need to be exchanged. We could treat > it > > as an enhancement instead in my view. Do you agree? > > > > Thanks, > > Vishwas > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > wrote: > > > > Yes, I support that too. There would be network management issues with > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > Most of the implementations I know off usually maps 4 byte of the > LSR-ID > > with a local ipv4 interface address in the system. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > ________________________________ > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Wednesday, February 29, 2012 4:57 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > Hi Mustapha, > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out > > in my first email. > > > > Thanks > > Lizhong > > > > > > "Aissaoui, Mustapha (Mustapha)" lucent.com> > > wrote 2012/03/01 04:35:41: > > > > > Hi Lizhong, > > > I actually think that we would need to define a new one which will > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > > a all-IPv6 network will not be possible. I cannot see that operators > > > will start maintaining a mapping of some global non routable LSR-id > > > value to an IPv6 loopback interface on each router in the network. > > > > > > Mustapha. > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Lizhong, > > > the existing LSR-id will do the job and should be supported since > > > the LSR-id need not be an IP address. Most implementations will > > > actually populate the field with a /32 address in IPv4 and thus If > > > necessary we could define a new format to allow the use of /128 > > IPv6addresses. > > > > > > Mustapha. > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Monday, February 06, 2012 10:23 PM > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > > Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi, > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > session in dual-stack network. LDP capability is per node > > > capability, not per interface capability. But for LDP to choose the > > > correct downstream session and output interface for each FEC, it > > > should also check if the output interface is LDP enabled or not. The > > > link adjacency could be used to assist such kind of checking. > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > new format of LSR-ID. > > > > > > Regards > > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > To: Vishwas Manral > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > , "mpls@ietf.org" > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Message-ID: > > > > > > > > > > alcatel-lucent.com> > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > I would rather for complete separation with multiple lsr-id > because > > > > having separate link adjacencies does not really solved any > problem. > > > > Since hello adjacencies are associated with a link, still fate > > > > sharing would continue over the single ldp/tcp session for IPV4 > and IPV6. > > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > > only decide whether such a link is to be programmed for IPV4 or > IPV6 > > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 09:30:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E7111E8093 for ; Mon, 12 Mar 2012 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.292 X-Spam-Level: X-Spam-Status: No, score=-9.292 tagged_above=-999 required=5 tests=[AWL=1.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MTQj9tv+iCx for ; Mon, 12 Mar 2012 09:30:36 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D8B1211E808F for ; Mon, 12 Mar 2012 09:30:35 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2CGUIFW006869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 11:30:21 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CGUHsH027079 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:00:17 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 12 Mar 2012 22:00:16 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante Date: Mon, 12 Mar 2012 22:00:14 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:30:37 -0000 There are more subtleties involved when we talk on real implementation. If order to have fate separation between IPV4 and IPV6, we need separation = of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been differe= nt, so obviously it would lead to two separate LDP sessions. Howevever whether both an implementation wants to send hellos for both=20 adjacencies on a same interface (either ipv4 or ipv6) or different=20 interfaces is implementation specific. We send hellos over an interface=20 as intent of a LSR to include that interface for traffic and multiple=20 LSRs can hellos with same source ip address.=20 Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: Monday, March 12, 2012 7:24 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Shane, Pranjal, Let's make sure that we don't have any disconnect here at least on the technicalities here (ignoring the draft discussion for a minute) Shane's Q is whether either v4 or v6 hello could help to establish v4 and/or v6 LDP session.=20 While Pranjal's assertion is correct on its own, it doesn't quite answer the subtlety in Shane's Q. Shane's Q: > With respect to LDP Hellos, you're suggesting that operators run either IPv4- > only Hello's or IPv6-only Hello's, (never both at the same time), but through > either one can discover the "(IPv4|IPv6) transport capabilities" of a LDP peer > and, based on that, establish an IPv4 and/or IPv6 LDP session. Correct? Not really. Using v4 hello MUST not lead to using v6 transport and v6 LDP session. That would be a fundamentally wrong approach. As Pranjal said, v4 hello usage must lead to v4 session establishment, whereas v6 hello usage must lead to v6 session establishment. Cheers, Rajiv > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Dutta, Pranjal K (Pranjal) > Sent: Tuesday, March 06, 2012 1:28 PM > To: Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Shane, > Yes, that's correct. We can run either ipv4 hellos or ipv6 hellos and > operator can choose whichever is best, based upon the operational needs. > Since the src ip addresses used by hello packets are not coupled with FEC > types so single hello can advertise various FEC capabilities. >=20 > If we run multiple ldp sessions between peering systems for fate > separation of ipv4 and ipv6 then there can be two separate hello adjacencies > over a single interface (each one associated with separate sessions) but in > that case the LSR-IDS used would be different (we need to work for an > extension of RFC 5036). >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Monday, March 05, 2012 10:13 PM > To: Dutta, Pranjal K (Pranjal) > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Pranjal, >=20 > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > Hi Shane, > > Yes, two separate LDP sessions are required for fate separation of ipv4 > and ipv6 fecs. > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > satisfy > > a) and b). Both can be achieved with single hello adjacency per > > interface per peering lsr-id with adjacency specific capabilities. >=20 > I'm in agreement with you with respect to LDP sessions. >=20 > With respect to LDP Hellos, you're suggesting that operators run either IPv4- > only Hello's or IPv6-only Hello's, (never both at the same time), but through > either one can discover the "(IPv4|IPv6) transport capabilities" of a LDP peer > and, based on that, establish an IPv4 and/or IPv6 LDP session. Correct? >=20 > -shane >=20 >=20 >=20 > > Thanks, > > Pranjal > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Shane Amante > > Sent: Friday, March 02, 2012 11:34 PM > > To: mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mark, > > > > I completely agree with all of your comments below. I too would (strongly) > prefer the option to allow operators to choose (via CLI) whether to: > > a) use separate transport to ensure there is no fate-sharing of IPv4 + > > IPv6; or, > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, other > AF's) on a single session, for scale reasons. > > > > -shane > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > >> (Pranjal) wrote: > >> > >>>> From an implementer/system designer's point of view I would think > >>>> single hello adjacency with per adjacency capabilities would be > >>>> right approach. > >> > >> Pranjal, I appreciate that from a vendor perspective, implementing it > >> this way would make sense for large scale deployments. > >> > >> However, for some operators who may be using BGP or RSVP to signal or > >> nest a large number of LSP's, we would like to have the option of > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for LDP. > >> > >> If there are operators who aren't going to be looking at scaling that > >> many LSP's anytime in their network, they might still prefer to > >> eliminate adjacency fate-sharing. > >> > >> I would propose that vendors implement both options, allowing > >> operators to choose (via CLI) which method they would like to deploy > >> in the field. There are many operators out there who maintain > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's to > >> protect themselves against the problems fate-sharing could bring. > >> This is why some of us prefer to make our lives harder by going > >> native, dual-stack rather than 6PE :-). > >> > >> So while I won't disagree with your opinion on using a single > >> adjacency for both AF's for scaling purposes, I would certainly like > >> to have the option to choose which method suits me best in the wild. > >> > >> Mark. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 09:38:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC221F873C for ; Mon, 12 Mar 2012 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.035 X-Spam-Level: X-Spam-Status: No, score=-9.035 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbZbyrJY2LZ7 for ; Mon, 12 Mar 2012 09:38:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BAC6521E800C for ; Mon, 12 Mar 2012 09:38:37 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2CGcRfx011040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 11:38:29 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CGcRxP027317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:08:27 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 12 Mar 2012 22:08:26 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Aissaoui, Mustapha (Mustapha)" , Vishwas Manral Date: Mon, 12 Mar 2012 22:08:23 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQAAAZQJA Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:38:39 -0000 Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 FECs by= upstream towards downstream. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 9:28 AM To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manr= al Cc: mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > on technical reasons on why it is MUST to have hello adjacency over > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:25 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Rajeev, > We are not discussing about text rephrasing here and have been raising > technical issues. Could you please respond on my earlier mail > on technical reasons on why it is MUST to have hello adjacency over > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > Cheers, > Pranjal > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:33 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > > Certainly. That would be a sub-optimal protocol design, let alone the > subsequent implementations. > Thankfully, that's not what is prescribed. > > May I request you to review the verbiage a bit carefully? > > Cheers, > Rajiv > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Friday, March 02, 2012 2:37 PM > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Yes, this approach would lead to all "kludgy" implementations. Due to > race > > conditions between UDP based LDP hellos and TCP connections (since > they > > are independent channels) it may lead to states of continually > flapping > > sessions. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > ________________________________ > > > > From: Aissaoui, Mustapha (Mustapha) > > Sent: Friday, March 02, 2012 11:26 AM > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > Cc: Lizhong Jin; mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > I also have an issue with the stability of such an implementation. The > draft > > suggests in Section 6.1 - Transport connection establishment, that a > TCP > > connection with IPv6 should be preferred to one with IPv4 if both IPv4 > and > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came up > first > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello is > > established, we tear down the IPv4 TCP connection and signal the IPv6 > one. > > This of course is not acceptable. In RFC 5036 compliant > implementations, > > when a new adjacency comes up to the same LSR-ID, we just associate it > > with the existing TCP connection which was bootstrapped by the first > Hello > > adjacency. > > > > > > > > Mustapha. > > > > > > > > ________________________________ > > > > From: Dutta, Pranjal K (Pranjal) > > Sent: Friday, March 02, 2012 1:22 PM > > To: Vishwas Manral > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Viswas, > > > > We raised one more point earlier on the following > clause in the > > draft. > > > > > > > > Section 6.2 > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes that > > if an LSR has a dual-stack interface, which is enabled with both > > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 > and > > IPv6 LDP Link Hellos and must separately maintain the Hello > > adjacency for IPv4 and IPv6 on that interface. > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > forwarding on a dual-stacked interface, as well as successful LDP > > peering using the appropriate transport on a multi-access > > interface (even if there are IPv4-only, IPv6-only and dual-stack > > LSRs connected to that multi-access interface). > > > > > > The draft mandates that two separate hello adjacencies should be > > maintained on dual-stack - one for IPV4 and another for IPV6. We don't > see > > any benefit or technical reason of running two separate adjacencies. > > > > 1. First of all, doing so does not provide fate > separation any way. > > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. > > > > 2. This clause mandates that a transit network > that is carrying IPV6 > > LSPs must provision IPv6 interfaces. It is not mandatory that the > transport > > network itself be IPV6 in order to carry IPV6 traffic over its > tunnels. This is a > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > necessary > > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. > The > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > still be > > resolved by an IPV4 route next-hop. It's not necessary that source of > hellos > > be IPv6 or transport address of TCP session be ipv6. > > > > 3. This clause has unnecessary scalability > implications. We do run > > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > > backhauls or similar deployments. This clause requires to run 20K > hello > > adjacencies which has scalability implications. On theory there may > not much > > difference between 10K and 20K but in real implementations there is. > If we > > allow separation of sessions for fate separation of IPV4 and IPV6 then > it > > would become 40K adjacencies. > > > > We can limit to only one hello adjacency per interface yet address the > dual > > stack issue. A graceful solution is to come up with a notion of LDP > adjacency > > specific capabilities (similar to LDP capabilities that applies to > entire sessions) > > that would benefit multiple purposes. For example, we have multiple > ECMP > > Links between neighboring LSRs A and B as shows below. > > > > > +----------------L1------------------+ > > | > | > > A > ----------------L2----------------- B > > | > | > > > +----------------L3------------------+ > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are using > either > > IPV4 OR ipv6 addresses but not both. > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). L2 > > and L3 are IPv6 capable. > > > > Then hellos exchanged over link would advertise capabilities as below: > > > > L1 would carry capabilities - Ipv4 + Mcast > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > From an implementer/system designer's point of view I would think > single > > hello adjacency with per adjacency capabilities would be right > approach. > > > > Thanks, > > Pranjal > > > > > > > > ________________________________ > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Wednesday, February 29, 2012 5:11 PM > > To: Dutta, Pranjal K (Pranjal) > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > So the two main comments that have come after last call are: > > > > 1. Allow for separation of sessions along with the adjacency. > > 2. Allow for an IPv6 based LSR-ID. > > > > The second could lead to changes required in both OSPF and IS-IS, as > well > > because the new LSR ID would then need to be exchanged. We could treat > it > > as an enhancement instead in my view. Do you agree? > > > > Thanks, > > Vishwas > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > wrote: > > > > Yes, I support that too. There would be network management issues with > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > Most of the implementations I know off usually maps 4 byte of the > LSR-ID > > with a local ipv4 interface address in the system. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > ________________________________ > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > Sent: Wednesday, February 29, 2012 4:57 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > Hi Mustapha, > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > pointed out > > in my first email. > > > > Thanks > > Lizhong > > > > > > "Aissaoui, Mustapha (Mustapha)" lucent.com> > > wrote 2012/03/01 04:35:41: > > > > > Hi Lizhong, > > > I actually think that we would need to define a new one which will > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions in > > > a all-IPv6 network will not be possible. I cannot see that operators > > > will start maintaining a mapping of some global non routable LSR-id > > > value to an IPv6 loopback interface on each router in the network. > > > > > > Mustapha. > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Lizhong, > > > the existing LSR-id will do the job and should be supported since > > > the LSR-id need not be an IP address. Most implementations will > > > actually populate the field with a /32 address in IPv4 and thus If > > > necessary we could define a new format to allow the use of /128 > > IPv6addresses. > > > > > > Mustapha. > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Monday, February 06, 2012 10:23 PM > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > > Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi, > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > session in dual-stack network. LDP capability is per node > > > capability, not per interface capability. But for LDP to choose the > > > correct downstream session and output interface for each FEC, it > > > should also check if the output interface is LDP enabled or not. The > > > link adjacency could be used to assist such kind of checking. > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > RFC5036, we may need new LDP version number to identify IPv6 LSR-ID. > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > new format of LSR-ID. > > > > > > Regards > > > Lizhong > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > Message: 1 > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > To: Vishwas Manral > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > , "mpls@ietf.org" > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Message-ID: > > > > > > > > > > alcatel-lucent.com> > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > I would rather for complete separation with multiple lsr-id > because > > > > having separate link adjacencies does not really solved any > problem. > > > > Since hello adjacencies are associated with a link, still fate > > > > sharing would continue over the single ldp/tcp session for IPV4 > and IPV6. > > > > Having IPV4 and IPV6 specific hello adjacencies over a link would > > > > only decide whether such a link is to be programmed for IPV4 or > IPV6 > > > > egress traffic but I see it as overkill and unnecessary > scalability impacts. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this > > > mail is solely property of the sender's organization. This mail > > > communication is confidential. Recipients named above are obligated > > > to maintain secrecy and are not permitted to disclose the contents > > > of this communication to others. > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please > > > notify the originator of the message. Any views expressed in this > > > message are those of the individual sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > > system. > > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 09:44:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5356421F87CC for ; Mon, 12 Mar 2012 09:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.366 X-Spam-Level: X-Spam-Status: No, score=-7.366 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1jCVYbgizaL for ; Mon, 12 Mar 2012 09:44:52 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 08E4321F87BE for ; Mon, 12 Mar 2012 09:44:51 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2CGiccK012199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 11:44:41 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CGibSh002378 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:14:37 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 12 Mar 2012 22:14:37 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Mon, 12 Mar 2012 22:14:34 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+A Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com> <14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:44:53 -0000 Rajeev, Not really. There are applications that auto-instantiate T-LDP sessions.=20 You know transport address only after exchanging hellos. First hellos need to be sent to right remote LSR-ID. We don't run another discovery protocol= =20 that says "here is the BGP next-hop X but its LSR-ID is Y". Are you sugges= ting that all such applications are irrelevant and needs to be wiped out from deployments. I haven't heard of any text in RFC 5036 that says=20 "4 byte router-id MUST not be a routable address". Cheers, Pranjal=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: Monday, March 12, 2012 7:06 AM To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); mtinka@globaltransit= .net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Mustapha, Wim, > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has to > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > LDP has to auto-create targeted sessions. We can't force to set-up another > ip4 network just for some applications. It won't be possible to map 4 byte ldp I hope that we are not misunderstanding 32-bit integer value in RouterID in an IPv6-only router to mean having IPv4 network.=20 Also, such applications must use 'transport IP address', not the Router-ID when it comes to setting up the session. If they don't, then they are incorrect and must be fixed. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Friday, March 02, 2012 12:02 PM > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, > We shouldn't be ruling out the fact that there are some differences in > applications of LDP compared to OSPF or BGP. If we have IPV6 only transport > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has to > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > LDP has to auto-create targeted sessions. We can't force to set-up another > ip4 network just for some applications. It won't be possible to map 4 byte ldp > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID is must > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility and better > to add it now. >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Henderickx, Wim (Wim) > Sent: Friday, March 02, 2012 12:41 AM > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, >=20 > I understand we didn't add a IPv6 router ID option in BGP/OSPF but we > should look at the future to get to IPv6 only networks and as such it will be > required. So we are now at a point where we should add this option in all > protocols. Since LDP for Ipv6 is open we need to add it now. >=20 > My 2 cents >=20 > Cheers, > Wim >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: vrijdag 2 maart 2012 8:08 > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Wim, >=20 > That's a reasonable point, but no such proposal has been made for other > protocols. In fact, IPv6 deployments have already accommodated 4-octet > router-id for routing protocols (which was also a departure from the > common practice in IPv4 realm). As Mark T and I discussed in the > previous email, the router-id consistency across protocols would be an > operational benefit. >=20 > Focusing on the technicalities, Router ID is meant to ensure the > uniqueness of the router within the network while following the > protocol, so are we thinking that 4-octet is not good enough to ensure > the uniqueness? If so, then it would be worth having that discussion in > the Routing and Internet areas that have been focusing on IPv6 at large. >=20 >=20 > While I do agree to 128-bit future expandability as a benefit, the > benefit would be trivial (at the expense of message structure changes) > if we expanded it for the sake of it, but didn't address the root of the > problem. >=20 > Do you think otherwise? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > > Sent: Friday, March 02, 2012 1:42 AM > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, I believe we need to provide both options to ensure both are > possible. > > If we do not introduce the IPv6 LSR ID now I will be very hard to ad > it in the > > future. > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: vrijdag 2 maart 2012 7:39 > > To: mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mark, > > > > Well said. > > > > I take that we are in agreement wrt 4-octet entity for LDP router-id > in > > the context of IPv6, as specified. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > Sent: Friday, March 02, 2012 1:31 AM > > > To: Rajiv Asati (rajiva) > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > lizhong.jin@zte.com.cn; > > > vishwas.ietf@gmail.com > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > wrote: > > > > > > > In the past, implementations provided the router-id CLI > > > > for any interface IPv4 address to be chosen as router-id > > > > for various protocols including LDP. > > > > > > > However, many implementations already evolved the CLI to > > > > not even give an "interface" IP address for router-id, > > > > to accommodate IPv6. Almost all deployed networks > > > > already accommodated that. > > > > > > We do operate some implementations today that "still" allow > > > you to specify the Router-ID for various protocols as an > > > independent 32-bit integer (only), and also allow you to > > > define the LSR-ID for LDP as an interface (only). This is > > > current, shipping 2012 code. > > > > > > So both scenarios you mention above are still much in play > > > today. Whether operators are using them or not (I know we > > > are) is another matter entirely. > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > implementations could evolve LDP router-id as well to > > > > accommodate IPv6. This would make LDP router-id to be > > > > consistent with other protocols delving with IPv6. And > > > > this can certainly be operationally beneficial from IPv6 > > > > POV. > > > > > > Agree. > > > > > > > In fact, one of the implementations allow the router-id > > > > to be configured just once and let all protocols just > > > > use it, if they wanted. > > > > > > Yes, we operate some implementations that use this method > > > too. It's quite elegant, in that you configure once and > > > forget. Other implementations that are more structured means > > > operators could easily forget to specify the Router-ID for a > > > particular protocol, for better or worse. > > > > > > Cheers, > > > > > > Mark. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 09:51:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A4921E8057 for ; Mon, 12 Mar 2012 09:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.635 X-Spam-Level: X-Spam-Status: No, score=-9.635 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLdv--Cxalkr for ; Mon, 12 Mar 2012 09:51:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD521E8045 for ; Mon, 12 Mar 2012 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=15783; q=dns/txt; s=iport; t=1331571067; x=1332780667; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CmnuJlfVuXTScsld1gQNM5JgVLPRKBGBo0FD2Sbk3h0=; b=eTgu4VqClUCrUWyr2jRIFX1vb1eo5HNNRM+GIrN/gU7eVDblEwNtQPlc ENL1RL97q2E6qPPgenAedO+CQiV4Xhfn4qEdSNWqtWvMakQxjUzl86ItC HFLUIkg/nOJcxoGZwcEnaabQfVg7I/EdiSylhJlezl9IvOPggXLVTq/xU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANooXk+tJXHB/2dsb2JhbAA5CrVXgQeCCQEBAQMBAQEBDwEdCjQLBQcEAgEIEQMBAQEBCgYXAQYBIAYfCQgCBAESCBMHh2MFC50zAZ5niURoBQSFaWMEiFSYI4R4gwGBNwc X-IronPort-AV: E=Sophos;i="4.73,571,1325462400"; d="scan'208";a="65733608" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 12 Mar 2012 16:51:04 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2CGp4h1017443; Mon, 12 Mar 2012 16:51:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 11:51:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 11:51:03 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA1CF@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQAAAZQJAAABwCxA= References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Aissaoui, Mustapha (Mustapha)" , "Vishwas Manral" X-OriginalArrivalTime: 12 Mar 2012 16:51:04.0299 (UTC) FILETIME=[500D2BB0:01CD0070] Cc: mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:51:08 -0000 Pranjal, Could you please point to the relevant section in the ldp-ipv6 draft? Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:38 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 FECs by > upstream towards downstream. >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 9:28 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > on technical reasons on why it is MUST to have hello adjacency over > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? >=20 > When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? >=20 > Cheers, > Rajiv >=20 >=20 >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:25 PM > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajeev, > > We are not discussing about text rephrasing here and have been > raising > > technical issues. Could you please respond on my earlier mail > > on technical reasons on why it is MUST to have hello adjacency over > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > Cheers, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:33 AM > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, > > > > Certainly. That would be a sub-optimal protocol design, let alone the > > subsequent implementations. > > Thankfully, that's not what is prescribed. > > > > May I request you to review the verbiage a bit carefully? > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Dutta, Pranjal K (Pranjal) > > > Sent: Friday, March 02, 2012 2:37 PM > > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Yes, this approach would lead to all "kludgy" implementations. Due > to > > race > > > conditions between UDP based LDP hellos and TCP connections (since > > they > > > are independent channels) it may lead to states of continually > > flapping > > > sessions. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Aissaoui, Mustapha (Mustapha) > > > Sent: Friday, March 02, 2012 11:26 AM > > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > > Cc: Lizhong Jin; mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > I also have an issue with the stability of such an implementation. > The > > draft > > > suggests in Section 6.1 - Transport connection establishment, that a > > TCP > > > connection with IPv6 should be preferred to one with IPv4 if both > IPv4 > > and > > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came > up > > first > > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello > is > > > established, we tear down the IPv4 TCP connection and signal the > IPv6 > > one. > > > This of course is not acceptable. In RFC 5036 compliant > > implementations, > > > when a new adjacency comes up to the same LSR-ID, we just associate > it > > > with the existing TCP connection which was bootstrapped by the first > > Hello > > > adjacency. > > > > > > > > > > > > Mustapha. > > > > > > > > > > > > ________________________________ > > > > > > From: Dutta, Pranjal K (Pranjal) > > > Sent: Friday, March 02, 2012 1:22 PM > > > To: Vishwas Manral > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Viswas, > > > > > > We raised one more point earlier on the > following > > clause in the > > > draft. > > > > > > > > > > > > Section 6.2 > > > > > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes > that > > > if an LSR has a dual-stack interface, which is enabled with both > > > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 > > and > > > IPv6 LDP Link Hellos and must separately maintain the Hello > > > adjacency for IPv4 and IPv6 on that interface. > > > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > > forwarding on a dual-stacked interface, as well as successful > LDP > > > peering using the appropriate transport on a multi-access > > > interface (even if there are IPv4-only, IPv6-only and > dual-stack > > > LSRs connected to that multi-access interface). > > > > > > > > > The draft mandates that two separate hello adjacencies should be > > > maintained on dual-stack - one for IPV4 and another for IPV6. We > don't > > see > > > any benefit or technical reason of running two separate adjacencies. > > > > > > 1. First of all, doing so does not provide fate > > separation any way. > > > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. > > > > > > 2. This clause mandates that a transit network > > that is carrying IPV6 > > > LSPs must provision IPv6 interfaces. It is not mandatory that the > > transport > > > network itself be IPV6 in order to carry IPV6 traffic over its > > tunnels. This is a > > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > > necessary > > > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. > > The > > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > > still be > > > resolved by an IPV4 route next-hop. It's not necessary that source > of > > hellos > > > be IPv6 or transport address of TCP session be ipv6. > > > > > > 3. This clause has unnecessary scalability > > implications. We do run > > > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > > > backhauls or similar deployments. This clause requires to run 20K > > hello > > > adjacencies which has scalability implications. On theory there may > > not much > > > difference between 10K and 20K but in real implementations there is. > > If we > > > allow separation of sessions for fate separation of IPV4 and IPV6 > then > > it > > > would become 40K adjacencies. > > > > > > We can limit to only one hello adjacency per interface yet address > the > > dual > > > stack issue. A graceful solution is to come up with a notion of LDP > > adjacency > > > specific capabilities (similar to LDP capabilities that applies to > > entire sessions) > > > that would benefit multiple purposes. For example, we have multiple > > ECMP > > > Links between neighboring LSRs A and B as shows below. > > > > > > > > +----------------L1------------------+ > > > | > > | > > > A > > ----------------L2----------------- B > > > | > > | > > > > > +----------------L3------------------+ > > > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are > using > > either > > > IPV4 OR ipv6 addresses but not both. > > > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). > L2 > > > and L3 are IPv6 capable. > > > > > > Then hellos exchanged over link would advertise capabilities as > below: > > > > > > L1 would carry capabilities - Ipv4 + Mcast > > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > > > > From an implementer/system designer's point of view I would think > > single > > > hello adjacency with per adjacency capabilities would be right > > approach. > > > > > > Thanks, > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > Sent: Wednesday, February 29, 2012 5:11 PM > > > To: Dutta, Pranjal K (Pranjal) > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > > > So the two main comments that have come after last call are: > > > > > > 1. Allow for separation of sessions along with the adjacency. > > > 2. Allow for an IPv6 based LSR-ID. > > > > > > The second could lead to changes required in both OSPF and IS-IS, as > > well > > > because the new LSR ID would then need to be exchanged. We could > treat > > it > > > as an enhancement instead in my view. Do you agree? > > > > > > Thanks, > > > Vishwas > > > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > wrote: > > > > > > Yes, I support that too. There would be network management issues > with > > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > > > Most of the implementations I know off usually maps 4 byte of the > > LSR-ID > > > with a local ipv4 interface address in the system. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Wednesday, February 29, 2012 4:57 PM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com > > > > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > > > Hi Mustapha, > > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > > pointed out > > > in my first email. > > > > > > Thanks > > > Lizhong > > > > > > > > > "Aissaoui, Mustapha (Mustapha)" > lucent.com> > > > wrote 2012/03/01 04:35:41: > > > > > > > Hi Lizhong, > > > > I actually think that we would need to define a new one which will > > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions > in > > > > a all-IPv6 network will not be possible. I cannot see that > operators > > > > will start maintaining a mapping of some global non routable > LSR-id > > > > value to an IPv6 loopback interface on each router in the network. > > > > > > > > Mustapha. > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Aissaoui, Mustapha (Mustapha) > > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > Lizhong, > > > > the existing LSR-id will do the job and should be supported since > > > > the LSR-id need not be an IP address. Most implementations will > > > > actually populate the field with a /32 address in IPv4 and thus If > > > > necessary we could define a new format to allow the use of /128 > > > IPv6addresses. > > > > > > > > Mustapha. > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > Sent: Monday, February 06, 2012 10:23 PM > > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > > > Mustapha (Mustapha) > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > Hi, > > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > > session in dual-stack network. LDP capability is per node > > > > capability, not per interface capability. But for LDP to choose > the > > > > correct downstream session and output interface for each FEC, it > > > > should also check if the output interface is LDP enabled or not. > The > > > > link adjacency could be used to assist such kind of checking. > > > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > > RFC5036, we may need new LDP version number to identify IPv6 > LSR-ID. > > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > > new format of LSR-ID. > > > > > > > > Regards > > > > Lizhong > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Message: 1 > > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > > > To: Vishwas Manral > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > , "mpls@ietf.org" > > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Message-ID: > > > > > > > > > > > > > > > alcatel-lucent.com> > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > I would rather for complete separation with multiple lsr-id > > because > > > > > having separate link adjacencies does not really solved any > > problem. > > > > > Since hello adjacencies are associated with a link, still fate > > > > > sharing would continue over the single ldp/tcp session for IPV4 > > and IPV6. > > > > > Having IPV4 and IPV6 specific hello adjacencies over a link > would > > > > > only decide whether such a link is to be programmed for IPV4 or > > IPV6 > > > > > egress traffic but I see it as overkill and unnecessary > > scalability impacts. > > > > > > > > > > Thanks, > > > > > Pranjal > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail is solely property of the sender's organization. This mail > > > > communication is confidential. Recipients named above are > obligated > > > > to maintain secrecy and are not permitted to disclose the contents > > > > of this communication to others. > > > > This email and any files transmitted with it are confidential and > > > > intended solely for the use of the individual or entity to whom > they > > > > are addressed. If you have received this email in error please > > > > notify the originator of the message. Any views expressed in this > > > > message are those of the individual sender. > > > > This message has been scanned for viruses and Spam by ZTE > Anti-Spam > > > system. > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 09:56:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AAD21F8846 for ; Mon, 12 Mar 2012 09:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.042 X-Spam-Level: X-Spam-Status: No, score=-7.042 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es-VpSddQ8es for ; Mon, 12 Mar 2012 09:55:58 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 99FAE21F8777 for ; Mon, 12 Mar 2012 09:55:55 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2CGtZHA021184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 11:55:38 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CGtZLW002773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:25:35 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 12 Mar 2012 22:25:34 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Aissaoui, Mustapha (Mustapha)" , Vishwas Manral Date: Mon, 12 Mar 2012 22:25:32 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQAAAZQJAAABwCxAAACPJAA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA1CF@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA1CF@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:56:00 -0000 Rajeev, Refer to following: "Section 6.1 3. An LSR MUST send separate Hellos (each containing either IPv4 or IPv6 transport address optional object) for each IP address- family, if LDP was enabled for both IP address-families." Cheers, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Raj= iv Asati (rajiva) Sent: Monday, March 12, 2012 9:51 AM To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manr= al Cc: mpls@ietf.org; Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Could you please point to the relevant section in the ldp-ipv6 draft? Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:38 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 FECs by > upstream towards downstream. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 9:28 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > > > on technical reasons on why it is MUST to have hello adjacency over > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? > > Cheers, > Rajiv > > > > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:25 PM > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajeev, > > We are not discussing about text rephrasing here and have been > raising > > technical issues. Could you please respond on my earlier mail > > on technical reasons on why it is MUST to have hello adjacency over > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > Cheers, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:33 AM > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, > > > > Certainly. That would be a sub-optimal protocol design, let alone the > > subsequent implementations. > > Thankfully, that's not what is prescribed. > > > > May I request you to review the verbiage a bit carefully? > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Dutta, Pranjal K (Pranjal) > > > Sent: Friday, March 02, 2012 2:37 PM > > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Yes, this approach would lead to all "kludgy" implementations. Due > to > > race > > > conditions between UDP based LDP hellos and TCP connections (since > > they > > > are independent channels) it may lead to states of continually > > flapping > > > sessions. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Aissaoui, Mustapha (Mustapha) > > > Sent: Friday, March 02, 2012 11:26 AM > > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > > Cc: Lizhong Jin; mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > I also have an issue with the stability of such an implementation. > The > > draft > > > suggests in Section 6.1 - Transport connection establishment, that a > > TCP > > > connection with IPv6 should be preferred to one with IPv4 if both > IPv4 > > and > > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came > up > > first > > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello > is > > > established, we tear down the IPv4 TCP connection and signal the > IPv6 > > one. > > > This of course is not acceptable. In RFC 5036 compliant > > implementations, > > > when a new adjacency comes up to the same LSR-ID, we just associate > it > > > with the existing TCP connection which was bootstrapped by the first > > Hello > > > adjacency. > > > > > > > > > > > > Mustapha. > > > > > > > > > > > > ________________________________ > > > > > > From: Dutta, Pranjal K (Pranjal) > > > Sent: Friday, March 02, 2012 1:22 PM > > > To: Vishwas Manral > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Viswas, > > > > > > We raised one more point earlier on the > following > > clause in the > > > draft. > > > > > > > > > > > > Section 6.2 > > > > > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes > that > > > if an LSR has a dual-stack interface, which is enabled with both > > > IPv4 and IPv6 LDP, then the LSR must periodically send both IPv4 > > and > > > IPv6 LDP Link Hellos and must separately maintain the Hello > > > adjacency for IPv4 and IPv6 on that interface. > > > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > > forwarding on a dual-stacked interface, as well as successful > LDP > > > peering using the appropriate transport on a multi-access > > > interface (even if there are IPv4-only, IPv6-only and > dual-stack > > > LSRs connected to that multi-access interface). > > > > > > > > > The draft mandates that two separate hello adjacencies should be > > > maintained on dual-stack - one for IPV4 and another for IPV6. We > don't > > see > > > any benefit or technical reason of running two separate adjacencies. > > > > > > 1. First of all, doing so does not provide fate > > separation any way. > > > Both IPV4 and IPV6 fecs are still exchanged over same LDP sessions. > > > > > > 2. This clause mandates that a transit network > > that is carrying IPV6 > > > LSPs must provision IPv6 interfaces. It is not mandatory that the > > transport > > > network itself be IPV6 in order to carry IPV6 traffic over its > > tunnels. This is a > > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > > necessary > > > that an IPV6 FEC should be resolved by an IPV6 only route next-hop. > > The > > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > > still be > > > resolved by an IPV4 route next-hop. It's not necessary that source > of > > hellos > > > be IPv6 or transport address of TCP session be ipv6. > > > > > > 3. This clause has unnecessary scalability > > implications. We do run > > > very large number of LDP adjacencies/sessions (e.g 10K) in mobility > > > backhauls or similar deployments. This clause requires to run 20K > > hello > > > adjacencies which has scalability implications. On theory there may > > not much > > > difference between 10K and 20K but in real implementations there is. > > If we > > > allow separation of sessions for fate separation of IPV4 and IPV6 > then > > it > > > would become 40K adjacencies. > > > > > > We can limit to only one hello adjacency per interface yet address > the > > dual > > > stack issue. A graceful solution is to come up with a notion of LDP > > adjacency > > > specific capabilities (similar to LDP capabilities that applies to > > entire sessions) > > > that would benefit multiple purposes. For example, we have multiple > > ECMP > > > Links between neighboring LSRs A and B as shows below. > > > > > > > > +----------------L1------------------+ > > > | > > | > > > A > > ----------------L2----------------- B > > > | > > | > > > > > +----------------L3------------------+ > > > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are > using > > either > > > IPV4 OR ipv6 addresses but not both. > > > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). > L2 > > > and L3 are IPv6 capable. > > > > > > Then hellos exchanged over link would advertise capabilities as > below: > > > > > > L1 would carry capabilities - Ipv4 + Mcast > > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > > > > From an implementer/system designer's point of view I would think > > single > > > hello adjacency with per adjacency capabilities would be right > > approach. > > > > > > Thanks, > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > Sent: Wednesday, February 29, 2012 5:11 PM > > > To: Dutta, Pranjal K (Pranjal) > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > > > So the two main comments that have come after last call are: > > > > > > 1. Allow for separation of sessions along with the adjacency. > > > 2. Allow for an IPv6 based LSR-ID. > > > > > > The second could lead to changes required in both OSPF and IS-IS, as > > well > > > because the new LSR ID would then need to be exchanged. We could > treat > > it > > > as an enhancement instead in my view. Do you agree? > > > > > > Thanks, > > > Vishwas > > > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > wrote: > > > > > > Yes, I support that too. There would be network management issues > with > > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > > > Most of the implementations I know off usually maps 4 byte of the > > LSR-ID > > > with a local ipv4 interface address in the system. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > > ________________________________ > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > Sent: Wednesday, February 29, 2012 4:57 PM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com > > > > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > > > Hi Mustapha, > > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as I > > pointed out > > > in my first email. > > > > > > Thanks > > > Lizhong > > > > > > > > > "Aissaoui, Mustapha (Mustapha)" > lucent.com> > > > wrote 2012/03/01 04:35:41: > > > > > > > Hi Lizhong, > > > > I actually think that we would need to define a new one which will > > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP sessions > in > > > > a all-IPv6 network will not be possible. I cannot see that > operators > > > > will start maintaining a mapping of some global non routable > LSR-id > > > > value to an IPv6 loopback interface on each router in the network. > > > > > > > > Mustapha. > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Aissaoui, Mustapha (Mustapha) > > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); > vishwas.ietf@gmail.com > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > Lizhong, > > > > the existing LSR-id will do the job and should be supported since > > > > the LSR-id need not be an IP address. Most implementations will > > > > actually populate the field with a /32 address in IPv4 and thus If > > > > necessary we could define a new format to allow the use of /128 > > > IPv6addresses. > > > > > > > > Mustapha. > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > Sent: Monday, February 06, 2012 10:23 PM > > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; Aissaoui, > > > > Mustapha (Mustapha) > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > Hi, > > > > I wonder if it is feasible to use LDP capability to advertise IPv6 > > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > > session in dual-stack network. LDP capability is per node > > > > capability, not per interface capability. But for LDP to choose > the > > > > correct downstream session and output interface for each FEC, it > > > > should also check if the output interface is LDP enabled or not. > The > > > > link adjacency could be used to assist such kind of checking. > > > > > > > > However, IMO, it is valuable to allow two independent LDP sessions > > > > for IPv4 and IPv6 as an option. Regarding the format definition in > > > > RFC5036, we may need new LDP version number to identify IPv6 > LSR-ID. > > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I prefer > > > > new format of LSR-ID. > > > > > > > > Regards > > > > Lizhong > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Message: 1 > > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > > > To: Vishwas Manral > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > , "mpls@ietf.org" > > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > Message-ID: > > > > > > > > > > > > > > > alcatel-lucent.com> > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > I would rather for complete separation with multiple lsr-id > > because > > > > > having separate link adjacencies does not really solved any > > problem. > > > > > Since hello adjacencies are associated with a link, still fate > > > > > sharing would continue over the single ldp/tcp session for IPV4 > > and IPV6. > > > > > Having IPV4 and IPV6 specific hello adjacencies over a link > would > > > > > only decide whether such a link is to be programmed for IPV4 or > > IPV6 > > > > > egress traffic but I see it as overkill and unnecessary > > scalability impacts. > > > > > > > > > > Thanks, > > > > > Pranjal > > > > > > > > > -------------------------------------------------------- > > > > ZTE Information Security Notice: The information contained in this > > > > mail is solely property of the sender's organization. This mail > > > > communication is confidential. Recipients named above are > obligated > > > > to maintain secrecy and are not permitted to disclose the contents > > > > of this communication to others. > > > > This email and any files transmitted with it are confidential and > > > > intended solely for the use of the individual or entity to whom > they > > > > are addressed. If you have received this email in error please > > > > notify the originator of the message. Any views expressed in this > > > > message are those of the individual sender. > > > > This message has been scanned for viruses and Spam by ZTE > Anti-Spam > > > system. > > > > > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 10:05:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56F21F87CF for ; Mon, 12 Mar 2012 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.642 X-Spam-Level: X-Spam-Status: No, score=-9.642 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eDYeiJ2Vfns for ; Mon, 12 Mar 2012 10:05:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBD21F8714 for ; Mon, 12 Mar 2012 10:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=18214; q=dns/txt; s=iport; t=1331571945; x=1332781545; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vBbKtCtN7/JzzGZG4wIyTo7OrifJntjP8xlJCVsP5ig=; b=Xgc3mHHtpYsBO6iQ3DgOBUr/3xDgBRtaJ8LW1GACBN6kzXdo5HIp1EOR ruPP6oI6bFKKFvsZcD5jFsAxd4BopGjpePKR+okrP/a0eoi27pCZ6Mydn MM84koQ0A9tQl6qSuh1cqa7+V+zbYooOE8Bl9HgV7NWI4XAT+UIxby4WI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF0sXk+tJV2a/2dsb2JhbAA5CrVXgQeCCQEBAQMBAQEBDwEdCjQLBQcEAgEIEQMBAQEBCgYXAQYBIAYfCQgCBAESCBMHh2MFC50tAZ5riURoBQSFaWMEiFSYI4R4gwGBNwc X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="65713800" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2012 17:05:45 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CH5jBo014860; Mon, 12 Mar 2012 17:05:45 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:05:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 12:05:43 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA1F9@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQAAAZQJAAABwCxAAACPJAAAAUOVQ References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com><067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA1CF@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Aissaoui, Mustapha (Mustapha)" , "Vishwas Manral" X-OriginalArrivalTime: 12 Mar 2012 17:05:44.0951 (UTC) FILETIME=[5CF60070:01CD0072] Cc: mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:05:47 -0000 Pranjal, Thanks. Perhaps, you meant to point to another section, since that doesn't say anything about what you asked: > > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 > FECs by upstream towards downstream. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:56 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > Rajeev, > Refer to following: >=20 > "Section 6.1 >=20 > 3. An LSR MUST send separate Hellos (each containing either IPv4 > or IPv6 transport address optional object) for each IP address- > family, if LDP was enabled for both IP address-families." >=20 > Cheers, > Pranjal >=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 9:51 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > Could you please point to the relevant section in the ldp-ipv6 draft? >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:38 PM > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 > FECs by > > upstream towards downstream. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Monday, March 12, 2012 9:28 AM > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, > > > > > on technical reasons on why it is MUST to have hello adjacency over > > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? > > > > Cheers, > > Rajiv > > > > > > > > > -----Original Message----- > > > From: Dutta, Pranjal K (Pranjal) > > [mailto:pranjal.dutta@alcatel-lucent.com] > > > Sent: Monday, March 12, 2012 12:25 PM > > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajeev, > > > We are not discussing about text rephrasing here and have > been > > raising > > > technical issues. Could you please respond on my earlier mail > > > on technical reasons on why it is MUST to have hello adjacency over > > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > > > Cheers, > > > Pranjal > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Rajiv Asati (rajiva) > > > Sent: Monday, March 12, 2012 7:33 AM > > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); > Vishwas > > > Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Pranjal, > > > > > > Certainly. That would be a sub-optimal protocol design, let alone > the > > > subsequent implementations. > > > Thankfully, that's not what is prescribed. > > > > > > May I request you to review the verbiage a bit carefully? > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Dutta, Pranjal K (Pranjal) > > > > Sent: Friday, March 02, 2012 2:37 PM > > > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > > > Cc: mpls@ietf.org; Lizhong Jin > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Yes, this approach would lead to all "kludgy" implementations. Due > > to > > > race > > > > conditions between UDP based LDP hellos and TCP connections (since > > > they > > > > are independent channels) it may lead to states of continually > > > flapping > > > > sessions. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Aissaoui, Mustapha (Mustapha) > > > > Sent: Friday, March 02, 2012 11:26 AM > > > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > > > Cc: Lizhong Jin; mpls@ietf.org > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > I also have an issue with the stability of such an implementation. > > The > > > draft > > > > suggests in Section 6.1 - Transport connection establishment, that > a > > > TCP > > > > connection with IPv6 should be preferred to one with IPv4 if both > > IPv4 > > > and > > > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came > > up > > > first > > > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello > > is > > > > established, we tear down the IPv4 TCP connection and signal the > > IPv6 > > > one. > > > > This of course is not acceptable. In RFC 5036 compliant > > > implementations, > > > > when a new adjacency comes up to the same LSR-ID, we just > associate > > it > > > > with the existing TCP connection which was bootstrapped by the > first > > > Hello > > > > adjacency. > > > > > > > > > > > > > > > > Mustapha. > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Dutta, Pranjal K (Pranjal) > > > > Sent: Friday, March 02, 2012 1:22 PM > > > > To: Vishwas Manral > > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Viswas, > > > > > > > > We raised one more point earlier on the > > following > > > clause in the > > > > draft. > > > > > > > > > > > > > > > > Section 6.2 > > > > > > > > > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes > > that > > > > if an LSR has a dual-stack interface, which is enabled with > both > > > > IPv4 and IPv6 LDP, then the LSR must periodically send both > IPv4 > > > and > > > > IPv6 LDP Link Hellos and must separately maintain the Hello > > > > adjacency for IPv4 and IPv6 on that interface. > > > > > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > > > forwarding on a dual-stacked interface, as well as successful > > LDP > > > > peering using the appropriate transport on a multi-access > > > > interface (even if there are IPv4-only, IPv6-only and > > dual-stack > > > > LSRs connected to that multi-access interface). > > > > > > > > > > > > The draft mandates that two separate hello adjacencies should be > > > > maintained on dual-stack - one for IPV4 and another for IPV6. We > > don't > > > see > > > > any benefit or technical reason of running two separate > adjacencies. > > > > > > > > 1. First of all, doing so does not provide > fate > > > separation any way. > > > > Both IPV4 and IPV6 fecs are still exchanged over same LDP > sessions. > > > > > > > > 2. This clause mandates that a transit network > > > that is carrying IPV6 > > > > LSPs must provision IPv6 interfaces. It is not mandatory that the > > > transport > > > > network itself be IPV6 in order to carry IPV6 traffic over its > > > tunnels. This is a > > > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > > > necessary > > > > that an IPV6 FEC should be resolved by an IPV6 only route > next-hop. > > > The > > > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > > > still be > > > > resolved by an IPV4 route next-hop. It's not necessary that source > > of > > > hellos > > > > be IPv6 or transport address of TCP session be ipv6. > > > > > > > > 3. This clause has unnecessary scalability > > > implications. We do run > > > > very large number of LDP adjacencies/sessions (e.g 10K) in > mobility > > > > backhauls or similar deployments. This clause requires to run 20K > > > hello > > > > adjacencies which has scalability implications. On theory there > may > > > not much > > > > difference between 10K and 20K but in real implementations there > is. > > > If we > > > > allow separation of sessions for fate separation of IPV4 and IPV6 > > then > > > it > > > > would become 40K adjacencies. > > > > > > > > We can limit to only one hello adjacency per interface yet address > > the > > > dual > > > > stack issue. A graceful solution is to come up with a notion of > LDP > > > adjacency > > > > specific capabilities (similar to LDP capabilities that applies to > > > entire sessions) > > > > that would benefit multiple purposes. For example, we have > multiple > > > ECMP > > > > Links between neighboring LSRs A and B as shows below. > > > > > > > > > > > +----------------L1------------------+ > > > > | > > > | > > > > A > > > ----------------L2----------------- B > > > > | > > > | > > > > > > > +----------------L3------------------+ > > > > > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are > > using > > > either > > > > IPV4 OR ipv6 addresses but not both. > > > > > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). > > L2 > > > > and L3 are IPv6 capable. > > > > > > > > Then hellos exchanged over link would advertise capabilities as > > below: > > > > > > > > L1 would carry capabilities - Ipv4 + Mcast > > > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > > > > > > > From an implementer/system designer's point of view I would think > > > single > > > > hello adjacency with per adjacency capabilities would be right > > > approach. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > > Sent: Wednesday, February 29, 2012 5:11 PM > > > > To: Dutta, Pranjal K (Pranjal) > > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > > > > > So the two main comments that have come after last call are: > > > > > > > > 1. Allow for separation of sessions along with the adjacency. > > > > 2. Allow for an IPv6 based LSR-ID. > > > > > > > > The second could lead to changes required in both OSPF and IS-IS, > as > > > well > > > > because the new LSR ID would then need to be exchanged. We could > > treat > > > it > > > > as an enhancement instead in my view. Do you agree? > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > > wrote: > > > > > > > > Yes, I support that too. There would be network management issues > > with > > > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > > > > > Most of the implementations I know off usually maps 4 byte of the > > > LSR-ID > > > > with a local ipv4 interface address in the system. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > Sent: Wednesday, February 29, 2012 4:57 PM > > > > To: Aissaoui, Mustapha (Mustapha) > > > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); > > vishwas.ietf@gmail.com > > > > > > > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > > > > > > > > > Hi Mustapha, > > > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as > I > > > pointed out > > > > in my first email. > > > > > > > > Thanks > > > > Lizhong > > > > > > > > > > > > "Aissaoui, Mustapha (Mustapha)" > > lucent.com> > > > > wrote 2012/03/01 04:35:41: > > > > > > > > > Hi Lizhong, > > > > > I actually think that we would need to define a new one which > will > > > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP > sessions > > in > > > > > a all-IPv6 network will not be possible. I cannot see that > > operators > > > > > will start maintaining a mapping of some global non routable > > LSR-id > > > > > value to an IPv6 loopback interface on each router in the > network. > > > > > > > > > > Mustapha. > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > > Of > > > > > Aissaoui, Mustapha (Mustapha) > > > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); > > vishwas.ietf@gmail.com > > > > > Cc: mpls@ietf.org > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > Lizhong, > > > > > the existing LSR-id will do the job and should be supported > since > > > > > the LSR-id need not be an IP address. Most implementations will > > > > > actually populate the field with a /32 address in IPv4 and thus > If > > > > > necessary we could define a new format to allow the use of /128 > > > > IPv6addresses. > > > > > > > > > > Mustapha. > > > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > > Sent: Monday, February 06, 2012 10:23 PM > > > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; > Aissaoui, > > > > > Mustapha (Mustapha) > > > > > Cc: mpls@ietf.org > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > Hi, > > > > > I wonder if it is feasible to use LDP capability to advertise > IPv6 > > > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > > > session in dual-stack network. LDP capability is per node > > > > > capability, not per interface capability. But for LDP to choose > > the > > > > > correct downstream session and output interface for each FEC, it > > > > > should also check if the output interface is LDP enabled or not. > > The > > > > > link adjacency could be used to assist such kind of checking. > > > > > > > > > > However, IMO, it is valuable to allow two independent LDP > sessions > > > > > for IPv4 and IPv6 as an option. Regarding the format definition > in > > > > > RFC5036, we may need new LDP version number to identify IPv6 > > LSR-ID. > > > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I > prefer > > > > > new format of LSR-ID. > > > > > > > > > > Regards > > > > > Lizhong > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > Message: 1 > > > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > > > > > To: Vishwas Manral > > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > > , "mpls@ietf.org" > > > > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Message-ID: > > > > > > > > > > > > > > > > > > > > > alcatel-lucent.com> > > > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > > > I would rather for complete separation with multiple lsr-id > > > because > > > > > > having separate link adjacencies does not really solved any > > > problem. > > > > > > Since hello adjacencies are associated with a link, still fate > > > > > > sharing would continue over the single ldp/tcp session for > IPV4 > > > and IPV6. > > > > > > Having IPV4 and IPV6 specific hello adjacencies over a link > > would > > > > > > only decide whether such a link is to be programmed for IPV4 > or > > > IPV6 > > > > > > egress traffic but I see it as overkill and unnecessary > > > scalability impacts. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in > this > > > > > mail is solely property of the sender's organization. This mail > > > > > communication is confidential. Recipients named above are > > obligated > > > > > to maintain secrecy and are not permitted to disclose the > contents > > > > > of this communication to others. > > > > > This email and any files transmitted with it are confidential > and > > > > > intended solely for the use of the individual or entity to whom > > they > > > > > are addressed. If you have received this email in error please > > > > > notify the originator of the message. Any views expressed in > this > > > > > message are those of the individual sender. > > > > > This message has been scanned for viruses and Spam by ZTE > > Anti-Spam > > > > system. > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 10:13:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4C021F8789 for ; Mon, 12 Mar 2012 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9vbMg1ukMFG for ; Mon, 12 Mar 2012 10:13:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8A54621F877F for ; Mon, 12 Mar 2012 10:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=8752; q=dns/txt; s=iport; t=1331572420; x=1332782020; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+HK1Fam/HNwe9ThYYFOfk+Z4IFsgU85VZma1aCaP8Qs=; b=ldjt6FcTbNYlWwrA4N717iSlTqfagXVDhGMZPPKqXPLGoEAFf+1cFKqR tLqkgUJ4ahAmKQha8gft+plRPKulmsUVxT1HTk6svJPVL4NTLNMPCJ5JI sGyRrTu0ISPM4QvM5d//JFET8n3ewLJF18YV1dfee3ABT9aPzcM6Typlp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMYtXk+tJV2Y/2dsb2JhbABDtVeBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah2MFC50wAZ5nBJAeYwSIVJ0bgwE X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="65743573" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 17:13:40 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHDduV009914; Mon, 12 Mar 2012 17:13:39 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:13:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 12:13:38 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrA References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" X-OriginalArrivalTime: 12 Mar 2012 17:13:39.0869 (UTC) FILETIME=[7808BCD0:01CD0073] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:13:42 -0000 Pranjal, > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. It can't be, because it will break interoperability. This calls for normative behavior. > We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. Thanks for sharing the implementation details.=20 I followed the first part (and agreed), but I didn't follow the 2nd part (i.e. multiple LSRs can hellos with same source ip address), but it sounded incorrect. > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. I will shy away from the above circular logic. :-) Nonetheless, different LSR-IDs is one way to get to multi-session LDP. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:30 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > There are more subtleties involved when we talk on real implementation. >=20 > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:24 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Shane, Pranjal, >=20 > Let's make sure that we don't have any disconnect here at least on the > technicalities here (ignoring the draft discussion for a minute) >=20 > Shane's Q is whether either v4 or v6 hello could help to establish v4 > and/or v6 LDP session. > While Pranjal's assertion is correct on its own, it doesn't quite answer > the subtlety in Shane's Q. >=20 > Shane's Q: > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? >=20 > Not really. Using v4 hello MUST not lead to using v6 transport and v6 > LDP session. That would be a fundamentally wrong approach. >=20 > As Pranjal said, v4 hello usage must lead to v4 session establishment, > whereas v6 hello usage must lead to v6 session establishment. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Tuesday, March 06, 2012 1:28 PM > > To: Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > Yes, that's correct. We can run either ipv4 hellos or ipv6 > hellos and > > operator can choose whichever is best, based upon the operational > needs. > > Since the src ip addresses used by hello packets are not coupled with > FEC > > types so single hello can advertise various FEC capabilities. > > > > If we run multiple ldp sessions between peering systems for > fate > > separation of ipv4 and ipv6 then there can be two separate hello > adjacencies > > over a single interface (each one associated with separate sessions) > but in > > that case the LSR-IDS used would be different (we need to work for an > > extension of RFC 5036). > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Monday, March 05, 2012 10:13 PM > > To: Dutta, Pranjal K (Pranjal) > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > > mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Pranjal, > > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > > Hi Shane, > > > Yes, two separate LDP sessions are required for fate > separation of ipv4 > > and ipv6 fecs. > > > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > > satisfy > > > a) and b). Both can be achieved with single hello adjacency per > > > interface per peering lsr-id with adjacency specific capabilities. > > > > I'm in agreement with you with respect to LDP sessions. > > > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? > > > > -shane > > > > > > > > > Thanks, > > > Pranjal > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of Shane Amante > > > Sent: Friday, March 02, 2012 11:34 PM > > > To: mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mark, > > > > > > I completely agree with all of your comments below. I too would > (strongly) > > prefer the option to allow operators to choose (via CLI) whether to: > > > a) use separate transport to ensure there is no fate-sharing of IPv4 > + > > > IPv6; or, > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, > other > > AF's) on a single session, for scale reasons. > > > > > > -shane > > > > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > > >> (Pranjal) wrote: > > >> > > >>>> From an implementer/system designer's point of view I would think > > >>>> single hello adjacency with per adjacency capabilities would be > > >>>> right approach. > > >> > > >> Pranjal, I appreciate that from a vendor perspective, implementing > it > > >> this way would make sense for large scale deployments. > > >> > > >> However, for some operators who may be using BGP or RSVP to signal > or > > >> nest a large number of LSP's, we would like to have the option of > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for > LDP. > > >> > > >> If there are operators who aren't going to be looking at scaling > that > > >> many LSP's anytime in their network, they might still prefer to > > >> eliminate adjacency fate-sharing. > > >> > > >> I would propose that vendors implement both options, allowing > > >> operators to choose (via CLI) which method they would like to > deploy > > >> in the field. There are many operators out there who maintain > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's > to > > >> protect themselves against the problems fate-sharing could bring. > > >> This is why some of us prefer to make our lives harder by going > > >> native, dual-stack rather than 6PE :-). > > >> > > >> So while I won't disagree with your opinion on using a single > > >> adjacency for both AF's for scaling purposes, I would certainly > like > > >> to have the option to choose which method suits me best in the > wild. > > >> > > >> Mark. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:15:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089ED21F884D for ; Mon, 12 Mar 2012 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwvRaDKLM-9k for ; Mon, 12 Mar 2012 10:15:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3A36521F8844 for ; Mon, 12 Mar 2012 10:15:20 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2CHF7d0008055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:15:10 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHF6Fj028437 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:45:06 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 12 Mar 2012 22:45:05 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Aissaoui, Mustapha (Mustapha)" , Vishwas Manral Date: Mon, 12 Mar 2012 22:45:03 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz3SDdL3rCYESP9QwuVphHpOqkMlgBUVuVQAAPz9dAAAGjOMAHsdIZAAAPgOeAAACEQQAAAZQJAAABwCxAAACPJAAAAUOVQAAAemAA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><5DF53972F7E9134782DCE51624466FE50AD58117BB@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C079FA0CB@XMB-RCD-111.cisco.com><067E6CE33034954AAC05C9EC85E2577C079FA19C@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA1CF@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA1F9@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA1F9@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:15:22 -0000 Rajiv, What do you mean????? There is a complete disconnect. I have asked = an explicit question - "What makes it mandatory (MUST) to have two separate= hello adjacencies when there is no real fate separation?" I haven't still = got the answer from you. Is this a mandatory requirement for IPV6 FEC next-= hop resolution or FEC advertisement? Please justify with technical reasons= (only). Cheers, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 10:06 AM To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas Manr= al Cc: mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Thanks. Perhaps, you meant to point to another section, since that doesn't say anything about what you asked: > > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 > FECs by upstream towards downstream. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:56 PM > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > Rajeev, > Refer to following: > > "Section 6.1 > > 3. An LSR MUST send separate Hellos (each containing either IPv4 > or IPv6 transport address optional object) for each IP address- > family, if LDP was enabled for both IP address-families." > > Cheers, > Pranjal > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 9:51 AM > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > Cc: mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > > Could you please point to the relevant section in the ldp-ipv6 draft? > > Cheers, > Rajiv > > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:38 PM > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Not only that. IPV6 FEC advertisement + next-hop resolution of IPV6 > FECs by > > upstream towards downstream. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Monday, March 12, 2012 9:28 AM > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > Cc: mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, > > > > > on technical reasons on why it is MUST to have hello adjacency over > > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > When you say set-up IPv6 FECs, you mean IPv6 FEC advertisement? > > > > Cheers, > > Rajiv > > > > > > > > > -----Original Message----- > > > From: Dutta, Pranjal K (Pranjal) > > [mailto:pranjal.dutta@alcatel-lucent.com] > > > Sent: Monday, March 12, 2012 12:25 PM > > > To: Rajiv Asati (rajiva); Aissaoui, Mustapha (Mustapha); Vishwas > > Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajeev, > > > We are not discussing about text rephrasing here and have > been > > raising > > > technical issues. Could you please respond on my earlier mail > > > on technical reasons on why it is MUST to have hello adjacency over > > > both IPV4 and IPV6 in order to be able to set-up IPV6 FECs? > > > > > > Cheers, > > > Pranjal > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Rajiv Asati (rajiva) > > > Sent: Monday, March 12, 2012 7:33 AM > > > To: Dutta, Pranjal K (Pranjal); Aissaoui, Mustapha (Mustapha); > Vishwas > > > Manral > > > Cc: mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Pranjal, > > > > > > Certainly. That would be a sub-optimal protocol design, let alone > the > > > subsequent implementations. > > > Thankfully, that's not what is prescribed. > > > > > > May I request you to review the verbiage a bit carefully? > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Dutta, Pranjal K (Pranjal) > > > > Sent: Friday, March 02, 2012 2:37 PM > > > > To: Aissaoui, Mustapha (Mustapha); Vishwas Manral > > > > Cc: mpls@ietf.org; Lizhong Jin > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Yes, this approach would lead to all "kludgy" implementations. Due > > to > > > race > > > > conditions between UDP based LDP hellos and TCP connections (since > > > they > > > > are independent channels) it may lead to states of continually > > > flapping > > > > sessions. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Aissaoui, Mustapha (Mustapha) > > > > Sent: Friday, March 02, 2012 11:26 AM > > > > To: Dutta, Pranjal K (Pranjal); Vishwas Manral > > > > Cc: Lizhong Jin; mpls@ietf.org > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > I also have an issue with the stability of such an implementation. > > The > > > draft > > > > suggests in Section 6.1 - Transport connection establishment, that > a > > > TCP > > > > connection with IPv6 should be preferred to one with IPv4 if both > > IPv4 > > > and > > > > IPv6 adjacencies exist. This means that if the IPv4 adjacency came > > up > > > first > > > > and boot straps the IPv4 TCP connection, as soon as the IPv6 hello > > is > > > > established, we tear down the IPv4 TCP connection and signal the > > IPv6 > > > one. > > > > This of course is not acceptable. In RFC 5036 compliant > > > implementations, > > > > when a new adjacency comes up to the same LSR-ID, we just > associate > > it > > > > with the existing TCP connection which was bootstrapped by the > first > > > Hello > > > > adjacency. > > > > > > > > > > > > > > > > Mustapha. > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Dutta, Pranjal K (Pranjal) > > > > Sent: Friday, March 02, 2012 1:22 PM > > > > To: Vishwas Manral > > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Viswas, > > > > > > > > We raised one more point earlier on the > > following > > > clause in the > > > > draft. > > > > > > > > > > > > > > > > Section 6.2 > > > > > > > > > > > > > > > > As outlined in section 2.5.5 of RFC5036, this draft describes > > that > > > > if an LSR has a dual-stack interface, which is enabled with > both > > > > IPv4 and IPv6 LDP, then the LSR must periodically send both > IPv4 > > > and > > > > IPv6 LDP Link Hellos and must separately maintain the Hello > > > > adjacency for IPv4 and IPv6 on that interface. > > > > > > > > This ensures successful labeled IPv4 and labeled IPv6 traffic > > > > forwarding on a dual-stacked interface, as well as successful > > LDP > > > > peering using the appropriate transport on a multi-access > > > > interface (even if there are IPv4-only, IPv6-only and > > dual-stack > > > > LSRs connected to that multi-access interface). > > > > > > > > > > > > The draft mandates that two separate hello adjacencies should be > > > > maintained on dual-stack - one for IPV4 and another for IPV6. We > > don't > > > see > > > > any benefit or technical reason of running two separate > adjacencies. > > > > > > > > 1. First of all, doing so does not provide > fate > > > separation any way. > > > > Both IPV4 and IPV6 fecs are still exchanged over same LDP > sessions. > > > > > > > > 2. This clause mandates that a transit network > > > that is carrying IPV6 > > > > LSPs must provision IPv6 interfaces. It is not mandatory that the > > > transport > > > > network itself be IPV6 in order to carry IPV6 traffic over its > > > tunnels. This is a > > > > very narrow interpretation of section 2.5.5 in RFC 5036. It's not > > > necessary > > > > that an IPV6 FEC should be resolved by an IPV6 only route > next-hop. > > > The > > > > hello adjacency can still be over an IPV4 link and IPV6 prefix can > > > still be > > > > resolved by an IPV4 route next-hop. It's not necessary that source > > of > > > hellos > > > > be IPv6 or transport address of TCP session be ipv6. > > > > > > > > 3. This clause has unnecessary scalability > > > implications. We do run > > > > very large number of LDP adjacencies/sessions (e.g 10K) in > mobility > > > > backhauls or similar deployments. This clause requires to run 20K > > > hello > > > > adjacencies which has scalability implications. On theory there > may > > > not much > > > > difference between 10K and 20K but in real implementations there > is. > > > If we > > > > allow separation of sessions for fate separation of IPV4 and IPV6 > > then > > > it > > > > would become 40K adjacencies. > > > > > > > > We can limit to only one hello adjacency per interface yet address > > the > > > dual > > > > stack issue. A graceful solution is to come up with a notion of > LDP > > > adjacency > > > > specific capabilities (similar to LDP capabilities that applies to > > > entire sessions) > > > > that would benefit multiple purposes. For example, we have > multiple > > > ECMP > > > > Links between neighboring LSRs A and B as shows below. > > > > > > > > > > > +----------------L1------------------+ > > > > | > > > | > > > > A > > > ----------------L2----------------- B > > > > | > > > | > > > > > > > +----------------L3------------------+ > > > > > > > > The hello adjacencies over L1, L2 and L3 are IP4 interfaces are > > using > > > either > > > > IPV4 OR ipv6 addresses but not both. > > > > > > > > Link L1, L2 are multicast capable (P2MP or MP2MP_UP or MP2MP_DN). > > L2 > > > > and L3 are IPv6 capable. > > > > > > > > Then hellos exchanged over link would advertise capabilities as > > below: > > > > > > > > L1 would carry capabilities - Ipv4 + Mcast > > > > L2 would carry capabilities - ipv4 + ipv6 + Mcast > > > > L3 would carry capabilities - ipv4 + ipv6 > > > > > > > > > > > > From an implementer/system designer's point of view I would think > > > single > > > > hello adjacency with per adjacency capabilities would be right > > > approach. > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > > Sent: Wednesday, February 29, 2012 5:11 PM > > > > To: Dutta, Pranjal K (Pranjal) > > > > Cc: Lizhong Jin; Aissaoui, Mustapha (Mustapha); mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > Hi Lizhong/ Pranjal/ Mustapha, > > > > > > > > So the two main comments that have come after last call are: > > > > > > > > 1. Allow for separation of sessions along with the adjacency. > > > > 2. Allow for an IPv6 based LSR-ID. > > > > > > > > The second could lead to changes required in both OSPF and IS-IS, > as > > > well > > > > because the new LSR ID would then need to be exchanged. We could > > treat > > > it > > > > as an enhancement instead in my view. Do you agree? > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > On Wed, Feb 29, 2012 at 5:03 PM, Dutta, Pranjal K (Pranjal) > > > > wrote: > > > > > > > > Yes, I support that too. There would be network management issues > > with > > > > mapping of 4 byte LSR-ID to an IPV6 remote address. > > > > > > > > Most of the implementations I know off usually maps 4 byte of the > > > LSR-ID > > > > with a local ipv4 interface address in the system. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Pranjal > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > Sent: Wednesday, February 29, 2012 4:57 PM > > > > To: Aissaoui, Mustapha (Mustapha) > > > > Cc: mpls@ietf.org; Dutta, Pranjal K (Pranjal); > > vishwas.ietf@gmail.com > > > > > > > > > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > > > > > > > > > > > Hi Mustapha, > > > > I agree, and I also prefer to defining a IPv6 formated LSR-ID, as > I > > > pointed out > > > > in my first email. > > > > > > > > Thanks > > > > Lizhong > > > > > > > > > > > > "Aissaoui, Mustapha (Mustapha)" > > lucent.com> > > > > wrote 2012/03/01 04:35:41: > > > > > > > > > Hi Lizhong, > > > > > I actually think that we would need to define a new one which > will > > > > > accomodate an IPv6 /128 address. Otherwise, targeted LDP > sessions > > in > > > > > a all-IPv6 network will not be possible. I cannot see that > > operators > > > > > will start maintaining a mapping of some global non routable > > LSR-id > > > > > value to an IPv6 loopback interface on each router in the > network. > > > > > > > > > > Mustapha. > > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > Behalf > > > > Of > > > > > Aissaoui, Mustapha (Mustapha) > > > > > Sent: Tuesday, February 07, 2012 10:12 AM > > > > > To: Lizhong Jin; Dutta, Pranjal K (Pranjal); > > vishwas.ietf@gmail.com > > > > > Cc: mpls@ietf.org > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > Lizhong, > > > > > the existing LSR-id will do the job and should be supported > since > > > > > the LSR-id need not be an IP address. Most implementations will > > > > > actually populate the field with a /32 address in IPv4 and thus > If > > > > > necessary we could define a new format to allow the use of /128 > > > > IPv6addresses. > > > > > > > > > > Mustapha. > > > > > > > > > > From: Lizhong Jin [mailto:lizhong.jin@zte.com.cn] > > > > > Sent: Monday, February 06, 2012 10:23 PM > > > > > To: Dutta, Pranjal K (Pranjal); vishwas.ietf@gmail.com; > Aissaoui, > > > > > Mustapha (Mustapha) > > > > > Cc: mpls@ietf.org > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > > > > > Hi, > > > > > I wonder if it is feasible to use LDP capability to advertise > IPv6 > > > > > FEC without IPv6 adjacency, and only use one adjacency for LDP > > > > > session in dual-stack network. LDP capability is per node > > > > > capability, not per interface capability. But for LDP to choose > > the > > > > > correct downstream session and output interface for each FEC, it > > > > > should also check if the output interface is LDP enabled or not. > > The > > > > > link adjacency could be used to assist such kind of checking. > > > > > > > > > > However, IMO, it is valuable to allow two independent LDP > sessions > > > > > for IPv4 and IPv6 as an option. Regarding the format definition > in > > > > > RFC5036, we may need new LDP version number to identify IPv6 > > LSR-ID. > > > > > Or we use different 32bit LSR-ID for IPv6 with IPv4, but I > prefer > > > > > new format of LSR-ID. > > > > > > > > > > Regards > > > > > Lizhong > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > Message: 1 > > > > > > Date: Tue, 7 Feb 2012 05:28:21 +0530 > > > > > > From: "Dutta, Pranjal K (Pranjal)" > > > > > > > > > To: Vishwas Manral > > > > > > Cc: "Aissaoui, Mustapha \(Mustapha\)" > > > > > > , "mpls@ietf.org" > > > > > > > > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Message-ID: > > > > > > > > > > > > > > > > > > > > > alcatel-lucent.com> > > > > > > > > > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > > > > > > > > > I would rather for complete separation with multiple lsr-id > > > because > > > > > > having separate link adjacencies does not really solved any > > > problem. > > > > > > Since hello adjacencies are associated with a link, still fate > > > > > > sharing would continue over the single ldp/tcp session for > IPV4 > > > and IPV6. > > > > > > Having IPV4 and IPV6 specific hello adjacencies over a link > > would > > > > > > only decide whether such a link is to be programmed for IPV4 > or > > > IPV6 > > > > > > egress traffic but I see it as overkill and unnecessary > > > scalability impacts. > > > > > > > > > > > > Thanks, > > > > > > Pranjal > > > > > > > > > > > -------------------------------------------------------- > > > > > ZTE Information Security Notice: The information contained in > this > > > > > mail is solely property of the sender's organization. This mail > > > > > communication is confidential. Recipients named above are > > obligated > > > > > to maintain secrecy and are not permitted to disclose the > contents > > > > > of this communication to others. > > > > > This email and any files transmitted with it are confidential > and > > > > > intended solely for the use of the individual or entity to whom > > they > > > > > are addressed. If you have received this email in error please > > > > > notify the originator of the message. Any views expressed in > this > > > > > message are those of the individual sender. > > > > > This message has been scanned for viruses and Spam by ZTE > > Anti-Spam > > > > system. > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:17:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030F21F8895 for ; Mon, 12 Mar 2012 10:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.281 X-Spam-Level: X-Spam-Status: No, score=-7.281 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3UYFLGoO5W6 for ; Mon, 12 Mar 2012 10:17:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id ED5D521F888F for ; Mon, 12 Mar 2012 10:17:06 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2CHGntR015970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:16:51 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHGnTw003365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:46:49 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 12 Mar 2012 22:46:48 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante Date: Mon, 12 Mar 2012 22:46:46 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABXMzA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:17:08 -0000 "It can't be, because it will break interoperability. This calls for normative behavior." Reference Please? -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Monday, March 12, 2012 10:14 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. It can't be, because it will break interoperability. This calls for normative behavior. > We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. Thanks for sharing the implementation details.=20 I followed the first part (and agreed), but I didn't follow the 2nd part (i.e. multiple LSRs can hellos with same source ip address), but it sounded incorrect. > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. I will shy away from the above circular logic. :-) Nonetheless, different LSR-IDs is one way to get to multi-session LDP. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:30 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > There are more subtleties involved when we talk on real implementation. >=20 > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. >=20 > Thanks, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:24 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Shane, Pranjal, >=20 > Let's make sure that we don't have any disconnect here at least on the > technicalities here (ignoring the draft discussion for a minute) >=20 > Shane's Q is whether either v4 or v6 hello could help to establish v4 > and/or v6 LDP session. > While Pranjal's assertion is correct on its own, it doesn't quite answer > the subtlety in Shane's Q. >=20 > Shane's Q: > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? >=20 > Not really. Using v4 hello MUST not lead to using v6 transport and v6 > LDP session. That would be a fundamentally wrong approach. >=20 > As Pranjal said, v4 hello usage must lead to v4 session establishment, > whereas v6 hello usage must lead to v6 session establishment. >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Tuesday, March 06, 2012 1:28 PM > > To: Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > Yes, that's correct. We can run either ipv4 hellos or ipv6 > hellos and > > operator can choose whichever is best, based upon the operational > needs. > > Since the src ip addresses used by hello packets are not coupled with > FEC > > types so single hello can advertise various FEC capabilities. > > > > If we run multiple ldp sessions between peering systems for > fate > > separation of ipv4 and ipv6 then there can be two separate hello > adjacencies > > over a single interface (each one associated with separate sessions) > but in > > that case the LSR-IDS used would be different (we need to work for an > > extension of RFC 5036). > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Monday, March 05, 2012 10:13 PM > > To: Dutta, Pranjal K (Pranjal) > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > > mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Pranjal, > > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > > Hi Shane, > > > Yes, two separate LDP sessions are required for fate > separation of ipv4 > > and ipv6 fecs. > > > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > > satisfy > > > a) and b). Both can be achieved with single hello adjacency per > > > interface per peering lsr-id with adjacency specific capabilities. > > > > I'm in agreement with you with respect to LDP sessions. > > > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? > > > > -shane > > > > > > > > > Thanks, > > > Pranjal > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of Shane Amante > > > Sent: Friday, March 02, 2012 11:34 PM > > > To: mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mark, > > > > > > I completely agree with all of your comments below. I too would > (strongly) > > prefer the option to allow operators to choose (via CLI) whether to: > > > a) use separate transport to ensure there is no fate-sharing of IPv4 > + > > > IPv6; or, > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, > other > > AF's) on a single session, for scale reasons. > > > > > > -shane > > > > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > > >> (Pranjal) wrote: > > >> > > >>>> From an implementer/system designer's point of view I would think > > >>>> single hello adjacency with per adjacency capabilities would be > > >>>> right approach. > > >> > > >> Pranjal, I appreciate that from a vendor perspective, implementing > it > > >> this way would make sense for large scale deployments. > > >> > > >> However, for some operators who may be using BGP or RSVP to signal > or > > >> nest a large number of LSP's, we would like to have the option of > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for > LDP. > > >> > > >> If there are operators who aren't going to be looking at scaling > that > > >> many LSP's anytime in their network, they might still prefer to > > >> eliminate adjacency fate-sharing. > > >> > > >> I would propose that vendors implement both options, allowing > > >> operators to choose (via CLI) which method they would like to > deploy > > >> in the field. There are many operators out there who maintain > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's > to > > >> protect themselves against the problems fate-sharing could bring. > > >> This is why some of us prefer to make our lives harder by going > > >> native, dual-stack rather than 6PE :-). > > >> > > >> So while I won't disagree with your opinion on using a single > > >> adjacency for both AF's for scaling purposes, I would certainly > like > > >> to have the option to choose which method suits me best in the > wild. > > >> > > >> Mark. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:21:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9A21F88A7 for ; Mon, 12 Mar 2012 10:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.261 X-Spam-Level: X-Spam-Status: No, score=-7.261 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJAfKUstpVSd for ; Mon, 12 Mar 2012 10:21:19 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B02C021F888E for ; Mon, 12 Mar 2012 10:21:18 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2CHKwub013027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:21:01 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHKwDh003502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:50:58 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 12 Mar 2012 22:50:57 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante Date: Mon, 12 Mar 2012 22:50:55 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABwTTA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E09F01843E8INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:21:21 -0000 --_000_C584046466ED224CA92C1BC3313B963E09F01843E8INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rajiv, "I will shy away from the above circular logic. :-) Nonetheless, different = LSR-IDs is one way to get to multi-session LDP." I don't see any circular logic. You seemed to be quite confused between LDP= hello adjacencies, its intent and LDP sessions. Cheers, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 10:14 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. It can't be, because it will break interoperability. This calls for normative behavior. > We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. Thanks for sharing the implementation details. I followed the first part (and agreed), but I didn't follow the 2nd part (i.e. multiple LSRs can hellos with same source ip address), but it sounded incorrect. > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. I will shy away from the above circular logic. :-) Nonetheless, different LSR-IDs is one way to get to multi-session LDP. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:30 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > There are more subtleties involved when we talk on real implementation. > > If order to have fate separation between IPV4 and IPV6, we need separation > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been different, > so obviously it would lead to two separate LDP sessions. > Howevever whether both an implementation wants to send hellos for both > adjacencies on a same interface (either ipv4 or ipv6) or different > interfaces is implementation specific. We send hellos over an interface > as intent of a LSR to include that interface for traffic and multiple > LSRs can hellos with same source ip address. > > Thanks, > Pranjal > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:24 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Shane, Pranjal, > > Let's make sure that we don't have any disconnect here at least on the > technicalities here (ignoring the draft discussion for a minute) > > Shane's Q is whether either v4 or v6 hello could help to establish v4 > and/or v6 LDP session. > While Pranjal's assertion is correct on its own, it doesn't quite answer > the subtlety in Shane's Q. > > Shane's Q: > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? > > Not really. Using v4 hello MUST not lead to using v6 transport and v6 > LDP session. That would be a fundamentally wrong approach. > > As Pranjal said, v4 hello usage must lead to v4 session establishment, > whereas v6 hello usage must lead to v6 session establishment. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Dutta, Pranjal K (Pranjal) > > Sent: Tuesday, March 06, 2012 1:28 PM > > To: Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > Yes, that's correct. We can run either ipv4 hellos or ipv6 > hellos and > > operator can choose whichever is best, based upon the operational > needs. > > Since the src ip addresses used by hello packets are not coupled with > FEC > > types so single hello can advertise various FEC capabilities. > > > > If we run multiple ldp sessions between peering systems for > fate > > separation of ipv4 and ipv6 then there can be two separate hello > adjacencies > > over a single interface (each one associated with separate sessions) > but in > > that case the LSR-IDS used would be different (we need to work for an > > extension of RFC 5036). > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Monday, March 05, 2012 10:13 PM > > To: Dutta, Pranjal K (Pranjal) > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > > mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Pranjal, > > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > > Hi Shane, > > > Yes, two separate LDP sessions are required for fate > separation of ipv4 > > and ipv6 fecs. > > > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > > satisfy > > > a) and b). Both can be achieved with single hello adjacency per > > > interface per peering lsr-id with adjacency specific capabilities. > > > > I'm in agreement with you with respect to LDP sessions. > > > > With respect to LDP Hellos, you're suggesting that operators run > either IPv4- > > only Hello's or IPv6-only Hello's, (never both at the same time), but > through > > either one can discover the "(IPv4|IPv6) transport capabilities" of a > LDP peer > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > Correct? > > > > -shane > > > > > > > > > Thanks, > > > Pranjal > > > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > > Of Shane Amante > > > Sent: Friday, March 02, 2012 11:34 PM > > > To: mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mark, > > > > > > I completely agree with all of your comments below. I too would > (strongly) > > prefer the option to allow operators to choose (via CLI) whether to: > > > a) use separate transport to ensure there is no fate-sharing of IPv4 > + > > > IPv6; or, > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 (or, > other > > AF's) on a single session, for scale reasons. > > > > > > -shane > > > > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > > >> (Pranjal) wrote: > > >> > > >>>> From an implementer/system designer's point of view I would think > > >>>> single hello adjacency with per adjacency capabilities would be > > >>>> right approach. > > >> > > >> Pranjal, I appreciate that from a vendor perspective, implementing > it > > >> this way would make sense for large scale deployments. > > >> > > >> However, for some operators who may be using BGP or RSVP to signal > or > > >> nest a large number of LSP's, we would like to have the option of > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for > LDP. > > >> > > >> If there are operators who aren't going to be looking at scaling > that > > >> many LSP's anytime in their network, they might still prefer to > > >> eliminate adjacency fate-sharing. > > >> > > >> I would propose that vendors implement both options, allowing > > >> operators to choose (via CLI) which method they would like to > deploy > > >> in the field. There are many operators out there who maintain > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's > to > > >> protect themselves against the problems fate-sharing could bring. > > >> This is why some of us prefer to make our lives harder by going > > >> native, dual-stack rather than 6PE :-). > > >> > > >> So while I won't disagree with your opinion on using a single > > >> adjacency for both AF's for scaling purposes, I would certainly > like > > >> to have the option to choose which method suits me best in the > wild. > > >> > > >> Mark. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_000_C584046466ED224CA92C1BC3313B963E09F01843E8INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Rajiv,

 

"I will shy away from the above circular lo= gic. :-) Nonetheless, different LSR-IDs is one way to get to multi-session LDP.&= quot;

 

I don't see any circular logic. You seemed to be quite confused between LDP hello adjacencies, its intent and LDP sessions. =

 

Cheers,

Pranjal

 

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]
Sent: Monday, March 12, 2012 10:14 AM
To: Dutta, Pranjal K (Pranjal)= ; Shane Amante
Cc: Aissaoui, Mustapha (Mustap= ha); mpls@ietf.org; Liz= hong Jin
Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

 

Pranjal,

 

> Howevever whether both an implementation wants to send hellos = for both

> adjacencies on a same interface (either ipv4 or ipv6) or diffe= rent

> interfaces is implementation specific.

 

It can't be, because it will break interoperability. This calls for=

normative behavior.

 

>  We send hellos over an interface

> as intent of a LSR to include that interface for traffic and multiple

> LSRs can hellos with same source ip address.=

 

Thanks for sharing the implementation details.

 

I followed the first part (and agreed), but I didn't follow the 2nd part

(i.e. multiple LSRs can hellos with same source ip address), but it=

sounded incorrect.

 

 

> If order to have fate separation between IPV4 and IPV6, we nee= d

separation

> of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been

different,

> so obviously it would lead to two separate LDP sessions.<= /o:p>

 

I will shy away from the above circular logic. :-)

Nonetheless, different LSR-IDs is one way to get to multi-session L= DP.

 

Cheers,

Rajiv

 

> -----Original Message-----

> From: Dutta, Pranjal K (Pranjal)

[mailto:pranjal.dutta@alcatel-lucent.com]<= /p>

> Sent: Monday, March 12, 2012 12:30 PM=

> To: Rajiv Asati (rajiva); Shane Am= ante

> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin

> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>

> There are more subtleties involved when we talk on real

implementation.

>

> If order to have fate separation between IPV4 and IPV6, we nee= d

separation

> of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been

different,

> so obviously it would lead to two separate LDP sessions.<= /o:p>

> Howevever whether both an implementation wants to send hellos = for both

> adjacencies on a same interface (either ipv4 or ipv6) or diffe= rent

> interfaces is implementation specific. We send hellos over an<= o:p>

interface

> as intent of a LSR to include that interface for traffic and multiple

> LSRs can hellos with same source ip address.=

>

> Thanks,

> Pranjal

>

> -----Original Message-----

> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf

Of

> Rajiv Asati (rajiva)

> Sent: Monday, March 12, 2012 7:24 AM<= /p>

> To: Dutta, Pranjal K (Pranjal); Shane Amante

> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin

> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

>

> Shane, Pranjal,

>

> Let's make sure that we don't have any disconnect here at leas= t on the

> technicalities here (ignoring the draft discussion for a minut= e)

>

> Shane's Q is whether either v4 or v6 hello could help to estab= lish v4

> and/or v6 LDP session.

> While Pranjal's assertion is correct on its own, it doesn't qu= ite

answer

> the subtlety in Shane's Q.

>

> Shane's Q:

> > With respect to LDP Hellos, you're suggesting that operat= ors run

> either IPv4-

> > only Hello's or IPv6-only Hello's, (never both at the sam= e time),

but

> through

> > either one can discover the "(IPv4|IPv6) transport capabilities" of

a

> LDP peer

> > and, based on that, establish an IPv4 and/or IPv6 LDP session.

> Correct?

>

> Not really. Using v4 hello MUST not lead to using v6 transport= and v6

> LDP session. That would be a fundamentally wrong approach.

>

> As Pranjal said, v4 hello usage must lead to v4 session establishment,

> whereas v6 hello usage must lead to v6 session establishment.<= o:p>

>

> Cheers,

> Rajiv

>

>

> > -----Original Message-----

> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ] On Behalf

> Of

> > Dutta, Pranjal K (Pranjal)

> > Sent: Tuesday, March 06, 2012 1:28 PM

> > To: Shane Amante

> > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-= 06

> >

> > Hi Shane,

> >         &nbs= p; Yes, that's correct. We can run either ipv4 hellos or ipv6

> hellos and

> > operator can choose whichever is best,  based upon t= he operational

> needs.

> > Since the src ip addresses used by hello packets are not coupled

with

> FEC

> > types so single hello can advertise various FEC capabilit= ies.

> >

> >          If = we run multiple ldp sessions between peering systems for

> fate

> > separation of ipv4 and ipv6 then there can be two separat= e hello

> adjacencies

> > over a single interface (each one associated with separat= e sessions)

> but in

> > that case the LSR-IDS used would be different (we need to work for

an

> > extension of RFC 5036).

> >

> > Thanks,

> > Pranjal

> >

> > -----Original Message-----

> > From: Shane Amante [mailto:shane@castlepoint.net]

> > Sent: Monday, March 05, 2012 10:13 PM

> > To: Dutta, Pranjal K (Pranjal)

> > Cc: mtinka@globaltransit.net<= /st1:PersonName>; Aissaoui, Mustapha (Mustapha);=

> > mpls@ietf.org; Lizhong Jin

> > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-= 06

> >

> > Hi Pranjal,

> >

> > On Mar 5, 2012, at 11:44 AM, = Dutta, Pranjal K (Pranjal) wrote:

> > > Hi Shane,

> > >         = ; Yes, two separate LDP sessions are required for fate

> separation of ipv4

> > and ipv6 fecs.

> > >

> > > Separation of ipv4 and ipv6 hello adjacencies are no= t required to

> > > satisfy

> > > a) and b). Both can be achieved with single hello adjacency per

> > > interface per peering lsr-id with adjacency specific capabilities.

> >

> > I'm in agreement with you with respect to LDP sessions.

> >

> > With respect to LDP Hellos, you're suggesting that operat= ors run

> either IPv4-

> > only Hello's or IPv6-only Hello's, (never both at the sam= e time),

but

> through

> > either one can discover the "(IPv4|IPv6) transport capabilities" of

a

> LDP peer

> > and, based on that, establish an IPv4 and/or IPv6 LDP session.

> Correct?

> >

> > -shane

> >

> >

> >

> > > Thanks,

> > > Pranjal

> > >

> > >

> > > -----Original Message-----<= /p>

> > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@iet= f.org] On

Behalf

> > > Of Shane Amante

> > > Sent: Friday, March 02, 2012 11:34 PM

> > > To: mtinka@globaltransit= .net

> > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin

> > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06

> > >

> > > Mark,

> > >

> > > I completely agree with all of your comments below. = I too would

> (strongly)

> > prefer the option to allow operators to choose (via CLI) whether to:

> > > a) use separate transport to ensure there is no fate-sharing of

IPv4

> +

> > > IPv6; or,

> > > b) use a single transport to permit fate-sharing of = IPv4 + IPv6

(or,

> other

> > AF's) on a single session, for scale reasons.<= /span>

> > >

> > > -shane

> > >

> > >

> > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote:<= /o:p>

> > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K

> > >> (Pranjal) wrote:

> > >>

> > >>>> From an implementer/system designer's po= int of view I would

think

> > >>>> single hello adjacency with per adjacenc= y capabilities would be

> > >>>> right approach.=

> > >>

> > >> Pranjal, I appreciate that from a vendor perspective,

implementing

> it

> > >> this way would make sense for large scale deployments.

> > >>

> > >> However, for some operators who may be using BGP= or RSVP to

signal

> or

> > >> nest a large number of LSP's, we would like to h= ave the option of

> > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for

> LDP.

> > >>

> > >> If there are operators who aren't going to be looking at scaling

> that

> > >> many LSP's anytime in their network, they might still prefer to

> > >> eliminate adjacency fate-sharing.

> > >>

> > >> I would propose that vendors implement both opti= ons, allowing

> > >> operators to choose (via CLI) which method they would like to

> deploy

> > >> in the field. There are many operators out there= who maintain

> > >> separate BGP transport and policy sessions for I= Pv4 and IPv6 AF's

> to

> > >> protect themselves against the problems fate-sha= ring could bring.

> > >> This is why some of us prefer to make our lives harder by going

> > >> native, dual-stack rather than 6PE :-).

> > >>

> > >> So while I won't disagree with your opinion on u= sing a single

> > >> adjacency for both AF's for scaling purposes, I would certainly

> like

> > >> to have the option to choose which method suits = me best in the

> wild.

> > >>

> > >> Mark.

> > > _______________________________________________=

> > > mpls mailing list

> > > mpls@ietf.org

> > > https://www.ietf.org/mailman/listinfo/mpls

> >

> > _______________________________________________

> > mpls mailing list

> > mpls@ietf.org

> > https://www.ietf.org/mailman/listinfo/mpls

> _______________________________________________

> mpls mailing list

> mpls@ietf.org

> https://www.ietf.org/mailman/listinfo/mpls

--_000_C584046466ED224CA92C1BC3313B963E09F01843E8INBANSXCHMBSA_-- From rajiva@cisco.com Mon Mar 12 10:24:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25121F875E for ; Mon, 12 Mar 2012 10:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLBIeXAxnOfr for ; Mon, 12 Mar 2012 10:24:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E7C3F21F873E for ; Mon, 12 Mar 2012 10:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=10294; q=dns/txt; s=iport; t=1331573045; x=1332782645; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GnpBPDH6zYnlDrewKpOadzIUqbIpbGxa2TpEquvuEBQ=; b=gjc4qahXQWVT6Rb23jlYQyL1WE1GHvNsZmUs7DcX27SqjVzJf3Oi+bvf Wccic48n+Zq6icVCMo7cjAK6lrLWIXHY2K/KjvWxr9VH/DwG0EgZf1+uJ 4LGzUaAa1Mxi66BOExfjsXdH+qWzfbA1IAyEuU7OpSMbm3GML53db23zR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMgwXk+tJXG+/2dsb2JhbABBtWOBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAgQBEggah2gLn3YBlwUEkB5jBIhUnRuDAQ X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="65740008" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2012 17:24:04 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHNhgo000950; Mon, 12 Mar 2012 17:24:01 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:23:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 12:23:36 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA21F@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABXMzAAACIEQA== References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" X-OriginalArrivalTime: 12 Mar 2012 17:23:37.0361 (UTC) FILETIME=[DC2AC810:01CD0074] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:24:06 -0000 Pranjal, Please consider this scenario -=20 - LSR A's implementation expects both v4 and v6 hellos from LSR B,=20 - LSR B's implementation sends only v4 hello to LSR B That's why we shouldn't make this implementation specific. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:17 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > "It can't be, because it will break interoperability. This calls for > normative behavior." >=20 > Reference Please? >=20 >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:14 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > Howevever whether both an implementation wants to send hellos for both > > adjacencies on a same interface (either ipv4 or ipv6) or different > > interfaces is implementation specific. >=20 > It can't be, because it will break interoperability. This calls for > normative behavior. >=20 > > We send hellos over an interface > > as intent of a LSR to include that interface for traffic and multiple > > LSRs can hellos with same source ip address. >=20 > Thanks for sharing the implementation details. >=20 > I followed the first part (and agreed), but I didn't follow the 2nd part > (i.e. multiple LSRs can hellos with same source ip address), but it > sounded incorrect. >=20 >=20 > > If order to have fate separation between IPV4 and IPV6, we need > separation > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been > different, > > so obviously it would lead to two separate LDP sessions. >=20 > I will shy away from the above circular logic. :-) > Nonetheless, different LSR-IDs is one way to get to multi-session LDP. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:30 PM > > To: Rajiv Asati (rajiva); Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > There are more subtleties involved when we talk on real > implementation. > > > > If order to have fate separation between IPV4 and IPV6, we need > separation > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been > different, > > so obviously it would lead to two separate LDP sessions. > > Howevever whether both an implementation wants to send hellos for both > > adjacencies on a same interface (either ipv4 or ipv6) or different > > interfaces is implementation specific. We send hellos over an > interface > > as intent of a LSR to include that interface for traffic and multiple > > LSRs can hellos with same source ip address. > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:24 AM > > To: Dutta, Pranjal K (Pranjal); Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Shane, Pranjal, > > > > Let's make sure that we don't have any disconnect here at least on the > > technicalities here (ignoring the draft discussion for a minute) > > > > Shane's Q is whether either v4 or v6 hello could help to establish v4 > > and/or v6 LDP session. > > While Pranjal's assertion is correct on its own, it doesn't quite > answer > > the subtlety in Shane's Q. > > > > Shane's Q: > > > With respect to LDP Hellos, you're suggesting that operators run > > either IPv4- > > > only Hello's or IPv6-only Hello's, (never both at the same time), > but > > through > > > either one can discover the "(IPv4|IPv6) transport capabilities" of > a > > LDP peer > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > > Correct? > > > > Not really. Using v4 hello MUST not lead to using v6 transport and v6 > > LDP session. That would be a fundamentally wrong approach. > > > > As Pranjal said, v4 hello usage must lead to v4 session establishment, > > whereas v6 hello usage must lead to v6 session establishment. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Dutta, Pranjal K (Pranjal) > > > Sent: Tuesday, March 06, 2012 1:28 PM > > > To: Shane Amante > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Shane, > > > Yes, that's correct. We can run either ipv4 hellos or ipv6 > > hellos and > > > operator can choose whichever is best, based upon the operational > > needs. > > > Since the src ip addresses used by hello packets are not coupled > with > > FEC > > > types so single hello can advertise various FEC capabilities. > > > > > > If we run multiple ldp sessions between peering systems for > > fate > > > separation of ipv4 and ipv6 then there can be two separate hello > > adjacencies > > > over a single interface (each one associated with separate sessions) > > but in > > > that case the LSR-IDS used would be different (we need to work for > an > > > extension of RFC 5036). > > > > > > Thanks, > > > Pranjal > > > > > > -----Original Message----- > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > Sent: Monday, March 05, 2012 10:13 PM > > > To: Dutta, Pranjal K (Pranjal) > > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > > > mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Pranjal, > > > > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > > > Hi Shane, > > > > Yes, two separate LDP sessions are required for fate > > separation of ipv4 > > > and ipv6 fecs. > > > > > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > > > satisfy > > > > a) and b). Both can be achieved with single hello adjacency per > > > > interface per peering lsr-id with adjacency specific capabilities. > > > > > > I'm in agreement with you with respect to LDP sessions. > > > > > > With respect to LDP Hellos, you're suggesting that operators run > > either IPv4- > > > only Hello's or IPv6-only Hello's, (never both at the same time), > but > > through > > > either one can discover the "(IPv4|IPv6) transport capabilities" of > a > > LDP peer > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > > Correct? > > > > > > -shane > > > > > > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > > Of Shane Amante > > > > Sent: Friday, March 02, 2012 11:34 PM > > > > To: mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Mark, > > > > > > > > I completely agree with all of your comments below. I too would > > (strongly) > > > prefer the option to allow operators to choose (via CLI) whether to: > > > > a) use separate transport to ensure there is no fate-sharing of > IPv4 > > + > > > > IPv6; or, > > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 > (or, > > other > > > AF's) on a single session, for scale reasons. > > > > > > > > -shane > > > > > > > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > > > >> (Pranjal) wrote: > > > >> > > > >>>> From an implementer/system designer's point of view I would > think > > > >>>> single hello adjacency with per adjacency capabilities would be > > > >>>> right approach. > > > >> > > > >> Pranjal, I appreciate that from a vendor perspective, > implementing > > it > > > >> this way would make sense for large scale deployments. > > > >> > > > >> However, for some operators who may be using BGP or RSVP to > signal > > or > > > >> nest a large number of LSP's, we would like to have the option of > > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for > > LDP. > > > >> > > > >> If there are operators who aren't going to be looking at scaling > > that > > > >> many LSP's anytime in their network, they might still prefer to > > > >> eliminate adjacency fate-sharing. > > > >> > > > >> I would propose that vendors implement both options, allowing > > > >> operators to choose (via CLI) which method they would like to > > deploy > > > >> in the field. There are many operators out there who maintain > > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's > > to > > > >> protect themselves against the problems fate-sharing could bring. > > > >> This is why some of us prefer to make our lives harder by going > > > >> native, dual-stack rather than 6PE :-). > > > >> > > > >> So while I won't disagree with your opinion on using a single > > > >> adjacency for both AF's for scaling purposes, I would certainly > > like > > > >> to have the option to choose which method suits me best in the > > wild. > > > >> > > > >> Mark. > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:25:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD8721F88DA for ; Mon, 12 Mar 2012 10:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.943 X-Spam-Level: X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0FCK-P3GUmv for ; Mon, 12 Mar 2012 10:25:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52221F879B for ; Mon, 12 Mar 2012 10:25:33 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2CHPFgS021509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:25:18 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHPFSd028710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:55:15 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 12 Mar 2012 22:55:14 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "mtinka@globaltransit.net" , "mpls@ietf.org" , "Rajiv Asati (rajiva)" Date: Mon, 12 Mar 2012 22:55:12 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4++rqP00r2+MmRu+KPYcyprKrWgB+23xgAV9awtA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <201203031309.34330.mtinka@globaltransit.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:25:47 -0000 Rajiv, May I request you to answer on the following we raised over the issu= e on dual-stack hello adjacencies made mandatory for ipv6 draft? We still h= aven't heard justifications from any of the authors... Thanks, Pranjal -----Original Message----- From: Dutta, Pranjal K (Pranjal)=20 Sent: Monday, March 05, 2012 10:31 AM To: 'mtinka@globaltransit.net'; mpls@ietf.org Cc: Vishwas Manral; Aissaoui, Mustapha (Mustapha); Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mark, Please refer my responses inline. Thanks, Pranjal -----Original Message----- From: Mark Tinka [mailto:mtinka@globaltransit.net]=20 Sent: Friday, March 02, 2012 9:10 PM To: mpls@ietf.org Cc: Dutta, Pranjal K (Pranjal); Vishwas Manral; Aissaoui, Mustapha (Mustaph= a); Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K=20 (Pranjal) wrote: > >From an implementer/system designer's point of view I > >would think single hello adjacency with per adjacency > >capabilities would be right approach. Pranjal, I appreciate that from a vendor perspective,=20 implementing it this way would make sense for large scale=20 deployments. However, for some operators who may be using BGP or RSVP to=20 signal or nest a large number of LSP's, we would like to=20 have the option of choosing a discrete separation of IPv4=20 and IPv6 adjacencies for LDP. If there are operators who aren't going to be looking at=20 scaling that many LSP's anytime in their network, they might=20 still prefer to eliminate adjacency fate-sharing. I think we are confusing two different things. Having separate he= llo adjacency over an interface as mandated in ldp-ipv6 draft **DOES NOT** = give you fate separation. Still both IPV4 and IPV6 FECs would fate-share sa= me LDP session. We are in fact saying that fate separation is desirable but for that we nee= d=20 separation of **sessions** and NOT hello adjacencies. If you follow the ldp= -ipv6 draft of separate adjacencies for IPV4 and IPV6 still all IPV4 and IP= V6=20 FECs would be fate sharing a **single** LDP sessions. The ldp-ipv6 draft makes it **mandatory** that dual stack interface MUST=20 Have two separate hello adjacencies. This does not make any sense from=20 practical stand point and rather raises many open questions keeping in view= of existing applicability/capabilities of LDP. IP6 FEC next-hop resolution= algorithms does not mandate running hello adjacency with an ipv6 next-hop.= FEC capabilities are decoupled from the address family used in hello adjac= encies.=20 Just to give an example. Let's take the WG item on mLdp in-band signaling draft below.=20 http://tools.ietf.org/html/draft-ietf-mpls-mldp-in-band-signaling-05 This draft defines in-band signaling of multicast (S,G)s top set-up the LDP= Multicast tunnels for the respective S,Gs. If we look at section 3 it has = IPV4 as well as IPV6 specific multicast LSPs. If ldp-ipv6 draft mandates ru= nning separate adjacencies on dual stack then the question would be - where= is the placement of those LSP types w.r.t dual hello adjacencies **mandate= d** by ldp-ipv6?=20 The WG has decided to move to LDP capabilities (RFC 5561) to advertise vari= ous capabilities of a single LDP session. Various extensions has been done = further based on that. For example, mLdp Spec (RFC 6388) defines capabiliti= es for various multicast fec types (Refer to section 2.1) over an ldp sessi= ons. mLdp has been shipped and is deployed. Now are we saying we=20 Should be running **separate** hello adjacencies per FEC type over a **sing= le** Interface with **same** peering LSR?=20 There is another WG item that introduces IP and PW FEC Capability. http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-01 Then why the fundamental shift for IPV6 unicast FECs alone? I have scouted = the archive on all discussions occurred in the past on ldp-ipv6 yet hasn't = seen a strong technical basis why it is MUST for IPV6 FECs to take a radica= lly different approach.=20 In ldp-ipv6 draft, the proposal of running separate ipv4 and ipv6 hello adj= acencies yet fate sharing **same** session to signal dual stack capabilitie= s is a fundamental shift from the capability based approaches already adopt= ed by the WG. IPV6 is just another FEC element type. I have seen puritanica= l references like "OSPF does so", "BGP does so" in some discussions in this= list but that does not provide enough technical basis in the context of LD= P. There has to be a single/consistent approach=20 To satisfy your requirement for fate separation of IPV4 and IPV6 FECs, we n= eed to work out a separate spec on running "multi-lsr" **sessions** between= two peering systems - as an extension to RFC 5036. Such method can not on= ly useful for IPV4 and IPV6 FEC separation but for other types as well. For= example, it can also provide an option for fate separation of PW FECs (L2 = Over lay) from the transport FECs (IPV4, IPV6, Multicast). =20 I would propose that vendors implement both options,=20 allowing operators to choose (via CLI) which method they=20 would like to deploy in the field. There are many operators=20 out there who maintain separate BGP transport and policy=20 sessions for IPv4 and IPv6 AF's to protect themselves=20 against the problems fate-sharing could bring. This is why=20 some of us prefer to make our lives harder by going native,=20 dual-stack rather than 6PE :-). As I mentioned above separation of ipv4 and ipv6 hello adjacencie= s does not provide fate separation. I guess what you are mentioning about=20 Separation of IPV4 and IPV6 FECs over two separate LDP sessions between=20 two peering systems which can be achieved by running multi-lsr sessions. <\Pranjal>=20 So while I won't disagree with your opinion on using a=20 single adjacency for both AF's for scaling purposes, I would=20 certainly like to have the option to choose which method=20 suits me best in the wild. =20 I think what you are looking for knob to toggle fate sharing and fate separ= ation of IPV4 and IPV6 FECs. For this we need a knob whether we=20 Single LSR peering or multi-lsr peering. This is different from separation= =20 Of ipv4 and ipv6 hello adjacencies. In LDP, hello adjacencies are discovery= protocols and does not have "tight" coupling with various FEC types existe= nt in LDP. We can satisfy both fate-shared and fate-separation requirement= s using single hello adjacency (with per adjacency capabilities) associated= with a remote lsr-id. Mark. From rajiva@cisco.com Mon Mar 12 10:26:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB03B21F88F0 for ; Mon, 12 Mar 2012 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.971 X-Spam-Level: X-Spam-Status: No, score=-9.971 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQOu-Wpg7cI5 for ; Mon, 12 Mar 2012 10:26:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7821D21F88ED for ; Mon, 12 Mar 2012 10:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=11936; q=dns/txt; s=iport; t=1331573185; x=1332782785; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ArCti84BM2e6AahUBGcfZQRiqqK+2Iq05q6ApbrF784=; b=AdPtDiI4ZBNta2aXUQR23JbZexv+P6ilUsjDk+BztrNpnQXKjLqwAvAe AqZkcBnFJ8IcgiSzmq3cxlcuQIkvsrAsUqCLBXBLES103tYGxtzVJpdUG k4NjYHXuLQ1zTAxZM/WrSZN+PQmP9tjXQO+HDewZzeoIyj8nx2MQqqqTe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKAwXk+tJXG9/2dsb2JhbABBtWSBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAgQBEggah2gLn3YBlwUEkB5jBIhUnRuDAQ X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="65738479" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 12 Mar 2012 17:26:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHQNWb032211; Mon, 12 Mar 2012 17:26:24 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:26:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 12:26:22 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA233@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABwTTAAADSycA== References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Shane Amante" X-OriginalArrivalTime: 12 Mar 2012 17:26:24.0053 (UTC) FILETIME=[3F85F650:01CD0075] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:26:27 -0000 Pranjal, I am sorry, but such remarks will not lead to any healthy discussion.=20 Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:21 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Rajiv, >=20 >=20 >=20 > "I will shy away from the above circular logic. :-) Nonetheless, different LSR- > IDs is one way to get to multi-session LDP." >=20 >=20 >=20 > I don't see any circular logic. You seemed to be quite confused between LDP > hello adjacencies, its intent and LDP sessions. >=20 >=20 >=20 > Cheers, >=20 > Pranjal >=20 >=20 >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:14 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Pranjal, >=20 >=20 >=20 > > Howevever whether both an implementation wants to send hellos for both >=20 > > adjacencies on a same interface (either ipv4 or ipv6) or different >=20 > > interfaces is implementation specific. >=20 >=20 >=20 > It can't be, because it will break interoperability. This calls for >=20 > normative behavior. >=20 >=20 >=20 > > We send hellos over an interface >=20 > > as intent of a LSR to include that interface for traffic and multiple >=20 > > LSRs can hellos with same source ip address. >=20 >=20 >=20 > Thanks for sharing the implementation details. >=20 >=20 >=20 > I followed the first part (and agreed), but I didn't follow the 2nd part >=20 > (i.e. multiple LSRs can hellos with same source ip address), but it >=20 > sounded incorrect. >=20 >=20 >=20 >=20 >=20 > > If order to have fate separation between IPV4 and IPV6, we need >=20 > separation >=20 > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been >=20 > different, >=20 > > so obviously it would lead to two separate LDP sessions. >=20 >=20 >=20 > I will shy away from the above circular logic. :-) >=20 > Nonetheless, different LSR-IDs is one way to get to multi-session LDP. >=20 >=20 >=20 > Cheers, >=20 > Rajiv >=20 >=20 >=20 > > -----Original Message----- >=20 > > From: Dutta, Pranjal K (Pranjal) >=20 > [mailto:pranjal.dutta@alcatel-lucent.com] >=20 > > Sent: Monday, March 12, 2012 12:30 PM >=20 > > To: Rajiv Asati (rajiva); Shane Amante >=20 > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > >=20 > > There are more subtleties involved when we talk on real >=20 > implementation. >=20 > > >=20 > > If order to have fate separation between IPV4 and IPV6, we need >=20 > separation >=20 > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been >=20 > different, >=20 > > so obviously it would lead to two separate LDP sessions. >=20 > > Howevever whether both an implementation wants to send hellos for both >=20 > > adjacencies on a same interface (either ipv4 or ipv6) or different >=20 > > interfaces is implementation specific. We send hellos over an >=20 > interface >=20 > > as intent of a LSR to include that interface for traffic and multiple >=20 > > LSRs can hellos with same source ip address. >=20 > > >=20 > > Thanks, >=20 > > Pranjal >=20 > > >=20 > > -----Original Message----- >=20 > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >=20 > Of >=20 > > Rajiv Asati (rajiva) >=20 > > Sent: Monday, March 12, 2012 7:24 AM >=20 > > To: Dutta, Pranjal K (Pranjal); Shane Amante >=20 > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > >=20 > > Shane, Pranjal, >=20 > > >=20 > > Let's make sure that we don't have any disconnect here at least on the >=20 > > technicalities here (ignoring the draft discussion for a minute) >=20 > > >=20 > > Shane's Q is whether either v4 or v6 hello could help to establish v4 >=20 > > and/or v6 LDP session. >=20 > > While Pranjal's assertion is correct on its own, it doesn't quite >=20 > answer >=20 > > the subtlety in Shane's Q. >=20 > > >=20 > > Shane's Q: >=20 > > > With respect to LDP Hellos, you're suggesting that operators run >=20 > > either IPv4- >=20 > > > only Hello's or IPv6-only Hello's, (never both at the same time), >=20 > but >=20 > > through >=20 > > > either one can discover the "(IPv4|IPv6) transport capabilities" of >=20 > a >=20 > > LDP peer >=20 > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. >=20 > > Correct? >=20 > > >=20 > > Not really. Using v4 hello MUST not lead to using v6 transport and v6 >=20 > > LDP session. That would be a fundamentally wrong approach. >=20 > > >=20 > > As Pranjal said, v4 hello usage must lead to v4 session establishment, >=20 > > whereas v6 hello usage must lead to v6 session establishment. >=20 > > >=20 > > Cheers, >=20 > > Rajiv >=20 > > >=20 > > >=20 > > > -----Original Message----- >=20 > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >=20 > > Of >=20 > > > Dutta, Pranjal K (Pranjal) >=20 > > > Sent: Tuesday, March 06, 2012 1:28 PM >=20 > > > To: Shane Amante >=20 > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > >=20 > > > Hi Shane, >=20 > > > Yes, that's correct. We can run either ipv4 hellos or ipv6 >=20 > > hellos and >=20 > > > operator can choose whichever is best, based upon the operational >=20 > > needs. >=20 > > > Since the src ip addresses used by hello packets are not coupled >=20 > with >=20 > > FEC >=20 > > > types so single hello can advertise various FEC capabilities. >=20 > > > >=20 > > > If we run multiple ldp sessions between peering systems for >=20 > > fate >=20 > > > separation of ipv4 and ipv6 then there can be two separate hello >=20 > > adjacencies >=20 > > > over a single interface (each one associated with separate sessions) >=20 > > but in >=20 > > > that case the LSR-IDS used would be different (we need to work for >=20 > an >=20 > > > extension of RFC 5036). >=20 > > > >=20 > > > Thanks, >=20 > > > Pranjal >=20 > > > >=20 > > > -----Original Message----- >=20 > > > From: Shane Amante [mailto:shane@castlepoint.net] >=20 > > > Sent: Monday, March 05, 2012 10:13 PM >=20 > > > To: Dutta, Pranjal K (Pranjal) >=20 > > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); >=20 > > > mpls@ietf.org; Lizhong Jin >=20 > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > >=20 > > > Hi Pranjal, >=20 > > > >=20 > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: >=20 > > > > Hi Shane, >=20 > > > > Yes, two separate LDP sessions are required for fate >=20 > > separation of ipv4 >=20 > > > and ipv6 fecs. >=20 > > > > >=20 > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to >=20 > > > > satisfy >=20 > > > > a) and b). Both can be achieved with single hello adjacency per >=20 > > > > interface per peering lsr-id with adjacency specific capabilities. >=20 > > > >=20 > > > I'm in agreement with you with respect to LDP sessions. >=20 > > > >=20 > > > With respect to LDP Hellos, you're suggesting that operators run >=20 > > either IPv4- >=20 > > > only Hello's or IPv6-only Hello's, (never both at the same time), >=20 > but >=20 > > through >=20 > > > either one can discover the "(IPv4|IPv6) transport capabilities" of >=20 > a >=20 > > LDP peer >=20 > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. >=20 > > Correct? >=20 > > > >=20 > > > -shane >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Thanks, >=20 > > > > Pranjal >=20 > > > > >=20 > > > > >=20 > > > > -----Original Message----- >=20 > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >=20 > Behalf >=20 > > > > Of Shane Amante >=20 > > > > Sent: Friday, March 02, 2012 11:34 PM >=20 > > > > To: mtinka@globaltransit.net >=20 > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > >=20 > > > > Mark, >=20 > > > > >=20 > > > > I completely agree with all of your comments below. I too would >=20 > > (strongly) >=20 > > > prefer the option to allow operators to choose (via CLI) whether to: >=20 > > > > a) use separate transport to ensure there is no fate-sharing of >=20 > IPv4 >=20 > > + >=20 > > > > IPv6; or, >=20 > > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 >=20 > (or, >=20 > > other >=20 > > > AF's) on a single session, for scale reasons. >=20 > > > > >=20 > > > > -shane >=20 > > > > >=20 > > > > >=20 > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: >=20 > > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K >=20 > > > >> (Pranjal) wrote: >=20 > > > >> >=20 > > > >>>> From an implementer/system designer's point of view I would >=20 > think >=20 > > > >>>> single hello adjacency with per adjacency capabilities would be >=20 > > > >>>> right approach. >=20 > > > >> >=20 > > > >> Pranjal, I appreciate that from a vendor perspective, >=20 > implementing >=20 > > it >=20 > > > >> this way would make sense for large scale deployments. >=20 > > > >> >=20 > > > >> However, for some operators who may be using BGP or RSVP to >=20 > signal >=20 > > or >=20 > > > >> nest a large number of LSP's, we would like to have the option of >=20 > > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for >=20 > > LDP. >=20 > > > >> >=20 > > > >> If there are operators who aren't going to be looking at scaling >=20 > > that >=20 > > > >> many LSP's anytime in their network, they might still prefer to >=20 > > > >> eliminate adjacency fate-sharing. >=20 > > > >> >=20 > > > >> I would propose that vendors implement both options, allowing >=20 > > > >> operators to choose (via CLI) which method they would like to >=20 > > deploy >=20 > > > >> in the field. There are many operators out there who maintain >=20 > > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's >=20 > > to >=20 > > > >> protect themselves against the problems fate-sharing could bring. >=20 > > > >> This is why some of us prefer to make our lives harder by going >=20 > > > >> native, dual-stack rather than 6PE :-). >=20 > > > >> >=20 > > > >> So while I won't disagree with your opinion on using a single >=20 > > > >> adjacency for both AF's for scaling purposes, I would certainly >=20 > > like >=20 > > > >> to have the option to choose which method suits me best in the >=20 > > wild. >=20 > > > >> >=20 > > > >> Mark. >=20 > > > > _______________________________________________ >=20 > > > > mpls mailing list >=20 > > > > mpls@ietf.org >=20 > > > > https://www.ietf.org/mailman/listinfo/mpls >=20 > > > >=20 > > > _______________________________________________ >=20 > > > mpls mailing list >=20 > > > mpls@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls >=20 > > _______________________________________________ >=20 > > mpls mailing list >=20 > > mpls@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:28:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA96D21F8903 for ; Mon, 12 Mar 2012 10:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.272 X-Spam-Level: X-Spam-Status: No, score=-9.272 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z8+z5qr9VvS for ; Mon, 12 Mar 2012 10:28:27 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE77F21F88FF for ; Mon, 12 Mar 2012 10:28:24 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2CHS5wL022129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:28:08 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHS5ft003818 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 22:58:05 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 12 Mar 2012 22:58:04 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante Date: Mon, 12 Mar 2012 22:58:02 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABXMzAAACIEQAAAMtsg Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA21F@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA21F@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:28:29 -0000 Rajiv, I voted for win-win. Implementations can provide knob to toggle. You can't force an operator that has ipv4 only links connecting LDP=20 Network to provision ipv6 links in order to transport/set-up IPV6 FECs. It won't break inter-operability. Cheers, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Monday, March 12, 2012 10:24 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, Please consider this scenario -=20 - LSR A's implementation expects both v4 and v6 hellos from LSR B,=20 - LSR B's implementation sends only v4 hello to LSR B That's why we shouldn't make this implementation specific. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:17 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > "It can't be, because it will break interoperability. This calls for > normative behavior." >=20 > Reference Please? >=20 >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:14 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > Howevever whether both an implementation wants to send hellos for both > > adjacencies on a same interface (either ipv4 or ipv6) or different > > interfaces is implementation specific. >=20 > It can't be, because it will break interoperability. This calls for > normative behavior. >=20 > > We send hellos over an interface > > as intent of a LSR to include that interface for traffic and multiple > > LSRs can hellos with same source ip address. >=20 > Thanks for sharing the implementation details. >=20 > I followed the first part (and agreed), but I didn't follow the 2nd part > (i.e. multiple LSRs can hellos with same source ip address), but it > sounded incorrect. >=20 >=20 > > If order to have fate separation between IPV4 and IPV6, we need > separation > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been > different, > > so obviously it would lead to two separate LDP sessions. >=20 > I will shy away from the above circular logic. :-) > Nonetheless, different LSR-IDs is one way to get to multi-session LDP. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:30 PM > > To: Rajiv Asati (rajiva); Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > There are more subtleties involved when we talk on real > implementation. > > > > If order to have fate separation between IPV4 and IPV6, we need > separation > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been > different, > > so obviously it would lead to two separate LDP sessions. > > Howevever whether both an implementation wants to send hellos for both > > adjacencies on a same interface (either ipv4 or ipv6) or different > > interfaces is implementation specific. We send hellos over an > interface > > as intent of a LSR to include that interface for traffic and multiple > > LSRs can hellos with same source ip address. > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:24 AM > > To: Dutta, Pranjal K (Pranjal); Shane Amante > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Shane, Pranjal, > > > > Let's make sure that we don't have any disconnect here at least on the > > technicalities here (ignoring the draft discussion for a minute) > > > > Shane's Q is whether either v4 or v6 hello could help to establish v4 > > and/or v6 LDP session. > > While Pranjal's assertion is correct on its own, it doesn't quite > answer > > the subtlety in Shane's Q. > > > > Shane's Q: > > > With respect to LDP Hellos, you're suggesting that operators run > > either IPv4- > > > only Hello's or IPv6-only Hello's, (never both at the same time), > but > > through > > > either one can discover the "(IPv4|IPv6) transport capabilities" of > a > > LDP peer > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > > Correct? > > > > Not really. Using v4 hello MUST not lead to using v6 transport and v6 > > LDP session. That would be a fundamentally wrong approach. > > > > As Pranjal said, v4 hello usage must lead to v4 session establishment, > > whereas v6 hello usage must lead to v6 session establishment. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Dutta, Pranjal K (Pranjal) > > > Sent: Tuesday, March 06, 2012 1:28 PM > > > To: Shane Amante > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Shane, > > > Yes, that's correct. We can run either ipv4 hellos or ipv6 > > hellos and > > > operator can choose whichever is best, based upon the operational > > needs. > > > Since the src ip addresses used by hello packets are not coupled > with > > FEC > > > types so single hello can advertise various FEC capabilities. > > > > > > If we run multiple ldp sessions between peering systems for > > fate > > > separation of ipv4 and ipv6 then there can be two separate hello > > adjacencies > > > over a single interface (each one associated with separate sessions) > > but in > > > that case the LSR-IDS used would be different (we need to work for > an > > > extension of RFC 5036). > > > > > > Thanks, > > > Pranjal > > > > > > -----Original Message----- > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > Sent: Monday, March 05, 2012 10:13 PM > > > To: Dutta, Pranjal K (Pranjal) > > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); > > > mpls@ietf.org; Lizhong Jin > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Pranjal, > > > > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: > > > > Hi Shane, > > > > Yes, two separate LDP sessions are required for fate > > separation of ipv4 > > > and ipv6 fecs. > > > > > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to > > > > satisfy > > > > a) and b). Both can be achieved with single hello adjacency per > > > > interface per peering lsr-id with adjacency specific capabilities. > > > > > > I'm in agreement with you with respect to LDP sessions. > > > > > > With respect to LDP Hellos, you're suggesting that operators run > > either IPv4- > > > only Hello's or IPv6-only Hello's, (never both at the same time), > but > > through > > > either one can discover the "(IPv4|IPv6) transport capabilities" of > a > > LDP peer > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. > > Correct? > > > > > > -shane > > > > > > > > > > > > > Thanks, > > > > Pranjal > > > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > > Of Shane Amante > > > > Sent: Friday, March 02, 2012 11:34 PM > > > > To: mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Mark, > > > > > > > > I completely agree with all of your comments below. I too would > > (strongly) > > > prefer the option to allow operators to choose (via CLI) whether to: > > > > a) use separate transport to ensure there is no fate-sharing of > IPv4 > > + > > > > IPv6; or, > > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 > (or, > > other > > > AF's) on a single session, for scale reasons. > > > > > > > > -shane > > > > > > > > > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: > > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K > > > >> (Pranjal) wrote: > > > >> > > > >>>> From an implementer/system designer's point of view I would > think > > > >>>> single hello adjacency with per adjacency capabilities would be > > > >>>> right approach. > > > >> > > > >> Pranjal, I appreciate that from a vendor perspective, > implementing > > it > > > >> this way would make sense for large scale deployments. > > > >> > > > >> However, for some operators who may be using BGP or RSVP to > signal > > or > > > >> nest a large number of LSP's, we would like to have the option of > > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for > > LDP. > > > >> > > > >> If there are operators who aren't going to be looking at scaling > > that > > > >> many LSP's anytime in their network, they might still prefer to > > > >> eliminate adjacency fate-sharing. > > > >> > > > >> I would propose that vendors implement both options, allowing > > > >> operators to choose (via CLI) which method they would like to > > deploy > > > >> in the field. There are many operators out there who maintain > > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's > > to > > > >> protect themselves against the problems fate-sharing could bring. > > > >> This is why some of us prefer to make our lives harder by going > > > >> native, dual-stack rather than 6PE :-). > > > >> > > > >> So while I won't disagree with your opinion on using a single > > > >> adjacency for both AF's for scaling purposes, I would certainly > > like > > > >> to have the option to choose which method suits me best in the > > wild. > > > >> > > > >> Mark. > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Mar 12 10:28:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F022A21F88FF for ; Mon, 12 Mar 2012 10:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.981 X-Spam-Level: X-Spam-Status: No, score=-9.981 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aXdt2n7duIQ for ; Mon, 12 Mar 2012 10:28:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF921F890B for ; Mon, 12 Mar 2012 10:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=9623; q=dns/txt; s=iport; t=1331573306; x=1332782906; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=YeGKVPK0LCz/EcE/D9e9N198yb7Z3k6Rf2gjJAIM9ZM=; b=QM4PC8cswDBSJe+uo49oIC+UbOKjFsIkR6JV2BCS9KyFjdKTLQPQuEkN /Fzdb88UNY8fU4XwK9Of7O9UNJOCOBWEkuy3t5aIMN26DJHL+SXU1Ns7H O2pdYY/8BY+JgHt4NSq6ia6pMykXOqmXSU6vkhIeTSS4WsjG/Lkeyf+XI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEkxXk+tJV2a/2dsb2JhbABDtVeBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASAGHwkIAgQBEggah2MFC50hAZ5viUSGWmMEiFSYI4R4gwGBPg X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="65748633" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 17:28:25 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHSPKx000591; Mon, 12 Mar 2012 17:28:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 12:28:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Mar 2012 12:28:24 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA23F@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAABijSA= References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Henderickx, Wim (Wim)" , X-OriginalArrivalTime: 12 Mar 2012 17:28:25.0389 (UTC) FILETIME=[87D85DD0:01CD0075] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:28:34 -0000 Pranjal, > You know transport address only after exchanging hellos. First hellos need > to be sent to right remote LSR-ID.=20 Hellos should be sent to the correct transport address (unicast or multicast), not to the chosen LSR-ID. =20 Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:45 PM > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > Rajeev, >=20 > Not really. There are applications that auto-instantiate T-LDP sessions. > You know transport address only after exchanging hellos. First hellos need > to be sent to right remote LSR-ID. We don't run another discovery protocol > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you suggesting > that all such applications are irrelevant and needs to be wiped > out from deployments. I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:06 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, Mustapha, Wim, >=20 > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > > LDP has to auto-create targeted sessions. We can't force to set-up > another > > ip4 network just for some applications. It won't be possible to map 4 > byte ldp >=20 > I hope that we are not misunderstanding 32-bit integer value in RouterID > in an IPv6-only router to mean having IPv4 network. > Also, such applications must use 'transport IP address', not the > Router-ID when it comes to setting up the session. If they don't, then > they are incorrect and must be fixed. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Friday, March 02, 2012 12:02 PM > > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, > > We shouldn't be ruling out the fact that there are some > differences in > > applications of LDP compared to OSPF or BGP. If we have IPV6 only > transport > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > > LDP has to auto-create targeted sessions. We can't force to set-up > another > > ip4 network just for some applications. It won't be possible to map 4 > byte ldp > > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > is must > > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > and better > > to add it now. > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Henderickx, Wim (Wim) > > Sent: Friday, March 02, 2012 12:41 AM > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, > > > > I understand we didn't add a IPv6 router ID option in BGP/OSPF but we > > should look at the future to get to IPv6 only networks and as such it > will be > > required. So we are now at a point where we should add this option in > all > > protocols. Since LDP for Ipv6 is open we need to add it now. > > > > My 2 cents > > > > Cheers, > > Wim > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: vrijdag 2 maart 2012 8:08 > > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Wim, > > > > That's a reasonable point, but no such proposal has been made for > other > > protocols. In fact, IPv6 deployments have already accommodated 4-octet > > router-id for routing protocols (which was also a departure from the > > common practice in IPv4 realm). As Mark T and I discussed in the > > previous email, the router-id consistency across protocols would be an > > operational benefit. > > > > Focusing on the technicalities, Router ID is meant to ensure the > > uniqueness of the router within the network while following the > > protocol, so are we thinking that 4-octet is not good enough to ensure > > the uniqueness? If so, then it would be worth having that discussion > in > > the Routing and Internet areas that have been focusing on IPv6 at > large. > > > > > > While I do agree to 128-bit future expandability as a benefit, the > > benefit would be trivial (at the expense of message structure changes) > > if we expanded it for the sake of it, but didn't address the root of > the > > problem. > > > > Do you think otherwise? > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > lucent.com] > > > Sent: Friday, March 02, 2012 1:42 AM > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, I believe we need to provide both options to ensure both are > > possible. > > > If we do not introduce the IPv6 LSR ID now I will be very hard to ad > > it in the > > > future. > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Rajiv Asati (rajiva) > > > Sent: vrijdag 2 maart 2012 7:39 > > > To: mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mark, > > > > > > Well said. > > > > > > I take that we are in agreement wrt 4-octet entity for LDP router-id > > in > > > the context of IPv6, as specified. > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > > Sent: Friday, March 02, 2012 1:31 AM > > > > To: Rajiv Asati (rajiva) > > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > > lizhong.jin@zte.com.cn; > > > > vishwas.ietf@gmail.com > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > > wrote: > > > > > > > > > In the past, implementations provided the router-id CLI > > > > > for any interface IPv4 address to be chosen as router-id > > > > > for various protocols including LDP. > > > > > > > > > However, many implementations already evolved the CLI to > > > > > not even give an "interface" IP address for router-id, > > > > > to accommodate IPv6. Almost all deployed networks > > > > > already accommodated that. > > > > > > > > We do operate some implementations today that "still" allow > > > > you to specify the Router-ID for various protocols as an > > > > independent 32-bit integer (only), and also allow you to > > > > define the LSR-ID for LDP as an interface (only). This is > > > > current, shipping 2012 code. > > > > > > > > So both scenarios you mention above are still much in play > > > > today. Whether operators are using them or not (I know we > > > > are) is another matter entirely. > > > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > > implementations could evolve LDP router-id as well to > > > > > accommodate IPv6. This would make LDP router-id to be > > > > > consistent with other protocols delving with IPv6. And > > > > > this can certainly be operationally beneficial from IPv6 > > > > > POV. > > > > > > > > Agree. > > > > > > > > > In fact, one of the implementations allow the router-id > > > > > to be configured just once and let all protocols just > > > > > use it, if they wanted. > > > > > > > > Yes, we operate some implementations that use this method > > > > too. It's quite elegant, in that you configure once and > > > > forget. Other implementations that are more structured means > > > > operators could easily forget to specify the Router-ID for a > > > > particular protocol, for better or worse. > > > > > > > > Cheers, > > > > > > > > Mark. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:31:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1444B21F88EA for ; Mon, 12 Mar 2012 10:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.307 X-Spam-Level: X-Spam-Status: No, score=-9.307 tagged_above=-999 required=5 tests=[AWL=1.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOAI8MGnwAi4 for ; Mon, 12 Mar 2012 10:31:02 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3D21F888F for ; Mon, 12 Mar 2012 10:31:02 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2CHUk9U022850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:30:48 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHUkeW003879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 23:00:46 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Mon, 12 Mar 2012 23:00:45 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , Shane Amante Date: Mon, 12 Mar 2012 23:00:43 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz7YEUCUwszUceER5CHrafqVtCOZAAZebaAASUZSOAABJFzEAABaYrAAABwTTAAADSycAAAG0aQ Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD575E18E@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203031309.34330.mtinka@globaltransit.net><71D28042-CCD0-4B1D-A55A-F80DE2133070@castlepoint.net><6C9D56F8-D4F6-4D27-BE21-DEED9439BA69@castlepoint.net> <067E6CE33034954AAC05C9EC85E2577C079FA0B1@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA208@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA233@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA233@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , Lizhong Jin Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:31:04 -0000 Rajeev, Who started this? I am raising technical issues but I am not gettin= g any answers with technical justifications. We need to justify on technica= l=20 front to carry forward a healthy discussion. Cheers, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Monday, March 12, 2012 10:26 AM To: Dutta, Pranjal K (Pranjal); Shane Amante Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, I am sorry, but such remarks will not lead to any healthy discussion.=20 Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:21 PM > To: Rajiv Asati (rajiva); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Rajiv, >=20 >=20 >=20 > "I will shy away from the above circular logic. :-) Nonetheless, different LSR- > IDs is one way to get to multi-session LDP." >=20 >=20 >=20 > I don't see any circular logic. You seemed to be quite confused between LDP > hello adjacencies, its intent and LDP sessions. >=20 >=20 >=20 > Cheers, >=20 > Pranjal >=20 >=20 >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:14 AM > To: Dutta, Pranjal K (Pranjal); Shane Amante > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 >=20 > Pranjal, >=20 >=20 >=20 > > Howevever whether both an implementation wants to send hellos for both >=20 > > adjacencies on a same interface (either ipv4 or ipv6) or different >=20 > > interfaces is implementation specific. >=20 >=20 >=20 > It can't be, because it will break interoperability. This calls for >=20 > normative behavior. >=20 >=20 >=20 > > We send hellos over an interface >=20 > > as intent of a LSR to include that interface for traffic and multiple >=20 > > LSRs can hellos with same source ip address. >=20 >=20 >=20 > Thanks for sharing the implementation details. >=20 >=20 >=20 > I followed the first part (and agreed), but I didn't follow the 2nd part >=20 > (i.e. multiple LSRs can hellos with same source ip address), but it >=20 > sounded incorrect. >=20 >=20 >=20 >=20 >=20 > > If order to have fate separation between IPV4 and IPV6, we need >=20 > separation >=20 > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been >=20 > different, >=20 > > so obviously it would lead to two separate LDP sessions. >=20 >=20 >=20 > I will shy away from the above circular logic. :-) >=20 > Nonetheless, different LSR-IDs is one way to get to multi-session LDP. >=20 >=20 >=20 > Cheers, >=20 > Rajiv >=20 >=20 >=20 > > -----Original Message----- >=20 > > From: Dutta, Pranjal K (Pranjal) >=20 > [mailto:pranjal.dutta@alcatel-lucent.com] >=20 > > Sent: Monday, March 12, 2012 12:30 PM >=20 > > To: Rajiv Asati (rajiva); Shane Amante >=20 > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > >=20 > > There are more subtleties involved when we talk on real >=20 > implementation. >=20 > > >=20 > > If order to have fate separation between IPV4 and IPV6, we need >=20 > separation >=20 > > of ldp sessions with multiple lsr-ids. Since LSR-IDs used have been >=20 > different, >=20 > > so obviously it would lead to two separate LDP sessions. >=20 > > Howevever whether both an implementation wants to send hellos for both >=20 > > adjacencies on a same interface (either ipv4 or ipv6) or different >=20 > > interfaces is implementation specific. We send hellos over an >=20 > interface >=20 > > as intent of a LSR to include that interface for traffic and multiple >=20 > > LSRs can hellos with same source ip address. >=20 > > >=20 > > Thanks, >=20 > > Pranjal >=20 > > >=20 > > -----Original Message----- >=20 > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >=20 > Of >=20 > > Rajiv Asati (rajiva) >=20 > > Sent: Monday, March 12, 2012 7:24 AM >=20 > > To: Dutta, Pranjal K (Pranjal); Shane Amante >=20 > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > >=20 > > Shane, Pranjal, >=20 > > >=20 > > Let's make sure that we don't have any disconnect here at least on the >=20 > > technicalities here (ignoring the draft discussion for a minute) >=20 > > >=20 > > Shane's Q is whether either v4 or v6 hello could help to establish v4 >=20 > > and/or v6 LDP session. >=20 > > While Pranjal's assertion is correct on its own, it doesn't quite >=20 > answer >=20 > > the subtlety in Shane's Q. >=20 > > >=20 > > Shane's Q: >=20 > > > With respect to LDP Hellos, you're suggesting that operators run >=20 > > either IPv4- >=20 > > > only Hello's or IPv6-only Hello's, (never both at the same time), >=20 > but >=20 > > through >=20 > > > either one can discover the "(IPv4|IPv6) transport capabilities" of >=20 > a >=20 > > LDP peer >=20 > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. >=20 > > Correct? >=20 > > >=20 > > Not really. Using v4 hello MUST not lead to using v6 transport and v6 >=20 > > LDP session. That would be a fundamentally wrong approach. >=20 > > >=20 > > As Pranjal said, v4 hello usage must lead to v4 session establishment, >=20 > > whereas v6 hello usage must lead to v6 session establishment. >=20 > > >=20 > > Cheers, >=20 > > Rajiv >=20 > > >=20 > > >=20 > > > -----Original Message----- >=20 > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >=20 > > Of >=20 > > > Dutta, Pranjal K (Pranjal) >=20 > > > Sent: Tuesday, March 06, 2012 1:28 PM >=20 > > > To: Shane Amante >=20 > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > >=20 > > > Hi Shane, >=20 > > > Yes, that's correct. We can run either ipv4 hellos or ipv6 >=20 > > hellos and >=20 > > > operator can choose whichever is best, based upon the operational >=20 > > needs. >=20 > > > Since the src ip addresses used by hello packets are not coupled >=20 > with >=20 > > FEC >=20 > > > types so single hello can advertise various FEC capabilities. >=20 > > > >=20 > > > If we run multiple ldp sessions between peering systems for >=20 > > fate >=20 > > > separation of ipv4 and ipv6 then there can be two separate hello >=20 > > adjacencies >=20 > > > over a single interface (each one associated with separate sessions) >=20 > > but in >=20 > > > that case the LSR-IDS used would be different (we need to work for >=20 > an >=20 > > > extension of RFC 5036). >=20 > > > >=20 > > > Thanks, >=20 > > > Pranjal >=20 > > > >=20 > > > -----Original Message----- >=20 > > > From: Shane Amante [mailto:shane@castlepoint.net] >=20 > > > Sent: Monday, March 05, 2012 10:13 PM >=20 > > > To: Dutta, Pranjal K (Pranjal) >=20 > > > Cc: mtinka@globaltransit.net; Aissaoui, Mustapha (Mustapha); >=20 > > > mpls@ietf.org; Lizhong Jin >=20 > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > >=20 > > > Hi Pranjal, >=20 > > > >=20 > > > On Mar 5, 2012, at 11:44 AM, Dutta, Pranjal K (Pranjal) wrote: >=20 > > > > Hi Shane, >=20 > > > > Yes, two separate LDP sessions are required for fate >=20 > > separation of ipv4 >=20 > > > and ipv6 fecs. >=20 > > > > >=20 > > > > Separation of ipv4 and ipv6 hello adjacencies are not required to >=20 > > > > satisfy >=20 > > > > a) and b). Both can be achieved with single hello adjacency per >=20 > > > > interface per peering lsr-id with adjacency specific capabilities. >=20 > > > >=20 > > > I'm in agreement with you with respect to LDP sessions. >=20 > > > >=20 > > > With respect to LDP Hellos, you're suggesting that operators run >=20 > > either IPv4- >=20 > > > only Hello's or IPv6-only Hello's, (never both at the same time), >=20 > but >=20 > > through >=20 > > > either one can discover the "(IPv4|IPv6) transport capabilities" of >=20 > a >=20 > > LDP peer >=20 > > > and, based on that, establish an IPv4 and/or IPv6 LDP session. >=20 > > Correct? >=20 > > > >=20 > > > -shane >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Thanks, >=20 > > > > Pranjal >=20 > > > > >=20 > > > > >=20 > > > > -----Original Message----- >=20 > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >=20 > Behalf >=20 > > > > Of Shane Amante >=20 > > > > Sent: Friday, March 02, 2012 11:34 PM >=20 > > > > To: mtinka@globaltransit.net >=20 > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Lizhong Jin >=20 > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > > > > >=20 > > > > Mark, >=20 > > > > >=20 > > > > I completely agree with all of your comments below. I too would >=20 > > (strongly) >=20 > > > prefer the option to allow operators to choose (via CLI) whether to: >=20 > > > > a) use separate transport to ensure there is no fate-sharing of >=20 > IPv4 >=20 > > + >=20 > > > > IPv6; or, >=20 > > > > b) use a single transport to permit fate-sharing of IPv4 + IPv6 >=20 > (or, >=20 > > other >=20 > > > AF's) on a single session, for scale reasons. >=20 > > > > >=20 > > > > -shane >=20 > > > > >=20 > > > > >=20 > > > > On Mar 2, 2012, at 10:09 PM, Mark Tinka wrote: >=20 > > > >> On Saturday, March 03, 2012 02:22:22 AM Dutta, Pranjal K >=20 > > > >> (Pranjal) wrote: >=20 > > > >> >=20 > > > >>>> From an implementer/system designer's point of view I would >=20 > think >=20 > > > >>>> single hello adjacency with per adjacency capabilities would be >=20 > > > >>>> right approach. >=20 > > > >> >=20 > > > >> Pranjal, I appreciate that from a vendor perspective, >=20 > implementing >=20 > > it >=20 > > > >> this way would make sense for large scale deployments. >=20 > > > >> >=20 > > > >> However, for some operators who may be using BGP or RSVP to >=20 > signal >=20 > > or >=20 > > > >> nest a large number of LSP's, we would like to have the option of >=20 > > > >> choosing a discrete separation of IPv4 and IPv6 adjacencies for >=20 > > LDP. >=20 > > > >> >=20 > > > >> If there are operators who aren't going to be looking at scaling >=20 > > that >=20 > > > >> many LSP's anytime in their network, they might still prefer to >=20 > > > >> eliminate adjacency fate-sharing. >=20 > > > >> >=20 > > > >> I would propose that vendors implement both options, allowing >=20 > > > >> operators to choose (via CLI) which method they would like to >=20 > > deploy >=20 > > > >> in the field. There are many operators out there who maintain >=20 > > > >> separate BGP transport and policy sessions for IPv4 and IPv6 AF's >=20 > > to >=20 > > > >> protect themselves against the problems fate-sharing could bring. >=20 > > > >> This is why some of us prefer to make our lives harder by going >=20 > > > >> native, dual-stack rather than 6PE :-). >=20 > > > >> >=20 > > > >> So while I won't disagree with your opinion on using a single >=20 > > > >> adjacency for both AF's for scaling purposes, I would certainly >=20 > > like >=20 > > > >> to have the option to choose which method suits me best in the >=20 > > wild. >=20 > > > >> >=20 > > > >> Mark. >=20 > > > > _______________________________________________ >=20 > > > > mpls mailing list >=20 > > > > mpls@ietf.org >=20 > > > > https://www.ietf.org/mailman/listinfo/mpls >=20 > > > >=20 > > > _______________________________________________ >=20 > > > mpls mailing list >=20 > > > mpls@ietf.org >=20 > > > https://www.ietf.org/mailman/listinfo/mpls >=20 > > _______________________________________________ >=20 > > mpls mailing list >=20 > > mpls@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Mon Mar 12 10:32:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E941B21F893F for ; Mon, 12 Mar 2012 10:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.34 X-Spam-Level: X-Spam-Status: No, score=-9.34 tagged_above=-999 required=5 tests=[AWL=1.259, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDZP2WAC36wG for ; Mon, 12 Mar 2012 10:32:01 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D1E6921F893E for ; Mon, 12 Mar 2012 10:32:01 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2CHVnkj023220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 12:31:52 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CHVnjx028923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Mar 2012 23:01:49 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 12 Mar 2012 23:01:48 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Mon, 12 Mar 2012 23:01:46 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAABijSAAAV9zQA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA23F@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA23F@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:32:03 -0000 Rajiv, How would you solve the following: Cheers, Pranjal -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Monday, March 12, 2012 10:28 AM To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); mtinka@globaltransit= .net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > You know transport address only after exchanging hellos. First hellos need > to be sent to right remote LSR-ID.=20 Hellos should be sent to the correct transport address (unicast or multicast), not to the chosen LSR-ID. =20 Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 12:45 PM > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 >=20 > Rajeev, >=20 > Not really. There are applications that auto-instantiate T-LDP sessions. > You know transport address only after exchanging hellos. First hellos need > to be sent to right remote LSR-ID. We don't run another discovery protocol > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you suggesting > that all such applications are irrelevant and needs to be wiped > out from deployments. I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rajiv Asati (rajiva) > Sent: Monday, March 12, 2012 7:06 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, Mustapha, Wim, >=20 > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > > LDP has to auto-create targeted sessions. We can't force to set-up > another > > ip4 network just for some applications. It won't be possible to map 4 > byte ldp >=20 > I hope that we are not misunderstanding 32-bit integer value in RouterID > in an IPv6-only router to mean having IPv4 network. > Also, such applications must use 'transport IP address', not the > Router-ID when it comes to setting up the session. If they don't, then > they are incorrect and must be fixed. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Friday, March 02, 2012 12:02 PM > > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, > > We shouldn't be ruling out the fact that there are some > differences in > > applications of LDP compared to OSPF or BGP. If we have IPV6 only > transport > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- > > LDP has to auto-create targeted sessions. We can't force to set-up > another > > ip4 network just for some applications. It won't be possible to map 4 > byte ldp > > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > is must > > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > and better > > to add it now. > > > > Thanks, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Henderickx, Wim (Wim) > > Sent: Friday, March 02, 2012 12:41 AM > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Rajiv, > > > > I understand we didn't add a IPv6 router ID option in BGP/OSPF but we > > should look at the future to get to IPv6 only networks and as such it > will be > > required. So we are now at a point where we should add this option in > all > > protocols. Since LDP for Ipv6 is open we need to add it now. > > > > My 2 cents > > > > Cheers, > > Wim > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: vrijdag 2 maart 2012 8:08 > > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Wim, > > > > That's a reasonable point, but no such proposal has been made for > other > > protocols. In fact, IPv6 deployments have already accommodated 4-octet > > router-id for routing protocols (which was also a departure from the > > common practice in IPv4 realm). As Mark T and I discussed in the > > previous email, the router-id consistency across protocols would be an > > operational benefit. > > > > Focusing on the technicalities, Router ID is meant to ensure the > > uniqueness of the router within the network while following the > > protocol, so are we thinking that 4-octet is not good enough to ensure > > the uniqueness? If so, then it would be worth having that discussion > in > > the Routing and Internet areas that have been focusing on IPv6 at > large. > > > > > > While I do agree to 128-bit future expandability as a benefit, the > > benefit would be trivial (at the expense of message structure changes) > > if we expanded it for the sake of it, but didn't address the root of > the > > problem. > > > > Do you think otherwise? > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > lucent.com] > > > Sent: Friday, March 02, 2012 1:42 AM > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, I believe we need to provide both options to ensure both are > > possible. > > > If we do not introduce the IPv6 LSR ID now I will be very hard to ad > > it in the > > > future. > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Rajiv Asati (rajiva) > > > Sent: vrijdag 2 maart 2012 7:39 > > > To: mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mark, > > > > > > Well said. > > > > > > I take that we are in agreement wrt 4-octet entity for LDP router-id > > in > > > the context of IPv6, as specified. > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > > Sent: Friday, March 02, 2012 1:31 AM > > > > To: Rajiv Asati (rajiva) > > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > > lizhong.jin@zte.com.cn; > > > > vishwas.ietf@gmail.com > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > > wrote: > > > > > > > > > In the past, implementations provided the router-id CLI > > > > > for any interface IPv4 address to be chosen as router-id > > > > > for various protocols including LDP. > > > > > > > > > However, many implementations already evolved the CLI to > > > > > not even give an "interface" IP address for router-id, > > > > > to accommodate IPv6. Almost all deployed networks > > > > > already accommodated that. > > > > > > > > We do operate some implementations today that "still" allow > > > > you to specify the Router-ID for various protocols as an > > > > independent 32-bit integer (only), and also allow you to > > > > define the LSR-ID for LDP as an interface (only). This is > > > > current, shipping 2012 code. > > > > > > > > So both scenarios you mention above are still much in play > > > > today. Whether operators are using them or not (I know we > > > > are) is another matter entirely. > > > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > > implementations could evolve LDP router-id as well to > > > > > accommodate IPv6. This would make LDP router-id to be > > > > > consistent with other protocols delving with IPv6. And > > > > > this can certainly be operationally beneficial from IPv6 > > > > > POV. > > > > > > > > Agree. > > > > > > > > > In fact, one of the implementations allow the router-id > > > > > to be configured just once and let all protocols just > > > > > use it, if they wanted. > > > > > > > > Yes, we operate some implementations that use this method > > > > too. It's quite elegant, in that you configure once and > > > > forget. Other implementations that are more structured means > > > > operators could easily forget to specify the Router-ID for a > > > > particular protocol, for better or worse. > > > > > > > > Cheers, > > > > > > > > Mark. > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Mar 12 11:30:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B6021F893A; Mon, 12 Mar 2012 11:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-8AKvDjRG-J; Mon, 12 Mar 2012 11:30:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B20721F892C; Mon, 12 Mar 2012 11:30:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312183038.7865.42061.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 11:30:38 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 18:30:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-01.txt Pages : 33 Date : 2012-03-12 Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-01.txt From gregory.mirsky@ericsson.com Mon Mar 12 12:36:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55F21E8096; Mon, 12 Mar 2012 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z07A3Ang1Ebh; Mon, 12 Mar 2012 12:36:22 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C0B7A21E8095; Mon, 12 Mar 2012 12:36:22 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2CJaLoA022754; Mon, 12 Mar 2012 14:36:22 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 12 Mar 2012 15:36:15 -0400 From: Gregory Mirsky To: "ietf@ietf.org" Date: Mon, 12 Mar 2012 15:36:14 -0400 Thread-Topic: RE: Last Call: (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC Thread-Index: Ac0Ah2L2izJRLkfhR1Wobgx1tFN2lQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135501CCB6CEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "bmwg@ietf.org" Subject: Re: [mpls] Last Call: (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:36:23 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135501CCB6CEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, Please consider my comments for the LC: * I'm concerned with the very title of the document, Methodology for = benchmarking MPLS protection mechanisms, even though only MPLS-TE FRR being= considered while LSP end-to-end and segment protection implicitly being ke= pt out of the scope. * I've found several textual inaccuracies related to both MPLS and BF= D to make me wonder if the document was liasioned to MPLS WG. * List of acronyms is missing - PLR, OIR, LOS, AIS, etc. * Introduction. I think that for "planned link or node failure" MBB i= s more efficient and useful than FRR. But MBB is not being mentioned in the= document. * Introduction. "A correlated failure is the simultaneous occurrence = of two or more failures." Personally, as correlated events I consider event= s with cause-effect relationship. * Introduction. Path restoration after FRR discussion does not appear= logical, in the scope of benchmarking document. * Document Scope. "Protection from Bi-directional Forwarding Detectio= n (BFD) is outside the scope of this document." I frankly couldn't decode t= his sentense. * Document Scope. Several references to Path Restoration as Re-optim= ization - doubt that it belongs in the document at all. * Sections 6.1.1 through 6.2.4 - what is relevance of listing number= s of labels in the stack? * Peerformance of control plane should be outside of the scope of ben= chmarking as it is end-to-end metrics, not explicitly of DUT. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF135501CCB6CEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
Please consider my comments for the LC:
  • I'm concerned with the very title of the document, Methodology for benc= hmarking MPLS protection mechanisms, even though only MPLS-TE FRR being con= sidered while LSP end-to-end and segment protection implicitly being kept o= ut of the scope.
  • I've found several textual inaccuracies related to= both MPLS and BFD to make me wonder if the document was liasioned to MPLS = WG.
  • List of acronyms is missing - PLR, OIR, LOS, AIS, etc.
  • Introduc= tion. I think that for "planned link or node failure" MBB is more= efficient and useful than FRR. But MBB is not being mentioned in the docum= ent.
  • Introduction. "A correlated failure is the simultaneous o= ccurrence of two or more failures." Personally, as correlated events I= consider events with cause-effect relationship.
  • Introduction. Path= restoration after FRR discussion does not appear logical, in the scope of = benchmarking document.
  • Document Scope. "Protection from Bi-dir= ectional Forwarding Detection (BFD) is outside the scope of this document.&= quot; I frankly couldn't decode this sentense.
  • Document Scope. Sev= eral references to Path Restoration as Re-optimization - doubt that it belo= ngs in the document at all.
  • Sections 6.1.1 through 6.2.4 - what is= relevance of listing numbers of labels in the stack?
  • Peerformance = of control plane should be outside of the scope of benchmarking as it is en= d-to-end metrics, not explicitly of DUT.
 
 
Regards,
        Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF135501CCB6CEUSAACMS0715e_-- From skraza@cisco.com Mon Mar 12 13:29:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FA621F88D8 for ; Mon, 12 Mar 2012 13:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.417 X-Spam-Level: X-Spam-Status: No, score=-9.417 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36WXOAKO4Spf for ; Mon, 12 Mar 2012 13:29:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7648021F871D for ; Mon, 12 Mar 2012 13:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=9926; q=dns/txt; s=iport; t=1331584153; x=1332793753; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=a+olvvFEPpXXmPPHp+nxyEP2ClvAS/mMC7NYtQ3s0mE=; b=mxDuyoJRtumBpeX9DL07uOdh7JUTAkvIcFkCsLE2QOcLAzfb/9YbYub5 DKpyKeaP4NFV+ToRVAk3d0bB6RTNFPS+reVoH+Rl68YTaB5deEt2Mx+rZ PcTVrOKsm/aSm7YtY8pLjr+KmqhFM0v9lnbPBKX9vnpBgDJJTrIhUN/ma c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMtbXk+tJXHA/2dsb2JhbAA5BwO1U4EHggkBAQEDAQEBAQ8BJwIBGBEICwUHBgEIEQQBAQEnKAYfCQgCBAENBSKHYwULnQoBnn2JRGiDLoMnBIhUjHiLK4R4gwGBPg X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="65803617" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2012 20:29:13 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2CKTCoT024122; Mon, 12 Mar 2012 20:29:12 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 15:29:12 -0500 Received: from 10.65.83.47 ([10.65.83.47]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Mar 2012 20:29:12 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 12 Mar 2012 16:29:31 -0500 From: Kamran Raza To: "Dutta, Pranjal K (Pranjal)" , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8A= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2012 20:29:12.0896 (UTC) FILETIME=[C9769400:01CD008E] Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:29:14 -0000 Pranjal, > I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP address, let alone "routable" address. Does it ? RF 5036, section 2.2.2.: "The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR. " The implementations took easy way out and started using it as: i) an IPv4 address, and ii) an address that is routable While one can try to justify this interpretation for IPv4, not sure how can we justify this for IPv6. As I had said earlier, transport connection endpoints and/or targeted hello destinations should be discovered through other LDP protocol/cfg means, instead of "infering" it from LSR-ID part of LDP-Identifier. My 2 cents. On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" wrote: > > Rajeev, > > Not really. There are applications that auto-instantiate T-LDP sessions. > You know transport address only after exchanging hellos. First hellos need > to be sent to right remote LSR-ID. We don't run another discovery protocol > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you > suggesting that all such applications are irrelevant and needs to be wiped > out from deployments. I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". > > Cheers, > Pranjal > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rajiv > Asati (rajiva) > Sent: Monday, March 12, 2012 7:06 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, Mustapha, Wim, > >> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to >> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >> LDP has to auto-create targeted sessions. We can't force to set-up > another >> ip4 network just for some applications. It won't be possible to map 4 > byte ldp > > I hope that we are not misunderstanding 32-bit integer value in RouterID > in an IPv6-only router to mean having IPv4 network. > Also, such applications must use 'transport IP address', not the > Router-ID when it comes to setting up the session. If they don't, then > they are incorrect and must be fixed. > > Cheers, > Rajiv > >> -----Original Message----- >> From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] >> Sent: Friday, March 02, 2012 12:02 PM >> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Rajiv, >> We shouldn't be ruling out the fact that there are some > differences in >> applications of LDP compared to OSPF or BGP. If we have IPV6 only > transport >> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to >> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >> LDP has to auto-create targeted sessions. We can't force to set-up > another >> ip4 network just for some applications. It won't be possible to map 4 > byte ldp >> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > is must >> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > and better >> to add it now. >> >> Thanks, >> Pranjal >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Henderickx, Wim (Wim) >> Sent: Friday, March 02, 2012 12:41 AM >> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Rajiv, >> >> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >> should look at the future to get to IPv6 only networks and as such it > will be >> required. So we are now at a point where we should add this option in > all >> protocols. Since LDP for Ipv6 is open we need to add it now. >> >> My 2 cents >> >> Cheers, >> Wim >> >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: vrijdag 2 maart 2012 8:08 >> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Hi Wim, >> >> That's a reasonable point, but no such proposal has been made for > other >> protocols. In fact, IPv6 deployments have already accommodated 4-octet >> router-id for routing protocols (which was also a departure from the >> common practice in IPv4 realm). As Mark T and I discussed in the >> previous email, the router-id consistency across protocols would be an >> operational benefit. >> >> Focusing on the technicalities, Router ID is meant to ensure the >> uniqueness of the router within the network while following the >> protocol, so are we thinking that 4-octet is not good enough to ensure >> the uniqueness? If so, then it would be worth having that discussion > in >> the Routing and Internet areas that have been focusing on IPv6 at > large. >> >> >> While I do agree to 128-bit future expandability as a benefit, the >> benefit would be trivial (at the expense of message structure changes) >> if we expanded it for the sake of it, but didn't address the root of > the >> problem. >> >> Do you think otherwise? >> >> Cheers, >> Rajiv >> >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >>> Sent: Friday, March 02, 2012 1:42 AM >>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Rajiv, I believe we need to provide both options to ensure both are >> possible. >>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >> it in the >>> future. >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Rajiv Asati (rajiva) >>> Sent: vrijdag 2 maart 2012 7:39 >>> To: mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Hi Mark, >>> >>> Well said. >>> >>> I take that we are in agreement wrt 4-octet entity for LDP router-id >> in >>> the context of IPv6, as specified. >>> >>> Cheers, >>> Rajiv >>> >>>> -----Original Message----- >>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>> Sent: Friday, March 02, 2012 1:31 AM >>>> To: Rajiv Asati (rajiva) >>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>> lizhong.jin@zte.com.cn; >>>> vishwas.ietf@gmail.com >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>> wrote: >>>> >>>>> In the past, implementations provided the router-id CLI >>>>> for any interface IPv4 address to be chosen as router-id >>>>> for various protocols including LDP. >>>> >>>>> However, many implementations already evolved the CLI to >>>>> not even give an "interface" IP address for router-id, >>>>> to accommodate IPv6. Almost all deployed networks >>>>> already accommodated that. >>>> >>>> We do operate some implementations today that "still" allow >>>> you to specify the Router-ID for various protocols as an >>>> independent 32-bit integer (only), and also allow you to >>>> define the LSR-ID for LDP as an interface (only). This is >>>> current, shipping 2012 code. >>>> >>>> So both scenarios you mention above are still much in play >>>> today. Whether operators are using them or not (I know we >>>> are) is another matter entirely. >>>> >>>>> Now that LDP is being enhanced to use IPv6, >>>>> implementations could evolve LDP router-id as well to >>>>> accommodate IPv6. This would make LDP router-id to be >>>>> consistent with other protocols delving with IPv6. And >>>>> this can certainly be operationally beneficial from IPv6 >>>>> POV. >>>> >>>> Agree. >>>> >>>>> In fact, one of the implementations allow the router-id >>>>> to be configured just once and let all protocols just >>>>> use it, if they wanted. >>>> >>>> Yes, we operate some implementations that use this method >>>> too. It's quite elegant, in that you configure once and >>>> forget. Other implementations that are more structured means >>>> operators could easily forget to specify the Router-ID for a >>>> particular protocol, for better or worse. >>>> >>>> Cheers, >>>> >>>> Mark. >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From pranjal.dutta@alcatel-lucent.com Mon Mar 12 13:34:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7723111E80A0 for ; Mon, 12 Mar 2012 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.371 X-Spam-Level: X-Spam-Status: No, score=-9.371 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLUDzgIs2J7T for ; Mon, 12 Mar 2012 13:34:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 43ED911E80B3 for ; Mon, 12 Mar 2012 13:34:29 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2CKYHAZ017198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 15:34:19 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CKYEdc002531 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 02:04:15 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 13 Mar 2012 02:04:14 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Tue, 13 Mar 2012 02:04:11 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8AAAAnr8A== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:34:30 -0000 Hi Kamran, I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be rou= table) then you can't say the following as mandate. "As I had said earlier, transport connection endpoints and/or targeted hell= o destinations should be discovered through other LDP protocol/cfg means, instead of "infering" it from LSR-ID part of LDP-Identifier." Cheers, Pranjal -----Original Message----- From: Kamran Raza [mailto:skraza@cisco.com]=20 Sent: Monday, March 12, 2012 2:30 PM To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim)= ; mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, > I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP address, let alone "routable" address. Does it ? RF 5036, section 2.2.2.: "The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR.=20 " The implementations took easy way out and started using it as: i) an IPv4 address, and ii) an address that is routable =20 While one can try to justify this interpretation for IPv4, not sure how can we justify this for IPv6. As I had said earlier, transport connection endpoints and/or targeted hello destinations should be discovered through other LDP protocol/cfg means, instead of "infering" it from LSR-ID part of LDP-Identifier. My 2 cents. On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" wrote: >=20 > Rajeev, >=20 > Not really. There are applications that auto-instantiate T-LDP sessions. > You know transport address only after exchanging hellos. First hellos nee= d > to be sent to right remote LSR-ID. We don't run another discovery protoco= l > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you > suggesting that all such applications are irrelevant and needs to be wipe= d > out from deployments. I haven't heard of any text in RFC 5036 that says > "4 byte router-id MUST not be a routable address". >=20 > Cheers, > Pranjal=20 >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of R= ajiv > Asati (rajiva) > Sent: Monday, March 12, 2012 7:06 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, Mustapha, Wim, >=20 >> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to >> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >> LDP has to auto-create targeted sessions. We can't force to set-up > another >> ip4 network just for some applications. It won't be possible to map 4 > byte ldp >=20 > I hope that we are not misunderstanding 32-bit integer value in RouterID > in an IPv6-only router to mean having IPv4 network. > Also, such applications must use 'transport IP address', not the > Router-ID when it comes to setting up the session. If they don't, then > they are incorrect and must be fixed. >=20 > Cheers, > Rajiv >=20 >> -----Original Message----- >> From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] >> Sent: Friday, March 02, 2012 12:02 PM >> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>=20 >> Rajiv, >> We shouldn't be ruling out the fact that there are some > differences in >> applications of LDP compared to OSPF or BGP. If we have IPV6 only > transport >> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has > to >> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >> LDP has to auto-create targeted sessions. We can't force to set-up > another >> ip4 network just for some applications. It won't be possible to map 4 > byte ldp >> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > is must >> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > and better >> to add it now. >>=20 >> Thanks, >> Pranjal >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of >> Henderickx, Wim (Wim) >> Sent: Friday, March 02, 2012 12:41 AM >> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>=20 >> Rajiv, >>=20 >> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >> should look at the future to get to IPv6 only networks and as such it > will be >> required. So we are now at a point where we should add this option in > all >> protocols. Since LDP for Ipv6 is open we need to add it now. >>=20 >> My 2 cents >>=20 >> Cheers, >> Wim >>=20 >> -----Original Message----- >> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >> Sent: vrijdag 2 maart 2012 8:08 >> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn >> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>=20 >> Hi Wim, >>=20 >> That's a reasonable point, but no such proposal has been made for > other >> protocols. In fact, IPv6 deployments have already accommodated 4-octet >> router-id for routing protocols (which was also a departure from the >> common practice in IPv4 realm). As Mark T and I discussed in the >> previous email, the router-id consistency across protocols would be an >> operational benefit. >>=20 >> Focusing on the technicalities, Router ID is meant to ensure the >> uniqueness of the router within the network while following the >> protocol, so are we thinking that 4-octet is not good enough to ensure >> the uniqueness? If so, then it would be worth having that discussion > in >> the Routing and Internet areas that have been focusing on IPv6 at > large. >>=20 >>=20 >> While I do agree to 128-bit future expandability as a benefit, the >> benefit would be trivial (at the expense of message structure changes) >> if we expanded it for the sake of it, but didn't address the root of > the >> problem. >>=20 >> Do you think otherwise? >>=20 >> Cheers, >> Rajiv >>=20 >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >> lucent.com] >>> Sent: Friday, March 02, 2012 1:42 AM >>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> Rajiv, I believe we need to provide both options to ensure both are >> possible. >>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >> it in the >>> future. >>>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Rajiv Asati (rajiva) >>> Sent: vrijdag 2 maart 2012 7:39 >>> To: mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> Hi Mark, >>>=20 >>> Well said. >>>=20 >>> I take that we are in agreement wrt 4-octet entity for LDP router-id >> in >>> the context of IPv6, as specified. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>> -----Original Message----- >>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>> Sent: Friday, March 02, 2012 1:31 AM >>>> To: Rajiv Asati (rajiva) >>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>> lizhong.jin@zte.com.cn; >>>> vishwas.ietf@gmail.com >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>> wrote: >>>>=20 >>>>> In the past, implementations provided the router-id CLI >>>>> for any interface IPv4 address to be chosen as router-id >>>>> for various protocols including LDP. >>>>=20 >>>>> However, many implementations already evolved the CLI to >>>>> not even give an "interface" IP address for router-id, >>>>> to accommodate IPv6. Almost all deployed networks >>>>> already accommodated that. >>>>=20 >>>> We do operate some implementations today that "still" allow >>>> you to specify the Router-ID for various protocols as an >>>> independent 32-bit integer (only), and also allow you to >>>> define the LSR-ID for LDP as an interface (only). This is >>>> current, shipping 2012 code. >>>>=20 >>>> So both scenarios you mention above are still much in play >>>> today. Whether operators are using them or not (I know we >>>> are) is another matter entirely. >>>>=20 >>>>> Now that LDP is being enhanced to use IPv6, >>>>> implementations could evolve LDP router-id as well to >>>>> accommodate IPv6. This would make LDP router-id to be >>>>> consistent with other protocols delving with IPv6. And >>>>> this can certainly be operationally beneficial from IPv6 >>>>> POV. >>>>=20 >>>> Agree. >>>>=20 >>>>> In fact, one of the implementations allow the router-id >>>>> to be configured just once and let all protocols just >>>>> use it, if they wanted. >>>>=20 >>>> Yes, we operate some implementations that use this method >>>> too. It's quite elegant, in that you configure once and >>>> forget. Other implementations that are more structured means >>>> operators could easily forget to specify the Router-ID for a >>>> particular protocol, for better or worse. >>>>=20 >>>> Cheers, >>>>=20 >>>> Mark. >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From skraza@cisco.com Mon Mar 12 14:25:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5A11E8112 for ; Mon, 12 Mar 2012 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.586 X-Spam-Level: X-Spam-Status: No, score=-9.586 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc8rxaMm8J4B for ; Mon, 12 Mar 2012 14:25:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B741711E80E4 for ; Mon, 12 Mar 2012 14:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=11707; q=dns/txt; s=iport; t=1331587499; x=1332797099; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=xDN5EzYfLDCzF6KsLTUafX489x2TED3O8FjD/KrGTJw=; b=PeRMrSqqNK3fgWzu47VhJnvKgPSpvKw/xWmoB0byJu5/ub+hOwRQu7ON dGHXW3zvKkm3N4/qz3Wg6odEP7ic22yvBLuE36xTLn0vgDK+FzkQsHAtW Rcz7vDtf43acLt4E0pTetwn1EUbIzswWFOCRoMzMCjyHd5AvSeqFdLKa3 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF1pXk+tJXHB/2dsb2JhbAA5BwO1U4EHggkBAQEDAQEBAQ8BJwIBGBEICwUHBgEIEQQBAQEnKAYfCQgCBAENBSKHYwULnRMBnwCJRGiDLoMnBIhUjHiLK4R4gwGBPg X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="65819278" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2012 21:24:59 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2CLOxg8010767; Mon, 12 Mar 2012 21:24:59 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 16:24:59 -0500 Received: from 10.65.83.47 ([10.65.83.47]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Mar 2012 21:24:58 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 12 Mar 2012 17:25:17 -0500 From: Kamran Raza To: "Dutta, Pranjal K (Pranjal)" , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8AAAAnr8AAB6K0a In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2012 21:24:59.0162 (UTC) FILETIME=[93FE3FA0:01CD0096] Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:25:02 -0000 Pranjal, 1. I was not mandating anything. I'd used "should" ;-) 2. I did not find the LSR-Id description ambiguous in RFC 5036. The description clearly says it is just a 32-bit identifier; Now it is a different story that some implementation chose to interpret it as an IPv4 address (for operational-ease reasons), and other implementations had to follow in order to inter-op. In a nutshell, while I see the value of this interpretation in IPv4 env, I do not think that we need to carry forward this notion onward (which is ambiguous - according to some - to begin with). Rgds. -- Kamran On 12-03-12 3:34 PM, "Dutta, Pranjal K (Pranjal)" wrote: > Hi Kamran, > > I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be > routable) then you can't say the following as mandate. > > "As I had said earlier, transport connection endpoints and/or targeted hello > destinations should be discovered through other LDP protocol/cfg means, > instead of "infering" it from LSR-ID part of LDP-Identifier." > > Cheers, > Pranjal > > -----Original Message----- > From: Kamran Raza [mailto:skraza@cisco.com] > Sent: Monday, March 12, 2012 2:30 PM > To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > >> I haven't heard of any text in RFC 5036 that says >> "4 byte router-id MUST not be a routable address". > > At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP > address, let alone "routable" address. Does it ? > > RF 5036, section 2.2.2.: > > "The first four octets identify the LSR and must be a > globally unique value, such as a 32-bit router Id assigned to the > LSR. > " > > The implementations took easy way out and started using it as: > i) an IPv4 address, and > ii) an address that is routable > > While one can try to justify this interpretation for IPv4, not sure how can > we justify this for IPv6. > > As I had said earlier, transport connection endpoints and/or targeted hello > destinations should be discovered through other LDP protocol/cfg means, > instead of "infering" it from LSR-ID part of LDP-Identifier. > > My 2 cents. > > On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" > wrote: > >> >> Rajeev, >> >> Not really. There are applications that auto-instantiate T-LDP sessions. >> You know transport address only after exchanging hellos. First hellos need >> to be sent to right remote LSR-ID. We don't run another discovery protocol >> that says "here is the BGP next-hop X but its LSR-ID is Y". Are you >> suggesting that all such applications are irrelevant and needs to be wiped >> out from deployments. I haven't heard of any text in RFC 5036 that says >> "4 byte router-id MUST not be a routable address". >> >> Cheers, >> Pranjal >> >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rajiv >> Asati (rajiva) >> Sent: Monday, March 12, 2012 7:06 AM >> To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); >> mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Pranjal, Mustapha, Wim, >> >>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >> to >>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>> LDP has to auto-create targeted sessions. We can't force to set-up >> another >>> ip4 network just for some applications. It won't be possible to map 4 >> byte ldp >> >> I hope that we are not misunderstanding 32-bit integer value in RouterID >> in an IPv6-only router to mean having IPv4 network. >> Also, such applications must use 'transport IP address', not the >> Router-ID when it comes to setting up the session. If they don't, then >> they are incorrect and must be fixed. >> >> Cheers, >> Rajiv >> >>> -----Original Message----- >>> From: Dutta, Pranjal K (Pranjal) >> [mailto:pranjal.dutta@alcatel-lucent.com] >>> Sent: Friday, March 02, 2012 12:02 PM >>> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); >> mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Rajiv, >>> We shouldn't be ruling out the fact that there are some >> differences in >>> applications of LDP compared to OSPF or BGP. If we have IPV6 only >> transport >>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >> to >>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>> LDP has to auto-create targeted sessions. We can't force to set-up >> another >>> ip4 network just for some applications. It won't be possible to map 4 >> byte ldp >>> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID >> is must >>> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility >> and better >>> to add it now. >>> >>> Thanks, >>> Pranjal >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Henderickx, Wim (Wim) >>> Sent: Friday, March 02, 2012 12:41 AM >>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Rajiv, >>> >>> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >>> should look at the future to get to IPv6 only networks and as such it >> will be >>> required. So we are now at a point where we should add this option in >> all >>> protocols. Since LDP for Ipv6 is open we need to add it now. >>> >>> My 2 cents >>> >>> Cheers, >>> Wim >>> >>> -----Original Message----- >>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>> Sent: vrijdag 2 maart 2012 8:08 >>> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Hi Wim, >>> >>> That's a reasonable point, but no such proposal has been made for >> other >>> protocols. In fact, IPv6 deployments have already accommodated 4-octet >>> router-id for routing protocols (which was also a departure from the >>> common practice in IPv4 realm). As Mark T and I discussed in the >>> previous email, the router-id consistency across protocols would be an >>> operational benefit. >>> >>> Focusing on the technicalities, Router ID is meant to ensure the >>> uniqueness of the router within the network while following the >>> protocol, so are we thinking that 4-octet is not good enough to ensure >>> the uniqueness? If so, then it would be worth having that discussion >> in >>> the Routing and Internet areas that have been focusing on IPv6 at >> large. >>> >>> >>> While I do agree to 128-bit future expandability as a benefit, the >>> benefit would be trivial (at the expense of message structure changes) >>> if we expanded it for the sake of it, but didn't address the root of >> the >>> problem. >>> >>> Do you think otherwise? >>> >>> Cheers, >>> Rajiv >>> >>>> -----Original Message----- >>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>> lucent.com] >>>> Sent: Friday, March 02, 2012 1:42 AM >>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Rajiv, I believe we need to provide both options to ensure both are >>> possible. >>>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >>> it in the >>>> future. >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Rajiv Asati (rajiva) >>>> Sent: vrijdag 2 maart 2012 7:39 >>>> To: mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Hi Mark, >>>> >>>> Well said. >>>> >>>> I take that we are in agreement wrt 4-octet entity for LDP router-id >>> in >>>> the context of IPv6, as specified. >>>> >>>> Cheers, >>>> Rajiv >>>> >>>>> -----Original Message----- >>>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>>> Sent: Friday, March 02, 2012 1:31 AM >>>>> To: Rajiv Asati (rajiva) >>>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>>> lizhong.jin@zte.com.cn; >>>>> vishwas.ietf@gmail.com >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>> >>>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>>> wrote: >>>>> >>>>>> In the past, implementations provided the router-id CLI >>>>>> for any interface IPv4 address to be chosen as router-id >>>>>> for various protocols including LDP. >>>>> >>>>>> However, many implementations already evolved the CLI to >>>>>> not even give an "interface" IP address for router-id, >>>>>> to accommodate IPv6. Almost all deployed networks >>>>>> already accommodated that. >>>>> >>>>> We do operate some implementations today that "still" allow >>>>> you to specify the Router-ID for various protocols as an >>>>> independent 32-bit integer (only), and also allow you to >>>>> define the LSR-ID for LDP as an interface (only). This is >>>>> current, shipping 2012 code. >>>>> >>>>> So both scenarios you mention above are still much in play >>>>> today. Whether operators are using them or not (I know we >>>>> are) is another matter entirely. >>>>> >>>>>> Now that LDP is being enhanced to use IPv6, >>>>>> implementations could evolve LDP router-id as well to >>>>>> accommodate IPv6. This would make LDP router-id to be >>>>>> consistent with other protocols delving with IPv6. And >>>>>> this can certainly be operationally beneficial from IPv6 >>>>>> POV. >>>>> >>>>> Agree. >>>>> >>>>>> In fact, one of the implementations allow the router-id >>>>>> to be configured just once and let all protocols just >>>>>> use it, if they wanted. >>>>> >>>>> Yes, we operate some implementations that use this method >>>>> too. It's quite elegant, in that you configure once and >>>>> forget. Other implementations that are more structured means >>>>> operators could easily forget to specify the Router-ID for a >>>>> particular protocol, for better or worse. >>>>> >>>>> Cheers, >>>>> >>>>> Mark. >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From pranjal.dutta@alcatel-lucent.com Mon Mar 12 14:53:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B820D21E80A2 for ; Mon, 12 Mar 2012 14:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.401 X-Spam-Level: X-Spam-Status: No, score=-9.401 tagged_above=-999 required=5 tests=[AWL=1.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA8Kd21sK-iV for ; Mon, 12 Mar 2012 14:53:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4221E809D for ; Mon, 12 Mar 2012 14:53:18 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q2CLr26a010458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 16:53:04 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CLqxT5012599 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 03:22:59 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 13 Mar 2012 03:22:59 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Tue, 13 Mar 2012 03:22:56 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8AAAAnr8AAB6K0aAAB7SGA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:53:21 -0000 Kamran, Let me clarify a few things. Nobody in this mailing list (including= me) ever suggested for ipv6 based LSR-ID to be made mandatory for IPV6 dep= loyments, rather suggested to add as an OPTIONAL since making the lsr-id=20 routable has been providing tremendous operational simplicity on gluing co-= existing network applications. There are several arguments that had been pr= ovided on that in the list. You are right while saying as below: The implementations took easy way out and started using it as: > i) an IPv4 address, and > ii) an address that is routable Yes, it makes lot of things easy and such implementations have been providi= ng lot of operational benefits to operators in various deployed solutions.= =20 We are working towards progressing a technology and decision should be = based on what makes operationally more sensible, rather than going by just = puritanical references alone. RFC 5036 never says that its procedures shoul= d never be extended. We have done numerous extensions to LDP in several oth= er drafts/RFCs post RFC 3036/5036. Let's assume for now that as per your vi= ew RFC 5036 is super-perfect and there is no ambiguity, then still I won't = keep a dogmatic view of RFC 5036 and would go ahead and vote for IPV6 based= LSR-ID (LDP v2). Such judgment is based on operational benefits its going = to incur for a huge bunch of network applications when deployed in IPV6 onl= y networks. Then what surprises me is that why we are so resistive when we are suggesting 16 byte LSR-ID as OPTIONAL method for IPV6 deployments? =20 Does any inter-operability breaks by keeping ipv6 based LSR-ID as OPTIONAL?= =20 Cheers, Pranjal -----Original Message----- From: Kamran Raza [mailto:skraza@cisco.com]=20 Sent: Monday, March 12, 2012 3:25 PM To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim)= ; mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Pranjal, 1. I was not mandating anything. I'd used "should" ;-) 2. I did not find the LSR-Id description ambiguous in RFC 5036. The description clearly says it is just a 32-bit identifier; Now it is a different story that some implementation chose to interpret it as an IPv4 address (for operational-ease reasons), and other implementation= s had to follow in order to inter-op. In a nutshell, while I see the value of this interpretation in IPv4 env, I do not think that we need to carry forward this notion onward (which is ambiguous - according to some - to begin with). Rgds. -- Kamran On 12-03-12 3:34 PM, "Dutta, Pranjal K (Pranjal)" wrote: > Hi Kamran, >=20 > I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be > routable) then you can't say the following as mandate. >=20 > "As I had said earlier, transport connection endpoints and/or targeted he= llo > destinations should be discovered through other LDP protocol/cfg means, > instead of "infering" it from LSR-ID part of LDP-Identifier." >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: Kamran Raza [mailto:skraza@cisco.com] > Sent: Monday, March 12, 2012 2:30 PM > To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wi= m); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 >> I haven't heard of any text in RFC 5036 that says >> "4 byte router-id MUST not be a routable address". >=20 > At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP > address, let alone "routable" address. Does it ? >=20 > RF 5036, section 2.2.2.: >=20 > "The first four octets identify the LSR and must be a > globally unique value, such as a 32-bit router Id assigned to the > LSR.=20 > " >=20 > The implementations took easy way out and started using it as: > i) an IPv4 address, and > ii) an address that is routable > =20 > While one can try to justify this interpretation for IPv4, not sure how c= an > we justify this for IPv6. >=20 > As I had said earlier, transport connection endpoints and/or targeted hel= lo > destinations should be discovered through other LDP protocol/cfg means, > instead of "infering" it from LSR-ID part of LDP-Identifier. >=20 > My 2 cents. >=20 > On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" > wrote: >=20 >>=20 >> Rajeev, >>=20 >> Not really. There are applications that auto-instantiate T-LDP sessions. >> You know transport address only after exchanging hellos. First hellos ne= ed >> to be sent to right remote LSR-ID. We don't run another discovery protoc= ol >> that says "here is the BGP next-hop X but its LSR-ID is Y". Are you >> suggesting that all such applications are irrelevant and needs to be wip= ed >> out from deployments. I haven't heard of any text in RFC 5036 that says >> "4 byte router-id MUST not be a routable address". >>=20 >> Cheers, >> Pranjal=20 >>=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Rajiv >> Asati (rajiva) >> Sent: Monday, March 12, 2012 7:06 AM >> To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); >> mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>=20 >> Pranjal, Mustapha, Wim, >>=20 >>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >> to >>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>> LDP has to auto-create targeted sessions. We can't force to set-up >> another >>> ip4 network just for some applications. It won't be possible to map 4 >> byte ldp >>=20 >> I hope that we are not misunderstanding 32-bit integer value in RouterID >> in an IPv6-only router to mean having IPv4 network. >> Also, such applications must use 'transport IP address', not the >> Router-ID when it comes to setting up the session. If they don't, then >> they are incorrect and must be fixed. >>=20 >> Cheers, >> Rajiv >>=20 >>> -----Original Message----- >>> From: Dutta, Pranjal K (Pranjal) >> [mailto:pranjal.dutta@alcatel-lucent.com] >>> Sent: Friday, March 02, 2012 12:02 PM >>> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); >> mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> Rajiv, >>> We shouldn't be ruling out the fact that there are some >> differences in >>> applications of LDP compared to OSPF or BGP. If we have IPV6 only >> transport >>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >> to >>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>> LDP has to auto-create targeted sessions. We can't force to set-up >> another >>> ip4 network just for some applications. It won't be possible to map 4 >> byte ldp >>> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID >> is must >>> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility >> and better >>> to add it now. >>>=20 >>> Thanks, >>> Pranjal >>>=20 >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> Of >>> Henderickx, Wim (Wim) >>> Sent: Friday, March 02, 2012 12:41 AM >>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> Rajiv, >>>=20 >>> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >>> should look at the future to get to IPv6 only networks and as such it >> will be >>> required. So we are now at a point where we should add this option in >> all >>> protocols. Since LDP for Ipv6 is open we need to add it now. >>>=20 >>> My 2 cents >>>=20 >>> Cheers, >>> Wim >>>=20 >>> -----Original Message----- >>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>> Sent: vrijdag 2 maart 2012 8:08 >>> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >> lizhong.jin@zte.com.cn >>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>=20 >>> Hi Wim, >>>=20 >>> That's a reasonable point, but no such proposal has been made for >> other >>> protocols. In fact, IPv6 deployments have already accommodated 4-octet >>> router-id for routing protocols (which was also a departure from the >>> common practice in IPv4 realm). As Mark T and I discussed in the >>> previous email, the router-id consistency across protocols would be an >>> operational benefit. >>>=20 >>> Focusing on the technicalities, Router ID is meant to ensure the >>> uniqueness of the router within the network while following the >>> protocol, so are we thinking that 4-octet is not good enough to ensure >>> the uniqueness? If so, then it would be worth having that discussion >> in >>> the Routing and Internet areas that have been focusing on IPv6 at >> large. >>>=20 >>>=20 >>> While I do agree to 128-bit future expandability as a benefit, the >>> benefit would be trivial (at the expense of message structure changes) >>> if we expanded it for the sake of it, but didn't address the root of >> the >>> problem. >>>=20 >>> Do you think otherwise? >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>> -----Original Message----- >>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>> lucent.com] >>>> Sent: Friday, March 02, 2012 1:42 AM >>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>> Rajiv, I believe we need to provide both options to ensure both are >>> possible. >>>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >>> it in the >>>> future. >>>>=20 >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Rajiv Asati (rajiva) >>>> Sent: vrijdag 2 maart 2012 7:39 >>>> To: mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>=20 >>>> Hi Mark, >>>>=20 >>>> Well said. >>>>=20 >>>> I take that we are in agreement wrt 4-octet entity for LDP router-id >>> in >>>> the context of IPv6, as specified. >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>>> -----Original Message----- >>>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>>> Sent: Friday, March 02, 2012 1:31 AM >>>>> To: Rajiv Asati (rajiva) >>>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>>> lizhong.jin@zte.com.cn; >>>>> vishwas.ietf@gmail.com >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>>=20 >>>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>>> wrote: >>>>>=20 >>>>>> In the past, implementations provided the router-id CLI >>>>>> for any interface IPv4 address to be chosen as router-id >>>>>> for various protocols including LDP. >>>>>=20 >>>>>> However, many implementations already evolved the CLI to >>>>>> not even give an "interface" IP address for router-id, >>>>>> to accommodate IPv6. Almost all deployed networks >>>>>> already accommodated that. >>>>>=20 >>>>> We do operate some implementations today that "still" allow >>>>> you to specify the Router-ID for various protocols as an >>>>> independent 32-bit integer (only), and also allow you to >>>>> define the LSR-ID for LDP as an interface (only). This is >>>>> current, shipping 2012 code. >>>>>=20 >>>>> So both scenarios you mention above are still much in play >>>>> today. Whether operators are using them or not (I know we >>>>> are) is another matter entirely. >>>>>=20 >>>>>> Now that LDP is being enhanced to use IPv6, >>>>>> implementations could evolve LDP router-id as well to >>>>>> accommodate IPv6. This would make LDP router-id to be >>>>>> consistent with other protocols delving with IPv6. And >>>>>> this can certainly be operationally beneficial from IPv6 >>>>>> POV. >>>>>=20 >>>>> Agree. >>>>>=20 >>>>>> In fact, one of the implementations allow the router-id >>>>>> to be configured just once and let all protocols just >>>>>> use it, if they wanted. >>>>>=20 >>>>> Yes, we operate some implementations that use this method >>>>> too. It's quite elegant, in that you configure once and >>>>> forget. Other implementations that are more structured means >>>>> operators could easily forget to specify the Router-ID for a >>>>> particular protocol, for better or worse. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Mark. >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From adrian@olddog.co.uk Mon Mar 12 15:07:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711221E811B; Mon, 12 Mar 2012 15:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5h7IGpC0lXt; Mon, 12 Mar 2012 15:07:35 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BB52D21E8127; Mon, 12 Mar 2012 15:07:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2CM7Xqh026322; Mon, 12 Mar 2012 22:07:33 GMT Received: from 950129200 ([90.84.144.248]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q2CM7O0I026241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Mar 2012 22:07:31 GMT From: "Adrian Farrel" To: , Date: Mon, 12 Mar 2012 22:07:26 -0000 Message-ID: <037301cd009c$86ea4290$94bec7b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0374_01CD009C.86F16E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0AmstwFklFNpkJSWmctiWPHNLZ7A== Content-Language: en-gb Subject: [mpls] heads up: Requirements for IP/MPLS network transmission interruption duration X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:07:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0374_01CD009C.86F16E80 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Discussion should probably go to the Ops Area Working Group list. =20 Adrian =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of fanpeng Sent: 12 March 2012 15:24 To: opsawg@ietf.org; 'Bradner, Scott'; ietf@cdl.asgaard.org; melinda.shore@gmail.com Cc: =C0=EE=C1=AC=D4=B4 Subject: [OPSAWG] Requirements for IP/MPLS network transmission = interruption duration =20 Greetings all, =20 We have recently submitted a draft on transmission interruption duration (draft-fan-opsawg-transmission-interuption-00 ). We felt it necessary to make requirements for the interruption duration = since there is no consensus on it yet in the industry. We primarily analyzed interruption criteria for softswitch voice, and research on LTE backhaul = and other kinds of service scenarios has been in progress. =20 We would like to hear from you feedbacks about this draft, e.g. whether = or not there should be such requirements or methodology for the analysis. Any = comment on it will be appreciated. =20 The following is a brief introduction: =20 Today's IP/MPLS network is widely used as a bearing network to carry = diversified packet switched services. The transmission qualities of these services = are closely related to the performance of bearing layers, as network = failure, delay, congestion and other abnormities will inevitably bring about service interruption and user perception degradation. However, there is no = consensus in the industry on transmission interruption for IP/MPLS network up to now. = This memo studies relationships between service performance and transmission interruption duration in several scenarios, and is intended to reach a = list of requirements for these interruption duration criteria. =20 =20 Best regards, =20 =20 Fan Peng ------=_NextPart_000_0374_01CD009C.86F16E80 Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

Discussion should probably go to the Ops Area = Working Group list.

 

Adrian

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] = On Behalf Of fanpeng
Sent: 12 March 2012 = 15:24
To: opsawg@ietf.org; 'Bradner, Scott'; = ietf@cdl.asgaard.org; melinda.shore@gmail.com
Cc: =C0=EE=C1=AC=D4=B4
Subject: [OPSAWG] Requirements for IP/MPLS = network transmission interruption = duration

 

Greetings all,

 

We have recently submitted a draft on = transmission interruption duration (draft-fan-opsawg-transmission-interuption-00). We felt it necessary = to make requirements for the interruption duration since there is no = consensus on it yet in the industry. We primarily analyzed interruption = criteria for softswitch voice, and research on LTE backhaul and other = kinds of service scenarios has been in progress.

 

We would like to hear from you = feedbacks about this draft, e.g. whether or not there should be such = requirements or methodology for the analysis. Any comment on it will be = appreciated.

 

The following is a brief = introduction:

 

Today's IP/MPLS network is = widely used as a bearing network to carry diversified packet switched = services. The transmission qualities of these services are closely = related to the performance of bearing layers, as network failure, delay, = congestion and other abnormities will inevitably bring about service = interruption and user perception degradation. However, there is no = consensus in the industry on transmission interruption for IP/MPLS = network up to now.  This memo studies relationships between service = performance and transmission interruption duration in several scenarios, = and is intended to reach a list of requirements for these interruption = duration criteria.

 

 

Best = regards,           = ;            =           =

 

Fan = Peng

------=_NextPart_000_0374_01CD009C.86F16E80-- From skraza@cisco.com Mon Mar 12 15:13:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6899021F890C for ; Mon, 12 Mar 2012 15:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.713 X-Spam-Level: X-Spam-Status: No, score=-9.713 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbVnHvQKL2r0 for ; Mon, 12 Mar 2012 15:13:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2021F896B for ; Mon, 12 Mar 2012 15:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=14658; q=dns/txt; s=iport; t=1331590420; x=1332800020; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=tm5GZuCXxdbq/Aonxy+SbINiWdhBqqKPdYMllQr3gR0=; b=GIEiJeOjH4x1coVriLqqgQDJ1u8p9eAYZPOETrmpNjrHj+7qyvLBbxJb JjgCfyEmhQQG1AHdebhEsFC8bjMRD2Mn105M4WMG+B8w6maC51U1ZX0SS 2TrUMPjdwdxrMJjKEPOO0+Cr62NOg8No8XIlM/QQY8WteX7FJ1nlWdYy4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALpzXk+tJXG//2dsb2JhbAA5BwO1VYEHggkBAQEDAQEBAQ8BJwIBGBEICwUHBgEIEQQBAQEnKAYfCQgCBAENBRsHh2MFC50HAZ8DiURogy6DJwSIVIx4iyuEeIMBgT4 X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208";a="65818164" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2012 22:13:40 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CMDear004437; Mon, 12 Mar 2012 22:13:40 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 17:13:40 -0500 Received: from 10.65.83.47 ([10.65.83.47]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Mar 2012 22:13:39 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 12 Mar 2012 18:13:58 -0500 From: Kamran Raza To: "Dutta, Pranjal K (Pranjal)" , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Message-ID: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8AAAAnr8AAB6K0aAAB7SGAAATf7ww== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2012 22:13:40.0281 (UTC) FILETIME=[611DA290:01CD009D] Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:13:42 -0000 As I understand, all this LSR-Id discussion is in the context of establishing/maintaining separate LDP sessions for IPv4 and IPv6. [ Please correct me if I am mistaken, or have missed something else in this lllong email thread ]. If this understanding holds, then Let's park this debate until we first close on the other more significant item regarding separate LDP sessions for IPv4 and IPv6. Rgds. On 12-03-12 4:52 PM, "Dutta, Pranjal K (Pranjal)" wrote: > Kamran, > Let me clarify a few things. Nobody in this mailing list (including > me) ever suggested for ipv6 based LSR-ID to be made mandatory for IPV6 > deployments, rather suggested to add as an OPTIONAL since making the lsr-id > routable has been providing tremendous operational simplicity on gluing > co-existing network applications. There are several arguments that had been > provided on that in the list. You are right while saying as below: > > The implementations took easy way out and started using it as: >> i) an IPv4 address, and >> ii) an address that is routable > > Yes, it makes lot of things easy and such implementations have been providing > lot of operational benefits to operators in various deployed solutions. > > We are working towards progressing a technology and decision should be > based on what makes operationally more sensible, rather than going by just > puritanical references alone. RFC 5036 never says that its procedures should > never be extended. We have done numerous extensions to LDP in several other > drafts/RFCs post RFC 3036/5036. Let's assume for now that as per your view RFC > 5036 is super-perfect and there is no ambiguity, then still I won't keep a > dogmatic view of RFC 5036 and would go ahead and vote for IPV6 based LSR-ID > (LDP v2). Such judgment is based on operational benefits its going to incur > for a huge bunch of network applications when deployed in IPV6 only networks. > Then what surprises me is that why we are so resistive when we > are suggesting 16 byte LSR-ID as OPTIONAL method for IPV6 deployments? > Does any inter-operability breaks by keeping ipv6 based LSR-ID as OPTIONAL? > > Cheers, > Pranjal > > -----Original Message----- > From: Kamran Raza [mailto:skraza@cisco.com] > Sent: Monday, March 12, 2012 3:25 PM > To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > > 1. I was not mandating anything. I'd used "should" ;-) > > 2. I did not find the LSR-Id description ambiguous in RFC 5036. > The description clearly says it is just a 32-bit identifier; > Now it is a different story that some implementation chose to interpret it > as an IPv4 address (for operational-ease reasons), and other implementations > had to follow in order to inter-op. > > In a nutshell, while I see the value of this interpretation in IPv4 env, I > do not think that we need to carry forward this notion onward (which is > ambiguous - according to some - to begin with). > > Rgds. > > -- Kamran > > On 12-03-12 3:34 PM, "Dutta, Pranjal K (Pranjal)" > wrote: > >> Hi Kamran, >> >> I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be >> routable) then you can't say the following as mandate. >> >> "As I had said earlier, transport connection endpoints and/or targeted hello >> destinations should be discovered through other LDP protocol/cfg means, >> instead of "infering" it from LSR-ID part of LDP-Identifier." >> >> Cheers, >> Pranjal >> >> -----Original Message----- >> From: Kamran Raza [mailto:skraza@cisco.com] >> Sent: Monday, March 12, 2012 2:30 PM >> To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim); >> mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Pranjal, >> >>> I haven't heard of any text in RFC 5036 that says >>> "4 byte router-id MUST not be a routable address". >> >> At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP >> address, let alone "routable" address. Does it ? >> >> RF 5036, section 2.2.2.: >> >> "The first four octets identify the LSR and must be a >> globally unique value, such as a 32-bit router Id assigned to the >> LSR. >> " >> >> The implementations took easy way out and started using it as: >> i) an IPv4 address, and >> ii) an address that is routable >> >> While one can try to justify this interpretation for IPv4, not sure how can >> we justify this for IPv6. >> >> As I had said earlier, transport connection endpoints and/or targeted hello >> destinations should be discovered through other LDP protocol/cfg means, >> instead of "infering" it from LSR-ID part of LDP-Identifier. >> >> My 2 cents. >> >> On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" >> wrote: >> >>> >>> Rajeev, >>> >>> Not really. There are applications that auto-instantiate T-LDP sessions. >>> You know transport address only after exchanging hellos. First hellos need >>> to be sent to right remote LSR-ID. We don't run another discovery protocol >>> that says "here is the BGP next-hop X but its LSR-ID is Y". Are you >>> suggesting that all such applications are irrelevant and needs to be wiped >>> out from deployments. I haven't heard of any text in RFC 5036 that says >>> "4 byte router-id MUST not be a routable address". >>> >>> Cheers, >>> Pranjal >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Rajiv >>> Asati (rajiva) >>> Sent: Monday, March 12, 2012 7:06 AM >>> To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); >>> mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Pranjal, Mustapha, Wim, >>> >>>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >>> to >>>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>>> LDP has to auto-create targeted sessions. We can't force to set-up >>> another >>>> ip4 network just for some applications. It won't be possible to map 4 >>> byte ldp >>> >>> I hope that we are not misunderstanding 32-bit integer value in RouterID >>> in an IPv6-only router to mean having IPv4 network. >>> Also, such applications must use 'transport IP address', not the >>> Router-ID when it comes to setting up the session. If they don't, then >>> they are incorrect and must be fixed. >>> >>> Cheers, >>> Rajiv >>> >>>> -----Original Message----- >>>> From: Dutta, Pranjal K (Pranjal) >>> [mailto:pranjal.dutta@alcatel-lucent.com] >>>> Sent: Friday, March 02, 2012 12:02 PM >>>> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); >>> mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Rajiv, >>>> We shouldn't be ruling out the fact that there are some >>> differences in >>>> applications of LDP compared to OSPF or BGP. If we have IPV6 only >>> transport >>>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >>> to >>>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>>> LDP has to auto-create targeted sessions. We can't force to set-up >>> another >>>> ip4 network just for some applications. It won't be possible to map 4 >>> byte ldp >>>> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID >>> is must >>>> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility >>> and better >>>> to add it now. >>>> >>>> Thanks, >>>> Pranjal >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Henderickx, Wim (Wim) >>>> Sent: Friday, March 02, 2012 12:41 AM >>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Rajiv, >>>> >>>> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >>>> should look at the future to get to IPv6 only networks and as such it >>> will be >>>> required. So we are now at a point where we should add this option in >>> all >>>> protocols. Since LDP for Ipv6 is open we need to add it now. >>>> >>>> My 2 cents >>>> >>>> Cheers, >>>> Wim >>>> >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>>> Sent: vrijdag 2 maart 2012 8:08 >>>> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Hi Wim, >>>> >>>> That's a reasonable point, but no such proposal has been made for >>> other >>>> protocols. In fact, IPv6 deployments have already accommodated 4-octet >>>> router-id for routing protocols (which was also a departure from the >>>> common practice in IPv4 realm). As Mark T and I discussed in the >>>> previous email, the router-id consistency across protocols would be an >>>> operational benefit. >>>> >>>> Focusing on the technicalities, Router ID is meant to ensure the >>>> uniqueness of the router within the network while following the >>>> protocol, so are we thinking that 4-octet is not good enough to ensure >>>> the uniqueness? If so, then it would be worth having that discussion >>> in >>>> the Routing and Internet areas that have been focusing on IPv6 at >>> large. >>>> >>>> >>>> While I do agree to 128-bit future expandability as a benefit, the >>>> benefit would be trivial (at the expense of message structure changes) >>>> if we expanded it for the sake of it, but didn't address the root of >>> the >>>> problem. >>>> >>>> Do you think otherwise? >>>> >>>> Cheers, >>>> Rajiv >>>> >>>>> -----Original Message----- >>>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>>> lucent.com] >>>>> Sent: Friday, March 02, 2012 1:42 AM >>>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>>> lizhong.jin@zte.com.cn >>>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>> >>>>> Rajiv, I believe we need to provide both options to ensure both are >>>> possible. >>>>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >>>> it in the >>>>> future. >>>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>> Of >>>>> Rajiv Asati (rajiva) >>>>> Sent: vrijdag 2 maart 2012 7:39 >>>>> To: mtinka@globaltransit.net >>>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>>> lizhong.jin@zte.com.cn >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>> >>>>> Hi Mark, >>>>> >>>>> Well said. >>>>> >>>>> I take that we are in agreement wrt 4-octet entity for LDP router-id >>>> in >>>>> the context of IPv6, as specified. >>>>> >>>>> Cheers, >>>>> Rajiv >>>>> >>>>>> -----Original Message----- >>>>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>>>> Sent: Friday, March 02, 2012 1:31 AM >>>>>> To: Rajiv Asati (rajiva) >>>>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>>>> lizhong.jin@zte.com.cn; >>>>>> vishwas.ietf@gmail.com >>>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>>> >>>>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>>>> wrote: >>>>>> >>>>>>> In the past, implementations provided the router-id CLI >>>>>>> for any interface IPv4 address to be chosen as router-id >>>>>>> for various protocols including LDP. >>>>>> >>>>>>> However, many implementations already evolved the CLI to >>>>>>> not even give an "interface" IP address for router-id, >>>>>>> to accommodate IPv6. Almost all deployed networks >>>>>>> already accommodated that. >>>>>> >>>>>> We do operate some implementations today that "still" allow >>>>>> you to specify the Router-ID for various protocols as an >>>>>> independent 32-bit integer (only), and also allow you to >>>>>> define the LSR-ID for LDP as an interface (only). This is >>>>>> current, shipping 2012 code. >>>>>> >>>>>> So both scenarios you mention above are still much in play >>>>>> today. Whether operators are using them or not (I know we >>>>>> are) is another matter entirely. >>>>>> >>>>>>> Now that LDP is being enhanced to use IPv6, >>>>>>> implementations could evolve LDP router-id as well to >>>>>>> accommodate IPv6. This would make LDP router-id to be >>>>>>> consistent with other protocols delving with IPv6. And >>>>>>> this can certainly be operationally beneficial from IPv6 >>>>>>> POV. >>>>>> >>>>>> Agree. >>>>>> >>>>>>> In fact, one of the implementations allow the router-id >>>>>>> to be configured just once and let all protocols just >>>>>>> use it, if they wanted. >>>>>> >>>>>> Yes, we operate some implementations that use this method >>>>>> too. It's quite elegant, in that you configure once and >>>>>> forget. Other implementations that are more structured means >>>>>> operators could easily forget to specify the Router-ID for a >>>>>> particular protocol, for better or worse. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mark. >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From pranjal.dutta@alcatel-lucent.com Mon Mar 12 15:28:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27B921F8844 for ; Mon, 12 Mar 2012 15:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.43 X-Spam-Level: X-Spam-Status: No, score=-7.43 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly2tUmJjbglQ for ; Mon, 12 Mar 2012 15:28:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65121F881E for ; Mon, 12 Mar 2012 15:28:39 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2CMSPxf016936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Mar 2012 17:28:27 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2CMSNj6013375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 03:58:24 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 13 Mar 2012 03:58:23 +0530 From: "Dutta, Pranjal K (Pranjal)" To: Kamran Raza , "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Tue, 13 Mar 2012 03:58:21 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAAf8G8AAAAnr8AAB6K0aAAB7SGAAATf7wwAAWw+Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:28:50 -0000 It is not completely attached to fate separation subject although it is an = inherent component for fate separation. If a network is ipv6 transport only= then IPV6 based LSR-ID provides lot of operational simplicity in various s= olutions, even though operator may have no strong case for fate separation. Cheers, Pranjal -----Original Message----- From: Kamran Raza [mailto:skraza@cisco.com] Sent: Monday, March 12, 2012 4:14 PM To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wim)= ; mtinka@globaltransit.net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 As I understand, all this LSR-Id discussion is in the context of establishing/maintaining separate LDP sessions for IPv4 and IPv6. [ Please correct me if I am mistaken, or have missed something else in this lllong email thread ]. If this understanding holds, then Let's park this debate until we first close on the other more significant item regarding separate LDP sessions fo= r IPv4 and IPv6. Rgds. On 12-03-12 4:52 PM, "Dutta, Pranjal K (Pranjal)" wrote: > Kamran, > Let me clarify a few things. Nobody in this mailing list (includi= ng > me) ever suggested for ipv6 based LSR-ID to be made mandatory for IPV6 > deployments, rather suggested to add as an OPTIONAL since making the lsr-= id > routable has been providing tremendous operational simplicity on gluing > co-existing network applications. There are several arguments that had be= en > provided on that in the list. You are right while saying as below: > > The implementations took easy way out and started using it as: >> i) an IPv4 address, and >> ii) an address that is routable > > Yes, it makes lot of things easy and such implementations have been provi= ding > lot of operational benefits to operators in various deployed solutions. > > We are working towards progressing a technology and decision should b= e > based on what makes operationally more sensible, rather than going by jus= t > puritanical references alone. RFC 5036 never says that its procedures sho= uld > never be extended. We have done numerous extensions to LDP in several oth= er > drafts/RFCs post RFC 3036/5036. Let's assume for now that as per your vie= w RFC > 5036 is super-perfect and there is no ambiguity, then still I won't keep = a > dogmatic view of RFC 5036 and would go ahead and vote for IPV6 based LSR-= ID > (LDP v2). Such judgment is based on operational benefits its going to inc= ur > for a huge bunch of network applications when deployed in IPV6 only netwo= rks. > Then what surprises me is that why we are so resistive when we > are suggesting 16 byte LSR-ID as OPTIONAL method for IPV6 deployments? > Does any inter-operability breaks by keeping ipv6 based LSR-ID as OPTIONA= L? > > Cheers, > Pranjal > > -----Original Message----- > From: Kamran Raza [mailto:skraza@cisco.com] > Sent: Monday, March 12, 2012 3:25 PM > To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (Wi= m); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Pranjal, > > 1. I was not mandating anything. I'd used "should" ;-) > > 2. I did not find the LSR-Id description ambiguous in RFC 5036. > The description clearly says it is just a 32-bit identifier; > Now it is a different story that some implementation chose to interpret i= t > as an IPv4 address (for operational-ease reasons), and other implementati= ons > had to follow in order to inter-op. > > In a nutshell, while I see the value of this interpretation in IPv4 env, = I > do not think that we need to carry forward this notion onward (which is > ambiguous - according to some - to begin with). > > Rgds. > > -- Kamran > > On 12-03-12 3:34 PM, "Dutta, Pranjal K (Pranjal)" > wrote: > >> Hi Kamran, >> >> I don't agree. When RFC 5036 is ambiguous (does not say LSR MUST NOT be >> routable) then you can't say the following as mandate. >> >> "As I had said earlier, transport connection endpoints and/or targeted h= ello >> destinations should be discovered through other LDP protocol/cfg means, >> instead of "infering" it from LSR-ID part of LDP-Identifier." >> >> Cheers, >> Pranjal >> >> -----Original Message----- >> From: Kamran Raza [mailto:skraza@cisco.com] >> Sent: Monday, March 12, 2012 2:30 PM >> To: Dutta, Pranjal K (Pranjal); Rajiv Asati (rajiva); Henderickx, Wim (W= im); >> mtinka@globaltransit.net >> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn >> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >> >> Pranjal, >> >>> I haven't heard of any text in RFC 5036 that says >>> "4 byte router-id MUST not be a routable address". >> >> At the same time, the RFC 5036 does not specify 4 byte LSR-Id as an IP >> address, let alone "routable" address. Does it ? >> >> RF 5036, section 2.2.2.: >> >> "The first four octets identify the LSR and must be a >> globally unique value, such as a 32-bit router Id assigned to the >> LSR. >> " >> >> The implementations took easy way out and started using it as: >> i) an IPv4 address, and >> ii) an address that is routable >> >> While one can try to justify this interpretation for IPv4, not sure how = can >> we justify this for IPv6. >> >> As I had said earlier, transport connection endpoints and/or targeted he= llo >> destinations should be discovered through other LDP protocol/cfg means, >> instead of "infering" it from LSR-ID part of LDP-Identifier. >> >> My 2 cents. >> >> On 12-03-12 11:44 AM, "Dutta, Pranjal K (Pranjal)" >> wrote: >> >>> >>> Rajeev, >>> >>> Not really. There are applications that auto-instantiate T-LDP sessions= . >>> You know transport address only after exchanging hellos. First hellos n= eed >>> to be sent to right remote LSR-ID. We don't run another discovery proto= col >>> that says "here is the BGP next-hop X but its LSR-ID is Y". Are you >>> suggesting that all such applications are irrelevant and needs to be wi= ped >>> out from deployments. I haven't heard of any text in RFC 5036 that says >>> "4 byte router-id MUST not be a routable address". >>> >>> Cheers, >>> Pranjal >>> >>> -----Original Message----- >>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >>> Rajiv >>> Asati (rajiva) >>> Sent: Monday, March 12, 2012 7:06 AM >>> To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); >>> mtinka@globaltransit.net >>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.c= n >>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>> >>> Pranjal, Mustapha, Wim, >>> >>>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >>> to >>>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>>> LDP has to auto-create targeted sessions. We can't force to set-up >>> another >>>> ip4 network just for some applications. It won't be possible to map 4 >>> byte ldp >>> >>> I hope that we are not misunderstanding 32-bit integer value in RouterI= D >>> in an IPv6-only router to mean having IPv4 network. >>> Also, such applications must use 'transport IP address', not the >>> Router-ID when it comes to setting up the session. If they don't, then >>> they are incorrect and must be fixed. >>> >>> Cheers, >>> Rajiv >>> >>>> -----Original Message----- >>>> From: Dutta, Pranjal K (Pranjal) >>> [mailto:pranjal.dutta@alcatel-lucent.com] >>>> Sent: Friday, March 02, 2012 12:02 PM >>>> To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); >>> mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Rajiv, >>>> We shouldn't be ruling out the fact that there are some >>> differences in >>>> applications of LDP compared to OSPF or BGP. If we have IPV6 only >>> transport >>>> network tomorrow then applications like BGP-AD, Dynamic MS-PW etc has >>> to >>>> advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and T- >>>> LDP has to auto-create targeted sessions. We can't force to set-up >>> another >>>> ip4 network just for some applications. It won't be possible to map 4 >>> byte ldp >>>> LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID >>> is must >>>> for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility >>> and better >>>> to add it now. >>>> >>>> Thanks, >>>> Pranjal >>>> >>>> -----Original Message----- >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> Of >>>> Henderickx, Wim (Wim) >>>> Sent: Friday, March 02, 2012 12:41 AM >>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Rajiv, >>>> >>>> I understand we didn't add a IPv6 router ID option in BGP/OSPF but we >>>> should look at the future to get to IPv6 only networks and as such it >>> will be >>>> required. So we are now at a point where we should add this option in >>> all >>>> protocols. Since LDP for Ipv6 is open we need to add it now. >>>> >>>> My 2 cents >>>> >>>> Cheers, >>>> Wim >>>> >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] >>>> Sent: vrijdag 2 maart 2012 8:08 >>>> To: Henderickx, Wim (Wim); mtinka@globaltransit.net >>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>> lizhong.jin@zte.com.cn >>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>> >>>> Hi Wim, >>>> >>>> That's a reasonable point, but no such proposal has been made for >>> other >>>> protocols. In fact, IPv6 deployments have already accommodated 4-octet >>>> router-id for routing protocols (which was also a departure from the >>>> common practice in IPv4 realm). As Mark T and I discussed in the >>>> previous email, the router-id consistency across protocols would be an >>>> operational benefit. >>>> >>>> Focusing on the technicalities, Router ID is meant to ensure the >>>> uniqueness of the router within the network while following the >>>> protocol, so are we thinking that 4-octet is not good enough to ensure >>>> the uniqueness? If so, then it would be worth having that discussion >>> in >>>> the Routing and Internet areas that have been focusing on IPv6 at >>> large. >>>> >>>> >>>> While I do agree to 128-bit future expandability as a benefit, the >>>> benefit would be trivial (at the expense of message structure changes) >>>> if we expanded it for the sake of it, but didn't address the root of >>> the >>>> problem. >>>> >>>> Do you think otherwise? >>>> >>>> Cheers, >>>> Rajiv >>>> >>>>> -----Original Message----- >>>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- >>>> lucent.com] >>>>> Sent: Friday, March 02, 2012 1:42 AM >>>>> To: Rajiv Asati (rajiva); mtinka@globaltransit.net >>>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>>> lizhong.jin@zte.com.cn >>>>> Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>> >>>>> Rajiv, I believe we need to provide both options to ensure both are >>>> possible. >>>>> If we do not introduce the IPv6 LSR ID now I will be very hard to ad >>>> it in the >>>>> future. >>>>> >>>>> -----Original Message----- >>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>> Of >>>>> Rajiv Asati (rajiva) >>>>> Sent: vrijdag 2 maart 2012 7:39 >>>>> To: mtinka@globaltransit.net >>>>> Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; >>>> lizhong.jin@zte.com.cn >>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>> >>>>> Hi Mark, >>>>> >>>>> Well said. >>>>> >>>>> I take that we are in agreement wrt 4-octet entity for LDP router-id >>>> in >>>>> the context of IPv6, as specified. >>>>> >>>>> Cheers, >>>>> Rajiv >>>>> >>>>>> -----Original Message----- >>>>>> From: Mark Tinka [mailto:mtinka@globaltransit.net] >>>>>> Sent: Friday, March 02, 2012 1:31 AM >>>>>> To: Rajiv Asati (rajiva) >>>>>> Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); >>>>> lizhong.jin@zte.com.cn; >>>>>> vishwas.ietf@gmail.com >>>>>> Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >>>>>> >>>>>> On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) >>>>>> wrote: >>>>>> >>>>>>> In the past, implementations provided the router-id CLI >>>>>>> for any interface IPv4 address to be chosen as router-id >>>>>>> for various protocols including LDP. >>>>>> >>>>>>> However, many implementations already evolved the CLI to >>>>>>> not even give an "interface" IP address for router-id, >>>>>>> to accommodate IPv6. Almost all deployed networks >>>>>>> already accommodated that. >>>>>> >>>>>> We do operate some implementations today that "still" allow >>>>>> you to specify the Router-ID for various protocols as an >>>>>> independent 32-bit integer (only), and also allow you to >>>>>> define the LSR-ID for LDP as an interface (only). This is >>>>>> current, shipping 2012 code. >>>>>> >>>>>> So both scenarios you mention above are still much in play >>>>>> today. Whether operators are using them or not (I know we >>>>>> are) is another matter entirely. >>>>>> >>>>>>> Now that LDP is being enhanced to use IPv6, >>>>>>> implementations could evolve LDP router-id as well to >>>>>>> accommodate IPv6. This would make LDP router-id to be >>>>>>> consistent with other protocols delving with IPv6. And >>>>>>> this can certainly be operationally beneficial from IPv6 >>>>>>> POV. >>>>>> >>>>>> Agree. >>>>>> >>>>>>> In fact, one of the implementations allow the router-id >>>>>>> to be configured just once and let all protocols just >>>>>>> use it, if they wanted. >>>>>> >>>>>> Yes, we operate some implementations that use this method >>>>>> too. It's quite elegant, in that you configure once and >>>>>> forget. Other implementations that are more structured means >>>>>> operators could easily forget to specify the Router-ID for a >>>>>> particular protocol, for better or worse. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Mark. >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls -- Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com From davari@broadcom.com Mon Mar 12 17:16:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3119621E801C; Mon, 12 Mar 2012 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.457 X-Spam-Level: X-Spam-Status: No, score=-5.457 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smnkVL0gODW4; Mon, 12 Mar 2012 17:16:54 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D821E8014; Mon, 12 Mar 2012 17:16:53 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 12 Mar 2012 17:25:54 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 12 Mar 2012 17:16:45 -0700 From: "Shahram Davari" To: "tictoc@ietf.org" , "mpls@ietf.org" , "'pwe3@ietf.org'" , CCAMP Date: Mon, 12 Mar 2012 17:16:39 -0700 Thread-Topic: Updated 1588 over MPLS draf-03 Thread-Index: Ac0Aro8OkV/kLkCtTR+QbDOlyi4vGQ== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 63404B983E03632515-01-01 Content-Type: multipart/mixed; boundary=_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Subject: [mpls] Updated 1588 over MPLS draf-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:16:57 -0000 --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Transfer-Encoding: 7bit --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,

 

Please fin= d attached the latest 1588 over MPLS draft (03). Since cut-off date was yes= terday, we will upload this after the Paris meeting.

Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, sinc= e some aspects from each of these groups are used in this draft.

 

We will= present this draft in the relevant WGs in Paris.

 

Regards,

=

Shahram Davari

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_-- --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_ Content-Type: text/plain; name=draft-ietf-tictoc-1588overmpls-03.txt Content-Description: draft-ietf-tictoc-1588overmpls-03.txt Content-Disposition: attachment; filename=draft-ietf-tictoc-1588overmpls-03.txt; size=50993; creation-date="Mon, 12 Mar 2012 16:46:51 GMT"; modification-date="Mon, 12 Mar 2012 17:07:14 GMT" Content-Transfer-Encoding: base64 DQoNCg0KVElDVE9DIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUy4gRGF2YXJpDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIE9yZW4NCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICBCcm9hZGNvbSBDb3JwLg0K RXhwaXJlczogU2VwdGVtYmVyIDEyLCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gQmhhdGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFAuIFJvYmVydHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsLUx1Y2VudA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM LiBNb250aW5pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMTIsIDIwMTENCg0KDQogICAgICAg ICAgVHJhbnNwb3J0aW5nIFBUUCBtZXNzYWdlcyAoMTU4OCkgb3ZlciBNUExTIE5ldHdvcmtzDQog ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OG92ZXJtcGxzLTAzDQoNCkFi c3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbWV0aG9kIGZvciB0cmFuc3Bv cnRpbmcgUFRQIG1lc3NhZ2VzIChQRFVzKQ0KICAgb3ZlciBhbiBNUExTIG5ldHdvcmsuICBUaGUg bWV0aG9kIGFsbG93cyBmb3IgdGhlIGVhc3kgaWRlbnRpZmljYXRpb24NCiAgIG9mIHRoZXNlIFBE VXMgYXQgdGhlIHBvcnQgbGV2ZWwgdG8gYWxsb3cgZm9yIHBvcnQgbGV2ZWwgcHJvY2Vzc2luZyBv Zg0KICAgdGhlc2UgUERVcyBpbiBib3RoIExFUnMgYW5kIExTUnMuDQoNCiAgIFRoZSBiYXNpYyBp ZGVhIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgaW5zaWRlIGRlZGljYXRlZCBNUExTDQog ICBMU1BzLiAgVGhlc2UgTFNQcyBvbmx5IGNhcnJ5IFBUUCBtZXNzYWdlcyBhbmQgcG9zc2libHkg Q29udHJvbCBhbmQNCiAgIE1hbmFnZW1lbnQgcGFja2V0cywgYnV0IHRoZXkgZG8gbm90IGNhcnJ5 IGN1c3RvbWVyIHRyYWZmaWMuDQoNCiAgIFR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgMTU4 OCBvdmVyIE1QTFMgYXJlIGRlZmluZWQuICBUaGUgZmlyc3QNCiAgIG1ldGhvZCBpcyB0byB0cmFu c3BvcnQgUFRQIG1lc3NhZ2VzIGRpcmVjdGx5IG92ZXIgdGhlIGRlZGljYXRlZCBNUExTDQogICBM U1AgdmlhIFVEUC9JUCBlbmNhcHN1bGF0aW9uLCB3aGljaCBpcyBzdWl0YWJsZSBmb3IgSVAvTVBM UyBuZXR3b3Jrcy4NCiAgIFRoZSBzZWNvbmQgbWV0aG9kIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVz c2FnZXMgaW5zaWRlIGEgUFcgdmlhDQogICBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uLCB3aGljaCBp cyBtb3JlIHN1aXRhYmxlIGZvciBNUExTLVRQIG5ldHdvcmtzLg0KDQpTdGF0dXMgb2YgdGhpcyBN ZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHQgMTIsIDIwMTIuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAx XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJp Z2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl DQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0K ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNClRhYmxl IG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KDQogICAyLiAgVGVybWlub2xvZ3kgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCg0KICAg My4gIFByb2JsZW0gU3RhdGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4DQoNCiAgIDQuICAxNTg4IG92ZXIgTVBMUyBBcmNoaXRlY3R1cmUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KDQogICA1LiAgRGVkaWNhdGVkIExTUHMg Zm9yIFBUUCBtZXNzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCg0KICAg Ni4gIDE1ODggb3ZlciBNUExTIEVuY2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDExDQogICAgIDYuMS4gIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNi4yLiAgMTU4OCBvdmVyIFBXIEVu Y2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KDQogICA3LiAg MTU4OCBNZXNzYWdlIFRyYW5zcG9ydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTQNCg0KICAgOC4gIFByb3RlY3Rpb24gYW5kIFJlZHVuZGFuY3kgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQoNCiAgIDkuICBFQ01QIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KDQogICAxMC4g T0FNLCBDb250cm9sIGFuZCBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCg0KICAgMTEuIFFvUyBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQoNCiAgIDEyLiBGQ1MgUmVjYWxjdWxhdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0KDQogICAxMy4g VURQIENoZWNrc3VtIENvcnJlY3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjENCg0KICAgMTQuIFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgMTU4OGF3YXJlIExTUnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgIDE0LjEuIDE1ODhhd2FyZSBMaW5rIENh cGFiaWxpdHkgZm9yIE9TUEYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMTQuMi4g MTU4OGF3YXJlIExpbmsgQ2FwYWJpbGl0eSBmb3IgSVMtSVMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyMw0KDQogICAxNS4gUlNWUC1URSBFeHRlbnNpb25zIGZvciBzdXBwb3J0IG9mIDE1ODggLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUNCg0KICAgMTYuIEJlaGF2aW9yIG9mIExFUi9MU1IgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICAgIDE2LjEuIEJl aGF2aW9yIG9mIDE1ODgtYXdhcmUgTEVSIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjYNCiAgICAgMTYuMi4gQmVoYXZpb3Igb2YgMTU4OC1hd2FyZSBMU1IgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyNg0KICAgICAxNi4zLiBCZWhhdmlvciBvZiBub24tMTU4OC1hd2Fy ZSBMU1IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQoNCiAgIDE3LiBPdGhlciBjb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0K DQogICAxOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjkNCg0KMTkuIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5DQoNCiAgIDIwLiBBY2tub3dsZWRnZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMA0KDQog ICAyMS4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzENCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KICAgICAyMS4xLiBJQU5BIENvbnNpZGVyYXRpb25zIGZvciBPU1BGIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMxDQogICAgIDIxLjIuIElBTkEgQ29uc2lkZXJhdGlvbnMgZm9yIElT LUlTICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzENCiAgICAgMjEuMy4gSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgUlNWUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQ0KDQog ICAyMi4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzINCiAgICAgMjIuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMg0KICAgICAyMi4yLiBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDQoNCiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzNA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN Cg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAg ICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAg IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDMjExOSBb UkZDMjExOV0uDQoNCiAgIFdoZW4gdXNlZCBpbiBsb3dlciBjYXNlLCB0aGVzZSB3b3JkcyBjb252 ZXkgdGhlaXIgdHlwaWNhbCB1c2UgaW4NCiAgIGNvbW1vbiBsYW5ndWFnZSwgYW5kIGFyZSBub3Qg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQogICBSRkMyMTE5IFtSRkMyMTE5XS4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMTINCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBvYmplY3RpdmUgb2Yg UHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgKFBUUCkgaXMgdG8gc3luY2hyb25pemUNCiAgIGluZGVw ZW5kZW50IGNsb2NrcyBydW5uaW5nIG9uIHNlcGFyYXRlIG5vZGVzIG9mIGEgZGlzdHJpYnV0ZWQg c3lzdGVtLg0KICAgW0lFRUVdIGRlZmluZXMgUFRQIG1lc3NhZ2VzIGZvciBjbG9jayBhbmQgdGlt ZSBzeW5jaHJvbml6YXRpb24uICBUaGUNCiAgIFBUUCBtZXNzYWdlcyBpbmNsdWRlIFBUUCBQRFVz IG92ZXIgVURQL0lQIChBbm5leCBEIGFuZCBFIG9mIFtJRUVFXSkNCiAgIGFuZCBQVFAgUERVcyBv dmVyIEV0aGVybmV0IChBbm5leCBGIG9mIFtJRUVFXSkuICBUaGlzIGRvY3VtZW50DQogICBkZWZp bmVzIG1hcHBpbmcgYW5kIHRyYW5zcG9ydCBvZiB0aGUgUFRQIG1lc3NhZ2VzIGRlZmluZWQgaW4g W0lFRUVdDQogICBvdmVyIE1QTFMgbmV0d29ya3MuDQoNCiAgIFBUUCBkZWZpbmVzIHNldmVyYWwg Y2xvY2sgdHlwZXM6IG9yZGluYXJ5IGNsb2NrcywgYm91bmRhcnkgY2xvY2tzLA0KICAgZW5kLXRv LWVuZCB0cmFuc3BhcmVudCBjbG9ja3MsIGFuZCBwZWVyLXRvLXBlZXIgdHJhbnNwYXJlbnQgY2xv Y2tzLg0KICAgT25lIGtleSBhdHRyaWJ1dGUgb2YgYWxsIG9mIHRoZXNlIGNsb2NrcyBpcyB0aGUg cmVjb21tZW5kYXRpb24gZm9yDQogICBQVFAgbWVzc2FnZXMgcHJvY2Vzc2luZyB0byBvY2N1ciBh cyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgYWN0dWFsDQogICB0cmFuc21pc3Npb24gYW5kIHJl Y2VwdGlvbiBhdCB0aGUgcGh5c2ljYWwgcG9ydCBpbnRlcmZhY2UuICBUaGlzDQogICB0YXJnZXRz IG9wdGltYWwgdGltZSBhbmQvb3IgZnJlcXVlbmN5IHJlY292ZXJ5IGJ5IGF2b2lkaW5nIHZhcmlh YmxlDQogICBkZWxheSBpbnRyb2R1Y2VkIGJ5IHF1ZXVlcyBpbnRlcm5hbCB0byB0aGUgY2xvY2tz LiAgVG8gZmFjaWxpdGF0ZSB0aGUNCiAgIGZhc3QgYW5kIGVmZmljaWVudCByZWNvZ25pdGlvbiBv ZiBQVFAgbWVzc2FnZXMgYXQgdGhlIHBvcnQgbGV2ZWwgd2hlbg0KICAgdGhlIFBUUCBtZXNzYWdl cyBhcmUgY2FycmllZCBvdmVyIE1QTFMgTFNQcywgdGhpcyBkb2N1bWVudCBkZWZpbmVzDQogICB0 aGUgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbnMgdGhhdCBzaG91bGQgYmUgdXNlZC4gIEluIGFkZGl0 aW9uLCBpdCBjYW4NCiAgIGJlIGV4cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBleGlzdCBMU1IvTEVS cyB3aGVyZSBvbmx5IGEgc3Vic2V0IG9mIHRoZQ0KICAgcGh5c2ljYWwgcG9ydHMgd2lsbCBoYXZl IHRoZSBwb3J0IGJhc2VkIFBUUCBtZXNzYWdlIHByb2Nlc3NpbmcNCiAgIGNhcGFiaWxpdGllcy4g IEluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBQVFAgY2FycnlpbmcgTFNQcyBhbHdheXMNCiAg IGVudGVyIGFuZCBleGl0IHBvcnRzIHdpdGggdGhpcyBjYXBhYmlsaXR5LCByb3V0aW5nIGV4dGVu c2lvbnMgYXJlDQogICBkZWZpbmVkIHRvIGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkgb24gYSBw b3J0IGJhc2lzIGFuZCB0byBhbGxvdyBmb3INCiAgIHRoZSBlc3RhYmxpc2htZW50IG9mIExTUHMg dGhhdCBvbmx5IHRyYW5zaXQgc3VjaCBwb3J0cy4gIFdoaWxlIHRoaXMNCiAgIHBhdGggZXN0YWJs aXNobWVudCByZXN0cmljdGlvbiBtYXkgYmUgYXBwbGllZCBvbmx5IGF0IHRoZSBMRVINCiAgIGlu Z3Jlc3MvZWdyZXNzIHBvcnRzLCBpdCBiZWNvbWVzIG1vcmUgaW1wb3J0YW50IHdoZW4gdXNpbmcN CiAgIHRyYW5zcGFyZW50IGNsb2NrIGNhcGFibGUgTFNScyBpbiB0aGUgcGF0aC4NCg0KICAgVGhl IHBvcnQgYmFzZWQgUFRQIG1lc3NhZ2UgcHJvY2Vzc2luZyBpbnZvbHZlcyBQVFAgZXZlbnQgbWVz c2FnZQ0KICAgcmVjb2duaXRpb24uICBPbmNlIHRoZSBQVFAgZXZlbnQgbWVzc2FnZXMgYXJlIHJl Y29nbml6ZWQgdGhleSBjYW4gYmUNCiAgIG1vZGlmaWVkIGJhc2VkIG9uIHRoZSByZWNlcHRpb24g b3IgdHJhbnNtaXNzaW9uIHRpbWVzdGFtcC4gIA0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IHR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXINCiAgIE1QTFMu ICBPbmUgaXMgcHJpbmNpcGFsbHkgZm9jdXNlZCBvbiBhbiBJUC9NUExTIGVudmlyb25tZW50IGFu ZCB0aGUNCiAgIHNlY29uZCBpcyBmb2N1c2VkIG9uIHRoZSBNUExTLVRQIGVudmlyb25tZW50LiBU aGUgc29sdXRpb24gaW52b2x2ZXMgDQogIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMgb3ZlciBk ZWRpY2F0ZWQgTFNQcyBjYWxsZWQgUFRQIExTUHMuIFRoZXNlDQogIExTUHMgY2FycnkgUFRQIG1l c3NhZ2VzIGFuZCBNQVkgY2FycnkgTWFuYWdlbWVudCBhbmQgY29udHJvbCBtZXNzYWdlcywNCiAg YnV0IG5vdCB1c2VyIHRyYWZmaWMuIFBUUCBMU1BzIGNhbiBiZSBlc3RhYmxpc2hlZCBzdGF0aWNh bGx5IG9yIHZpYSANCiAgc2lnbmFsaW5nLiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4dGVuc2lv bnMgdG8gT1NQRiwgSVNJUyB0aGF0IGVuYWJsZSANCiAgcm91dGVycyB0byBkaXN0cmlidXRlIHRo ZWlyIDE1ODggb3ZlciBNUExTIGNhcGFiaWxpdHkgdG8gb3RoZXIgcm91dGVycy4gDQogIEl0IGFs c28gcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBlc3RhYmxpc2hpbmcgUFRQIExT UHMuIA0KICBFeHRlbnNpb25zIGZvciBCR1AvTERQIFBXIHNpZ25hbGluZyBpcyBmb3IgZnV0dXJl IHN0dWR5IGFuZCBpcyAgDQogIHJlcXVpcmVkIG9ubHkgZm9yIGNhc2VzIHRoYXQgVHVubmVsIExh YmVsIGlzIG5vdCBhdmFpbGFibGUgKGUuZy4gUEhQKS4NCg0KICAgV2hpbGUgdGhlIHRlY2huaXF1 ZXMgaW5jbHVkZWQgaGVyZWluIGFsbG93IGZvciB0aGUgZXN0YWJsaXNobWVudCBvZg0KICAgcGF0 aHMgb3B0aW1pemVkIHRvIGluY2x1ZGUgUFRQIFRpbWUtc3RhbXBpbmcgY2FwYWJsZSBsaW5rcywg dGhlDQogICBwZXJmb3JtYW5jZSBvZiB0aGUgU2xhdmUgY2xvY2tzIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQoyLiAgVGVybWlub2xvZ3kNCg0KICAgMTU4ODogVGhlIHRpbWluZyBhbmQg c3luY2hyb25pemF0aW9uIGFzIGRlZmluZWQgYnkgSUVFRSAxNTg4LTIwMDgNCg0KICAgUFRQOiBU aGUgdGltaW5nIGFuZCBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2wgdXNlZCBieSAxNTg4IChzcGVj aWZpY2FsbHkgUFRQdjIpDQoNCiAgIE1hc3RlciBDbG9jazogVGhlIHNvdXJjZSBvZiAxNTg4IHRp bWluZyB0byBhIHNldCBvZiBzbGF2ZSBjbG9ja3MuDQoNCiAgIE1hc3RlciBQb3J0OiBBIHBvcnQg b24gYSBvcmRpbmFyeSBvciBib3VuZGFyeSBjbG9jayB0aGF0IGlzIGluIE1hc3Rlcg0KICAgc3Rh dGUuICBUaGlzIGlzIHRoZSBzb3VyY2Ugb2YgdGltaW5nIHRvd2FyZCBzbGF2ZSBwb3J0cy4NCg0K ICAgU2xhdmUgQ2xvY2s6IEEgcmVjZWl2ZXIgb2YgMTU4OCB0aW1pbmcgZnJvbSBhIG1hc3RlciBj bG9jay4NCg0KICAgU2xhdmUgUG9ydDogQSBwb3J0IG9uIGEgYm91bmRhcnkgY2xvY2sgb3Igb3Jk aW5hcnkgY2xvY2sgdGhhdCBpcw0KICAgcmVjZWl2aW5nIHRpbWluZyBmcm9tIGEgbWFzdGVyIGNs b2NrLg0KDQogICBPcmRpbmFyeSBDbG9jazogQSBkZXZpY2Ugd2l0aCBhIHNpbmdsZSBQVFAgcG9y dC4NCg0KICAgVHJhbnNwYXJlbnQgQ2xvY2s6ICBBIGRldmljZSB0aGF0IG1lYXN1cmVzIHRoZSB0 aW1lIHRha2VuIGZvciBhIFBUUA0KICAgZXZlbnQgbWVzc2FnZSB0byB0cmFuc2l0IHRoZSBkZXZp Y2UgYW5kIHRoZW4gZWl0aGVyIHVwZGF0ZXMgdGhlDQogICBjb3JyZWN0aW9uIEZpZWxkIG9mIHRo ZSBtZXNzYWdlIHdpdGggdGhpcyB0cmFuc2l0IHRpbWUgKDEtc3RlcCkgb3IgIA0KICAgZ2VuZXJh dGVzIGEgZm9sbG93IHVwIG1lc3NhZ2UgdGhhdCBjb250YWlucyB0aGUgdHJhbnNpdCBkZWxheSAo Mi1TdGVwKS4NCg0KICAgQm91bmRhcnkgQ2xvY2s6IEEgZGV2aWNlIHdpdGggbW9yZSB0aGFuIG9u ZSBQVFAgcG9ydC4gIEdlbmVyYWxseQ0KICAgYm91bmRhcnkgY2xvY2tzIHdpbGwgaGF2ZSBvbmUg cG9ydCBpbiBzbGF2ZSBzdGF0ZSB0byByZWNlaXZlIHRpbWluZw0KICAgYW5kIHRoZSBvdGhlciBw b3J0cyBpbiBtYXN0ZXIgc3RhdGUgdG8gcmUtZGlzdHJpYnV0ZSB0aGUgdGltaW5nLg0KDQogICBQ VFAgTFNQOiBBbiBMU1AgZGVkaWNhdGVkIHRvIGNhcnJ5IFBUUCBtZXNzYWdlcy4NCg0KICAgUFRQ IFBXOiBBIFBXIHdpdGhpbiBhIFBUUCBMU1AgdGhhdCBpcyBkZWRpY2F0ZWQgdG8gY2FycnkgUFRQ DQogICBtZXNzYWdlcy4NCg0KICAgQ1c6IFBzZXVkb3dpcmUgQ29udHJvbCBXb3JkDQoNCg0KICAg RUNNUDogRXF1YWwgQ29zdCBNdWx0aXBhdGgNCg0KICAgQ0Y6IENvcnJlY3Rpb24gRmllbGQsIGEg ZmllbGQgaW5zaWRlIGNlcnRhaW4gUFRQIG1lc3NhZ2VzIChtZXNzYWdlDQogICB0eXBlIDAtMyl0 aGF0IGhvbGRzIHRoZSBhY2N1bXVsYXRpdmUgdHJhbnNpdCB0aW1lIGluc2lkZSBpbnRlcm1lZGlh dGUNCiAgIHN3aXRjaGVzLg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCg0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMy4gIFByb2JsZW0gU3RhdGVtZW50DQoNCiAgIElFRUUgMTU4 OC0yMDA4IGhhcyBkZWZpbmVkIG1ldGhvZHMgZm9yIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMg b3ZlciANCiAgIEV0aGVybmV0IGFuZCBJUCBuZXR3b3Jrcy4gVGhlcmUgaXMgYSBuZWVkIHRvIHRy YW5zcG9ydCBQVFAgbWVzc2FnZXMgDQogICBvdmVyIGFuIE1QTFMgbmV0d29yayB3aGlsZSBzdXBw b3J0aW5nIHRoZSBUcmFuc3BhcmVudCBDbG9jayAoVEMpLCANCiAgIEJvdW5kYXJ5IENsb2NrIChC QykgYW5kIE9yZGluYXJ5IENsb2NrIChPQykgZnVuY3Rpb25hbGl0eSBpbiB0aGUgTEVSIA0KICAg YW5kIExTUnMgaW4gdGhlIE1QTFMgbmV0d29yay4gICANCg0KICAgVGhlcmUgYXJlIG11bHRpcGxl IHdheXMgb2YgdHJhbnNwb3J0aW5nIDE1ODggb3ZlciBNUExTLiBIb3dldmVyLCB0aGVyZQ0KICAg aXMgYSByZXF1aXJlbWVudCB0byBsaW1pdCB0aGUgcG9zc2libGUgZW5jYXBzdWxhdGlvbiBvcHRp b25zIHRvIHNpbXBsaWZ5DQogICB0aGUgUFRQIG1lc3NhZ2UgaWRlbnRpZmljYXRpb24gYW5kIHBy b2Nlc3NpbmcgcmVxdWlyZWQgYXQgdGhlIHBvcnQgbGV2ZWwuICANCg0KICAgVGhlcmUgaXMgYWxz byBhIHJlcXVpcmVtZW50IHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgYmVsb25naW5nIHRvIG1h bnkNCiAgIGRpZmZlcmVudCAxNTg4IGRvbWFpbnMgYWNyb3NzIGFuIE1QTFMgbmV0d29yayxzdWNo IGFzIHRoZSBjYXNlIGZvciB3aG9sZQ0KICAgc2FsZSAoY2Fycmllcj9zIGNhcnJpZXIgY2FzZSku DQoNCiAgIFdoZW4gMTU4OC1hd2FyZW5lc3MgaXMgbmVlZGVkLCBQVFAgbWVzc2FnZXMgc2hvdWxk IG5vdCBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBMU1BzIG9yIFBXcyB0aGF0IGFyZSBjYXJyeWlu ZyBjdXN0b21lciB0cmFmZmljIGJlY2F1c2UgTFNScw0KICAgcGVyZm9ybSBMYWJlbCBzd2l0Y2hp bmcgYmFzZWQgb24gdGhlIHRvcCBsYWJlbCBpbiB0aGUgc3RhY2suICBUbw0KICAgZGV0ZWN0IFBU UCBtZXNzYWdlcyBpbnNpZGUgc3VjaCBMU1BzIHJlcXVpcmUgc3BlY2lhbCBoYXJkd2FyZSB0byBk bw0KICAgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiBhdCBsaW5lIHJhdGUuICBFdmVuIGlmIHN1Y2gg aGFyZHdhcmUgZXhpc3RzLA0KICAgdGhlIHBheWxvYWQgY2FuJ3QgYmUgZGV0ZXJtaW5pc3RpY2Fs bHkgaWRlbnRpZmllZCBieSBMU1JzIGJlY2F1c2UgdGhlDQogICBwYXlsb2FkIHR5cGUgaXMgYSBj b250ZXh0IG9mIHRoZSBQVyBsYWJlbCwgYW5kIHRoZSBQVyBsYWJlbCBhbmQgaXRzDQogICBjb250 ZXh0IGFyZSBvbmx5IGtub3duIHRvIHRoZSBFZGdlIHJvdXRlcnMgKFBFcy9MRVJzKTsgTFNScyBk b24ndCBrbm93DQogICB3aGF0IGlzIGEgUFcncyBwYXlsb2FkIChFdGhlcm5ldCwgQVRNLCBGUiwg Q0VTLCBldGMpLiAgRXZlbiBpZiBvbmUNCiAgIHJlc3RyaWN0cyBhbiBMU1AgdG8gb25seSBjYXJy eSBFdGhlcm5ldCBQV3MsIHRoZSBMU1JzIGRvbid0IGhhdmUgdGhlIA0KICAga25vd2xlZGdlIG9m IHdoZXRoZXIgUFcgQ29udHJvbCBXb3JkIChDVykgaXMgcHJlc2VudCBvciBub3QgYW5kIHRoZXJl Zm9yZQ0KICAgY2FuJ3QgZGV0ZXJtaW5pc3RpY2FsbHkgaWRlbnRpZnkgdGhlIHBheWxvYWQuDQoN CiAgIFRoZXJlZm9yZSBhIGdlbmVyaWMgbWV0aG9kIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCB0aGF0IGRvZXMgbm90DQogICByZXF1aXJlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24gYXQgbGlu ZSByYXRlLCBhbmQgY2FuIGRldGVybWluaXN0aWNhbGx5DQogICBpZGVudGlmeSBQVFAgbWVzc2Fn ZXMuICBUaGUgZGVmaW5lZCBtZXRob2QgaXMgYXBwbGljYWJsZSB0byBib3RoIE1QTFMNCiAgIGFu ZCBNUExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K RGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVy IE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjQuICAxNTg4IG92ZXIgTVBM UyBBcmNoaXRlY3R1cmUNCg0KICAgMTU4OCBjb21tdW5pY2F0aW9uIGZsb3dzIG1hcCBvbnRvIE1Q TFMgbm9kZXMgYXMgZm9sbG93czogMTU4OA0KICAgbWVzc2FnZXMgYXJlIGV4Y2hhbmdlIGJldHdl ZW4gUFRQIHBvcnRzIG9uIG9yZGluYXJ5IGFuZCBib3VuZGFyeQ0KICAgY2xvY2tzLiAgVHJhbnNw YXJlbnQgY2xvY2tzIGRvIG5vdCB0ZXJtaW5hdGUgdGhlIFBUUCBtZXNzYWdlcyBidXQNCiAgIHRo ZXkgZG8gbW9kaWZ5IHRoZSBjb250ZW50cyBvZiB0aGUgUFRQIG1lc3NhZ2VzIGFzIHRoZXkgdHJh bnNpdA0KICAgYWNyb3NzIHRoZSB0cmFuc3BhcmVudCBjbG9jay4gIFNvIG9yZGluYXJ5IGFuZCBi b3VuZGFyeSBjbG9ja3Mgd291bGQNCiAgIGV4aXN0IHdpdGhpbiBMRVJzIGFzIHRoZXkgYXJlIHRo ZSB0ZXJtaW5hdGlvbiBwb2ludHMgZm9yIHRoZSBQVFANCiAgIG1lc3NhZ2VzIGNhcnJpZWQgaW4g TVBMUy4gIFRyYW5zcGFyZW50IGNsb2NrcyAob3IgYWx0ZXJuYXRpdmUgdGVjaG5pcXVlKSANCiAg IHdvdWxkIGV4aXN0IHdpdGhpbiBMU1JzIGFzIHRoZXkgZG8gbm90IHRlcm1pbmF0ZSB0aGUgUFRQ IG1lc3NhZ2UgZXhjaGFuZ2UuIA0KICAgVGhlIDE1OCBvdmVyIE1QTFMgQXJjaGl0ZWN0dXJlIGlz IHNob3duIGluIEZpZ3VyZSAxLg0KDQoNCg0KDQorLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAg Ky0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKw0KfCBNYXN0ZXJ8ICAgICB8ICAg ICAgIHwgICAgIHwgICAgICAgfCAgICAgfCAgICAgICB8ICAgICB8IFNsYXZlIHwNCnwgQ2xvY2sg fC0tLS0tfCAgTEVSICB8LS0tLS18ICBMU1IgIHwtLS0tLXwgIExFUiAgfC0tLS0tfCBDbG9jayB8 DQp8ICBPQyAgIHwgICAgIHwgIEJDICAgfCAgICAgfCAgVEMgICB8ICAgICB8ICBCQyAgIHwgICAg IHwgIE9DICAgfA0KKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAgKy0t LS0tLS0rICAgICArLS0tLS0tLSsNCiAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcDQorLS0tLS0tLSsgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFwgICAgICstLS0tLS0tKw0KfCAgTEVSICB8ICAgIC8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXCAgICB8ICBMRVIgIHwNCnwgTWFzdGVyfC0tLS8gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcLS0tfCBTbGF2ZSB8DQp8IENsb2NrIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ2xvY2sgfA0K Ky0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsNCg0KRmlndXJlIDEgLSBEZXBsb3ltZW50IGV4YW1wbGVzIG9mIDE1ODggb3ZlciBN UExTIG5ldHdvcmsNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODgg b3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQo1LiAgRGVkaWNhdGVk IExTUHMgZm9yIFBUUCBtZXNzYWdlcw0KDQogICBNYW55IG1ldGhvZHMgd2VyZSBjb25zaWRlcmVk IGZvciBpZGVudGlmeWluZyB0aGUgMTU4OCBtZXNzYWdlcyB3aGVuDQogICB0aGV5IGFyZSBlbmNh cHN1bGF0ZWQgaW4gTVBMUyBzdWNoIGFzIGJ5IHVzaW5nIEdBTC9BQ0ggb3IgYSBuZXcNCiAgIHJl c2VydmVkIGxhYmVsLiAgVGhlc2UgbWV0aG9kcyB3ZXJlIG5vdCBhdHRyYWN0aXZlIHNpbmNlIHRo ZXkgZWl0aGVyDQogICByZXF1aXJlZCBkZWVwIHBhY2tldCBpbnNwZWN0aW9uIGFuZCBzbm9vcGlu ZyBhdCBsaW5lIHJhdGUgb3IgdGhleQ0KICAgcmVxdWlyZWQgdXNlIG9mIGEgc2NhcmNlIG5ldyBy ZXNlcnZlZCBsYWJlbC4gIEFsc28gb25lIG9mIHRoZSBnb2Fscw0KICAgd2FzIHRvIHJldXNlIGV4 aXN0aW5nIE9BTSBhbmQgcHJvdGVjdGlvbiBtZWNoYW5pc21zLg0KDQogICBUaGUgbWV0aG9kIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gYmUgdXNlZCBieSBMRVIvTFNScyB0bw0KICAgaWRl bnRpZnkgUFRQIG1lc3NhZ2VzIGluIE1QTFMgdHVubmVscyBieSB1c2luZyBkZWRpY2F0ZWQgTFNQ cyB0bw0KICAgY2FycnkgUFRQIG1lc3NhZ2VzLg0KDQogICBDb21wbGlhbnQgaW1wbGVtZW50YXRp b25zIE1VU1QgdXNlIGRlZGljYXRlZCBMU1BzIHRvIGNhcnJ5IFBUUA0KICAgbWVzc2FnZXMgb3Zl ciBNUExTLiAgVGhlc2UgTFNQcyBhcmUgaGVyZWluIHJlZmVycmVkIHRvIGFzICJQVFAgTFNQcyIN CiAgIGFuZCB0aGUgbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGVzZSBMU1BzIGFzICJQVFAgbGFi ZWxzIi4gVGhlIFBUUCBMU1ANCiAgIGJldHdlZW4gYSBNYXN0ZXIgQ2xvY2sgYW5kIGEgU2xhdmUg Q2xvY2sgYW5kIHRoZSBQVFAgTFNQIGJldHdlZW4gdGhlDQogICBzYW1lIFNsYXZlIENsb2NrIGFu ZCBNYXN0ZXIgQ2xvY2sgTVVTVCBiZSBjby1yb3V0ZWQuICBBbHRlcm5hdGl2ZWx5LA0KICAgYSBz aW5nbGUgYmlkaXJlY3Rpb25hbCBjby1yb3V0ZWQgTFNQIGNhbiBiZSB1c2VkLiAgVGhlIFBUUCBM U1AgTUFZIGJlDQogICBNUExTIExTUCBvciBNUExTLVRQIExTUC4gIFRoaXMgY28tcm91dGluZyBp cyByZXF1aXJlZCB0byBsaW1pdA0KICAgZGlmZmVyZW5jZXMgaW4gdGhlIGRlbGF5cyBpbiB0aGUg TWFzdGVyIGNsb2NrIHRvIFNsYXZlIGNsb2NrDQogICBkaXJlY3Rpb24gY29tcGFyZWQgdG8gdGhl IFNsYXZlIGNsb2NrIHRvIE1hc3RlciBjbG9jayBkaXJlY3Rpb24uDQoNCiAgIFRoZSBQVFAgTFNQ cyBjb3VsZCBiZSBjb25maWd1cmVkIG9yIHNpZ25hbGVkIHZpYSBSU1ZQLVRFL0dNUExTLiAgTmV3 DQogICBSU1ZQLVRFL0dNUExTIFRMVnMgYW5kIG9iamVjdHMgYXJlIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCB0bw0KICAgaW5kaWNhdGUgdGhhdCB0aGVzZSBMU1BzIGFyZSBQVFAgTFNQcy4NCg0K ICAgVGhlIFBUUCBMU1BzIE1BWSBjYXJyeSBlc3NlbnRpYWwgTVBMUy9NUExTLVRQIGNvbnRyb2wg cGxhbmUgdHJhZmZpYw0KICAgc3VjaCBhcyBCRkQgYW5kIExTUCBQaW5nIGJ1dCB0aGUgTFNQIHVz ZXIgcGxhbmUgdHJhZmZpYyBNVVNUIGJlIFBUUA0KICAgb25seS4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAxMg0KDQoNCjYuICAxNTg4IG92ZXIgTVBMUyBFbmNhcHN1bGF0aW9uDQoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyB0d28gbWV0aG9kcyBmb3IgY2FycnlpbmcgUFRQIG1lc3NhZ2VzIG92ZXIN CiAgIE1QTFMuICBUaGUgZmlyc3QgbWV0aG9kIGlzIGNhcnJ5aW5nIElQIGVuY2Fwc3VsYXRlZCBQ VFAgbWVzc2FnZXMgb3Zlcg0KICAgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBJUC9N UExTIG5ldHdvcmtzIGFuZCB0aGUgc2Vjb25kIG1ldGhvZCwgDQogICBpcyBjYXJyeWluZyBQVFAg bWVzc2FnZXMgb3ZlciBkZWRpY2F0ZWQgRXRoZXJuZXQgUFdzIChjYWxsZWQgUFRQIFBXcykgDQog ICBpbnNpZGUgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBNUExTIGFuZCBNUExTLVRQ IG5ldHdvcmtzLg0KDQo2LjEuICAxNTg4IG92ZXIgTFNQIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IHNpbXBsZXN0IG1ldGhvZCBvZiB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXIgTVBMUyBp cyB0bw0KICAgZW5jYXBzdWxhdGUgUFRQIFBEVXMgaW4gVURQL0lQIGFuZCB0aGVuIGVuY2Fwc3Vs YXRlIHRoZW0gaW4gUFRQIExTUC4NCiAgIFRoZSAxNTg4IG92ZXIgTFNQIGZvcm1hdCBpcyBzaG93 biBpbiBGaWd1cmUgMi4NCg0KDQoNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICB8ICAgUFRQIFR1bm5lbCBMYWJlbCAgIHwNCiAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICBJUHY0LzYgICAgICAgIHwNCiAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICAgVURQICAg ICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8 ICAgICAgICBQVFAgUERVICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCg0KICAgRmlndXJlICgyKSAtIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbg0KDQogICBU aGlzIGVuY2Fwc3VsYXRpb24gaXMgdmVyeSBzaW1wbGUgYW5kIGlzIHVzZWZ1bCB3aGVuIHRoZSBu ZXR3b3Jrcw0KICAgYmV0d2VlbiAxNTg4IE1hc3RlciBDbG9jayBhbmQgU2xhdmUgQ2xvY2sgYXJl IElQL01QTFMgbmV0d29ya3MuDQoNCiAgIEluIG9yZGVyIGZvciBhbiBMU1IgdG8gcHJvY2VzcyBQ VFAgbWVzc2FnZXMsIHRoZSBQVFAgTGFiZWwgbXVzdCBiZQ0KICAgdGhlIHRvcCBsYWJlbCBvZiB0 aGUgbGFiZWwgc3RhY2suDQoNCiAgIFRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVT VCBmb2xsb3cgQW5uZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCjYuMi4gIDE1ODggb3ZlciBQVyBF bmNhcHN1bGF0aW9uDQoNCiAgIEFub3RoZXIgbWV0aG9kIG9mIHRyYW5zcG9ydGluZyAxNTg4IG92 ZXIgTVBMUyBuZXR3b3JrcyBpcyBieQ0KICAgZW5jYXBzdWxhdGluZyBQVFAgUERVcyBpbiBFdGhl cm5ldCBhbmQgdGhlbiB0cmFuc3BvcnRpbmcgdGhlbSBvdmVyDQogICBFdGhlcm5ldCBQVyAoUFRQ IFBXKSBhcyBkZWZpbmVkIGluIFtSRkM0NDQ4XSwgd2hpY2ggaW4gdHVybiBpcw0KICAgdHJhbnNw b3J0ZWQgb3ZlciBQVFAgTFNQcy4gIEFsdGVybmF0aXZlbHkgUFRQIFBEVXMgTUFZIGJlDQogICBl bmNhcHN1bGF0ZWQgaW4gVURQL0lQL0V0aGVybmV0IGFuZCB0aGVuIHRyYW5zcG9ydGVkIG92ZXIg RXRoZXJuZXQNCiAgIFBXLg0KDQogICBCb3RoIFJhdyBhbmQgVGFnZ2VkIG1vZGVzIGZvciBFdGhl cm5ldCBQVyBhcmUgcGVybWl0dGVkLiAgVGhlIDE1ODgNCiAgIG92ZXIgUFcgZm9ybWF0IGlzIHNo b3duIGluIEZpZ3VyZSAzLg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNo IDIwMTINCg0KDQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg ICAgICAgICAgICAgICB8UFRQIFR1bm5lbCBMYWJlbHwNCiAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgIHwgICAgUFcgTGFiZWwgICAgfA0K ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAg ICAgfCAgQ29udHJvbCBXb3JkICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIEV0aGVybmV0ICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgfCAgICAgSGVhZGVyICAgICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICBWTEFOcyAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIElQVjQvVjYgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICAgVURQICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIFBU UCBQRFUgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgIEZpZ3VyZSAzIC0gMTU4OCBvdmVyIFBXIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IENvbnRyb2wgV29yZCAoQ1cpIGFzIHNwZWNpZmllZCBpbiBbUkZDNDQ0OF0gU0hPVUxEIGJlIHVz ZWQgdG8NCiAgIGVuc3VyZSBhIG1vcmUgcm9idXN0IGRldGVjdGlvbiBvZiBQVFAgbWVzc2FnZXMg aW5zaWRlIHRoZSBNUExTDQogICBwYWNrZXQuICBJZiBDVyBpcyB1c2VkLCB0aGUgdXNlIG9mIFNl cXVlbmNlIE51bWJlciBpcyBvcHRpb25hbC4NCg0KICAgVGhlIHVzZSBvZiBWTEFOIGFuZCBVRFAv SVAgYXJlIG9wdGlvbmFsLiAgTm90ZSB0aGF0IDEgb3IgMiBWTEFOcyBNQVkNCiAgIGV4aXN0IGlu IHRoZSBQVyBwYXlsb2FkLg0KDQogICBJbiBvcmRlciBmb3IgYW4gTFNSIHRvIHByb2Nlc3MgUFRQ IG1lc3NhZ2VzLCB0aGUgdG9wIGxhYmVsIG9mIHRoZQ0KICAgbGFiZWwgc3RhY2sgKHRoZSBUdW5u ZWwgTGFiZWwpIE1VU1QgYmUgYSBQVFAgbGFiZWwuICBIb3dldmVyDQogICBpbiBzb21lIGFwcGxp Y2F0aW9ucyB0aGUgUFcgbGFiZWwgbWF5IGJlIHRoZSB0b3AgbGFiZWwgaW4gdGhlIHN0YWNrLA0K ICAgc3VjaCBhcyBjYXNlcyB3aGVyZSB0aGVyZSBpcyBvbmx5IG9uZS1ob3AgYmV0d2VlbiBQRXMg b3IgaW4gY2FzZSBvZg0KICAgUEhQLiAgSW4gc3VjaCBjYXNlcywgdGhlIFBXIGxhYmVsIFNIT1VM RCBiZSBhIFBUUCBMYWJlbC4NCg0KICAgSW4gb3JkZXIgdG8gZW5zdXJlIGNvbmdydWVuY3kgYmV0 d2VlbiB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgUFRQDQogICBtZXNzYWdlIGZsb3csIEVDTVAgU0hP VUxEIGJlIGF2b2lkZWQgZm9yIHRoZSBQVFAgVHVubmVscy9MU1BzLiAgDQogICBUaGVyZWZvcmUs IEVudHJvcHkgbGFiZWwgW0ktRC5pZXRmLXB3ZTMtZmF0LXB3XSBpcyBub3QgbmVjZXNzYXJ5IA0K ICAgYW5kIGl0IFNIT1VMRCBOT1QgYmUgcHJlc2VudCBpbiB0aGUgc3RhY2suDQoNCiAgIFRoZSBF dGhlcm5ldCBlbmNhcHN1bGF0aW9uIG9mIFBUUCBNVVNUIGZvbGxvdyBBbm5leCBGIG9mIFtJRUVF XSBhbmQNCiAgIHRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVTVCBmb2xsb3cgQW5u ZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCiAgIEZvciAxNTg4IG92ZXIgTVBMUyBlbmNhcHN1bGF0 aW9ucyB0aGF0IGFyZSBQVyBiYXNlZCwgdGhlcmUgYXJlIHNvbWUNCiAgIGNhc2VzIGluIHdoaWNo IHRoZSBQVFAgTFNQIGxhYmVsIG1heSBub3QgYmUgcHJlc2VudDoNCg0KDQoNCkRhdmFyaSwgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdl IDEyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIG8gIFdoZW4gUEhQIGlzIGFwcGxpZWQg dG8gdGhlIFBUUCBMU1AsIHRoZSBmcmFtZSBpcyByZWNlaXZlZA0KICAgICAgYXQgUFcgdGVybWlu YXRpb24gcG9pbnQgd2l0aG91dCBQVFAgTFNQIGxhYmVsOw0KDQogICBvICBXaGVuIHRoZSBQVyBp cyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHR3byByb3V0ZXJzIGRpcmVjdGx5IGNvbm5lY3RlZA0KICAg ICAgdG8gZWFjaCBvdGhlciB0aGUgUFRQIExTUCBpcyBub3QgbmVlZGVkLg0KDQogICBJbiBzdWNo IGNhc2VzIGl0IGlzIHJlcXVpcmVkIGZvciBhIHJvdXRlciB0byBpZGVudGlmeSB0aGVzZSBNUExT IGZyYW1lcyANCiAgIGFzIFBUUCBtZXNzYWdlcy4gIFRoaXMgd291bGQgcmVxdWlyZSB0aGUgUFcg bGFiZWwgdG8gYmUgYSBQVFAgbGFiZWwuDQoNCiAgIFNpbmNlIGJvdGggdGhlIFR1bm5lbCBMYWJl bCBhbmQgUFcgTGFiZWwgbWF5IG5lZWQgdG8gYmUgUFRQIGxhYmVscywgDQogICB0aGVyZSBpcyBh IG5lZWQgdG8gYWRkIGV4dGVuc2lvbiB0byBSU1ZQLVRFIFR1bm5lbCBMYWJlbCBkaXN0cmlidXRp b24sIA0KICAgYXMgd2VsbCBhcyBMRFAvQkdQIFBXIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2Nv bCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KICAgVHVubmVsIExhYmVsIGFuZCBQVyBsYWJlbCBhcmUg UFRQIExhYmVscyByZXNwZWN0aXZlbHkuDQoNCiAgIFRoZSBQVyBtZXRob2Qgb2YgdHJhbnNwb3J0 aW5nIFBUUCBvdmVyIE1QTFMgaXMgYXBwbGljYWJsZSB0byBib3RoIElQL01QTFMNCiAgIGFuZCBN UExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQo3LiAgMTU4OCBNZXNzYWdlIFRyYW5zcG9ydA0KDQogICAxNTg4IHByb3Rv Y29sIGNvbXByaXNlcyBvZiB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgdHlwZXM6DQoNCiAgIG8gIEFu bm91bmNlDQoNCiAgIG8gIFNZTkMNCg0KICAgbyAgRk9MTE9XIFVQDQoNCiAgIG8gIERFTEFZX1JF USAoRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgREVMQVlfUkVTUCAoRGVsYXkgUmVzcG9uc2UpDQoN CiAgIG8gIFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JF U1AgKFBlZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIG8gIFBERUxBWV9SRVNQX0ZPTExPV19VUCAo UGVlciBEZWxheSBSZXNwb25zZSBGb2xsb3cgdXApDQoNCiAgIG8gIE1hbmFnZW1lbnQNCg0KICAg byAgU2lnbmFsaW5nDQoNCiAgIEEgc3Vic2V0IG9mIFBUUCBtZXNzYWdlIHR5cGVzIHRoYXQgcmVx dWlyZSB0aW1lc3RhbXAgcHJvY2Vzc2luZyBhcmUNCiAgIGNhbGxlZCBFdmVudCBtZXNzYWdlczoN Cg0KICAgbyAgU1lOQw0KDQogICBvICBERUxBWV9SRVEgKERlbGF5IFJlcXVlc3QpDQoNCiAgIG8g IFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JFU1AgKFBl ZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIFNZTkMgYW5kIERFTEFZX1JFUSBhcmUgZXhjaGFuZ2Vk IGJldHdlZW4gTWFzdGVyIENsb2NrIGFuZCBTbGF2ZSBDbG9jaw0KICAgYW5kIE1VU1QgYmUgdHJh bnNwb3J0ZWQgb3ZlciBQVFAgTFNQcy4gIFBERUxBWV9SRVEgYW5kIFBERUxBWV9SRVNQDQogICBh cmUgZXhjaGFuZ2VkIGJldHdlZW4gYWRqYWNlbnQgUFRQIGNsb2NrcyAoaS5lLiAgb3JkaW5hcnkg aW4gTWFzdGVyIG9yIA0KICAgU2xhdmUgc3RhdGUsIGJvdW5kYXJ5LCBvciB0cmFuc3BhcmVudCBj bG9jaykgYW5kIE1BWSBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBzaW5nbGUgaG9wIFBUUCBMU1Bz LiAgDQoNCiAgIEZvciBhIGdpdmVuIGluc3RhbmNlIG9mIDE1ODggcHJvdG9jb2wsIFNZTkMgYW5k IERFTEFZX1JFUSBNVVNUIGJlDQogICB0cmFuc3BvcnRlZCBvdmVyIHR3byBQVFAgTFNQcyB0aGF0 IGFyZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgVGhlc2UNCiAgIFBUUCBMU1BzLCB3aGljaCBh cmUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucyBNVVNUIGJlIGNvbmdydWVudCBhbmQgY28tDQogICBy b3V0ZWQuICBBbHRlcm5hdGl2ZWx5LCBhIHNpbmdsZSBiaWRpcmVjdGlvbmFsIGNvLXJvdXRlZCBM U1AgY2FuIGJlDQogICB1c2VkLg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAg ICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KICBOb24tRXZlbnQgUFRQIG1lc3NhZ2UgdHlwZXMgZG9uJ3QgbmVl ZCB0byBiZSBwcm9jZXNzZWQgYnkgaW50ZXJtZWRpYXRlDQogIHJvdXRlcnMuSG93ZXZlciwgdGhl c2UgbWVzc2FnZSB0eXBlcyBNQVkgYmUgY2FycmllZCBpbiBQVFAgVHVubmVsIExTUHMuDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAg ICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNV0N CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAg ICAgICAgTWFyY2ggMjAxMg0KDQoNCjguICBQcm90ZWN0aW9uIGFuZCBSZWR1bmRhbmN5DQoNCiAg IEluIG9yZGVyIHRvIGVuc3VyZSBjb250aW51b3VzIHVuaW50ZXJydXB0ZWQgb3BlcmF0aW9uIG9m IHNsYXZlIGNsb2NrcywNCiAgIHVzdWFsbHkgYXMgYSBnZW5lcmFsIHByYWN0aWNlLCBzbGF2ZSBj bG9ja3MgKG9yIHBvcnRzKSB0cmFjayByZWR1bmRhbnQgDQogICBtYXN0ZXIgY2xvY2tzLg0KCQ0K ICAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvIGVu c3VyZQ0KICAgdGhhdCBwaHlzaWNhbGx5IGRpc2pvaW50IFBUUCB0dW5uZWxzIGFyZSBlc3RhYmxp c2hlZCBiZXR3ZWVuIGEgc2xhdmUgDQogICBjbG9jayBvciBwb3J0IGFuZCByZWR1bmRhbnQgbWFz dGVycyBjbG9ja3Mgb3IgcG9ydHMuDQoNCiAgIFdoZW4gYSBzbGF2ZSBjbG9jayhvciBwb3J0KSBs aXN0ZW4gdG8gcmVkdW5kYW50IG1hc3RlciBjbG9ja3Mgb3IgcG9ydHMsIA0KICAgYW55IHByb2xv bmdlZCBQVFAgTFNQIG9yIFBUUCBQVyBvdXRhZ2Ugd2lsbCB0cmlnZ2VyIHRoZSBzbGF2ZSBjbG9j ayBvcg0KICAgcG9ydCB0byBzd2l0Y2ggdG8gYSByZWR1bmRhbnQgbWFzdGVyIGNsb2NrIG9yIHBv cnQuICBIb3dldmVyIExTUC9QVyANCiAgIHByb3RlY3Rpb24gc3VjaCBhcyBMaW5lYXIgcHJvdGVj dGlvbiBTd2l0Y2hpbmcgKDE6MSwxKzEpLCBSaW5nIA0KICAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg b3IgTVBMUyBGYXN0IFJlcm91dGUgKEZSUikgU0hPVUxEIHN0aWxsIGJlIHVzZWQNCiAgIHRvIHBy b3ZpZGUgcmVzaWxpZW5jeSB0byBpbmRpdmlkdWFsIG5ldHdvcmsgc2VnbWVudCBmYWlsdXJlcy4N Cg0KICAgTm90ZSB0aGF0IGFueSBwcm90ZWN0aW9uIG9yIHJlcm91dGUgbWVjaGFuaXNtIHRoYXQg YWRkcyBhZGRpdGlvbmFsDQogICBsYWJlbCB0byB0aGUgbGFiZWwgc3RhY2ssIHN1Y2ggYXMgRmFj aWxpdHkgQmFja3VwIEZhc3QgUmVyb3V0ZSwgTVVTVA0KICAgZW5zdXJlIHRoYXQgdGhlIHB1c2hl ZCBsYWJlbCBpcyBhIFBUUCBMYWJlbCB0byBlbnN1cmUgcmVjb2duaXRpb24gb2YNCiAgIHRoZSBN UExTIGZyYW1lIGFzIGNvbnRhaW5pbmcgUFRQIG1lc3NhZ2VzIGFzIGl0IHRyYW5zaXRzIHRoZSBi YWNrdXANCiAgIHBhdGguDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2Vw dCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KOS4gIEVDTVANCg0KICAgVG8gZW5zdXJlIHRoZSBvcHRpbWFsIG9wZXJhdGlvbiBvZiBzbGF2 ZSBjbG9ja3MgYW5kIGF2b2lkIGVycm9ycw0KICAgaW50cm9kdWNlZCBieSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGggZGVsYXkgYXN5bW1ldHJ5LCB0aGUgcGh5c2ljYWwNCiAgIHBhdGggZm9yIFBU UCBtZXNzYWdlcyBmcm9tIG1hc3RlciBjbG9jayB0byBzbGF2ZSBDbG9jayBhbmQgdmljZSB2ZXJz YQ0KICAgbXVzdCBiZSB0aGUgc2FtZSBmb3IgYWxsIFBUUCBtZXNzYWdlcyBsaXN0ZWQgaW4gc2Vj dGlvbiA3IGFuZCBtdXN0DQogICBub3QgY2hhbmdlIGV2ZW4gaW4gdGhlIHByZXNlbmNlIG9mIEVD TVAgaW4gdGhlIE1QTFMgbmV0d29yay4NCg0KICAgVG8gZW5zdXJlIHRoZSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGhzIGFyZSB0aGUgc2FtZSBQVFAgTFNQcyBhbmQgUFdzDQogICBTSE9VTEQgTk9U IGJlIHN1YmplY3QgdG8gRUNNUC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQ YWdlIDE3XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxMC4gIE9BTSwgQ29udHJvbCBhbmQgTWFu YWdlbWVudA0KDQogICBJbiBvcmRlciB0byBtYW5hZ2UgUFRQIExTUHMgYW5kIFBUUCBQV3MsIHRo ZXkgTUFZIGNhcnJ5IE9BTSwgQ29udHJvbA0KICAgYW5kIG1hbmFnZW1lbnQgbWVzc2FnZXMuICBU aGVzZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IG1lc3NhZ2VzIGNhbg0KICAgYmUgZGlmZmVyZW50 aWF0ZWQgZnJvbSBQVFAgbWVzc2FnZXMgdmlhIGFscmVhZHkgZGVmaW5lZCBJRVRGIG1ldGhvZHMu DQoNCiAgIEluIHBhcnRpY3VsYXIgQkZEIFtSRkM1ODgwXSwgW1JGQzU4ODRdIGFuZCBMU1AtUGlu ZyBbUkZDNDM4OV0gTUFZIHJ1bg0KICAgb3ZlciBQVFAgTFNQcyB2aWEgVURQL0lQIGVuY2Fwc3Vs YXRpb24gb3IgdmlhIEdBTC9HLUFDSC4gIFRoZXNlDQogICBNYW5hZ2VtZW50IHByb3RvY29scyBh cmUgZWFzaWx5IGlkZW50aWZpZWQgYnkgdGhlIFVEUCBEZXN0aW5hdGlvbg0KICAgUG9ydCBudW1i ZXIgb3IgYnkgR0FML0FDSCByZXNwZWN0aXZlbHkuDQoNCiAgIEFsc28gQkZELCBMU1AtUGluZyBh bmQgb3RoZXIgbWFuYWdlbWVudCBtZXNzYWdlcyBNQVkgcnVuIG92ZXIgUFRQIFBXDQogICB2aWEg b25lIG9mIHRoZSBkZWZpbmVkIFZDQ1ZzIChUeXBlIDEsIDIgb3IgMykgW1JGQzUwODVdLiAgSW4g dGhpcw0KICAgY2FzZSBHLUFDSCwgUm91dGVyIEFsZXJ0IExhYmVsIChSQUwpLCBvciBQVyBsYWJl bCAoVFRMPTEpIGFyZSB1c2VkIHRvDQogICBpZGVudGlmeSBzdWNoIG1hbmFnZW1lbnQgbWVzc2Fn ZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQoxMS4gIFFvUyBDb25zaWRlcmF0aW9ucw0KDQogICBJbiBuZXR3b3JrIGRlcGxveW1lbnRz IHdoZXJlIG5vdCBldmVyeSBMU1IvTEVSIGlzIFBUUC1hd2FyZSwgdGhlbiBpdA0KICAgaXMgaW1w b3J0YW50IHRvIHJlZHVjZSB0aGUgaW1wYWN0IG9mIHRoZSBub24tUFRQLWF3YXJlIExTUi9MRVJz IG9uDQogICB0aGUgdGltaW5nIHJlY292ZXJ5IGluIHRoZSBzbGF2ZSBjbG9jay4gIFRoZSBQVFAg bWVzc2FnZXMgYXJlIHRpbWUNCiAgIGNyaXRpY2FsIGFuZCBtdXN0IGJlIHRyZWF0ZWQgd2l0aCB0 aGUgaGlnaGVzdCBwcmlvcml0eS4gIFRoZXJlZm9yZQ0KICAgMTU4OCBvdmVyIE1QTFMgbWVzc2Fn ZXMgbXVzdCBiZSB0cmVhdGVkIHdpdGggdGhlIGhpZ2hlc3QgcHJpb3JpdHkgaW4NCiAgIHRoZSBy b3V0ZXJzLiAgVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgcHJvcGVyIHNldHVwIG9mIFBUUCB0dW5u ZWxzLg0KICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgUFRQIExTUHMgYXJlIHNldHVwIGFu ZCBtYXJrZWQgcHJvcGVybHkgdG8NCiAgIGluZGljYXRlIEVGLVBIQiBbUkZDMzI0Nl1mb3IgdGhl IENvUyBhbmQgR3JlZW4gW1JGQzI2OTddIGZvciBkcm9wIA0KICAgZWxpZ2liaWxpdHkuDQoNCiAg IEluIG5ldHdvcmsgZGVwbG95bWVudHMgd2hlcmUgZXZlcnkgTFNSL0xFUiBzdXBwb3J0cyBQVFAg TFNQcywgdGhlbiBpdA0KICAgTUFZIE5PVCBiZSByZXF1aXJlZCB0byBhcHBseSB0aGUgc2FtZSBs ZXZlbCBvZiBwcmlvcml0aXphdGlvbiBhcw0KICAgc3BlY2lmaWVkIGFib3ZlLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEyLiAgRkNT IFJlY2FsY3VsYXRpb24NCg0KICAgRXRoZXJuZXQgRkNTIG9mIHRoZSBvdXRlciBlbmNhcHN1bGF0 aW9uIE1VU1QgYmUgcmVjYWxjdWxhdGVkIGF0IGV2ZXJ5DQogICBMU1IgdGhhdCBwZXJmb3JtcyB0 aGUgdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZyBhbmQgRkNTIHJldGVudGlvbg0KICAgZm9y IHRoZSBwYXlsb2FkIEV0aGVybmV0IGRlc2NyaWJlZCBpbiBbUkZDNDcyMF0gTVVTVCBOT1QgYmUg dXNlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy MF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEzLiAgVURQIENoZWNrc3VtIENvcnJlY3Rpb24N Cg0KICAgRm9yIFVEUC9JUCBlbmNhcHN1bGF0aW9uIG1vZGUgb2YgMTU4OCBvdmVyIE1QTFMsIHRo ZSBVRFAgY2hlY2tzdW0gaXMNCiAgIG9wdGlvbmFsIHdoZW4gdXNlZCBmb3IgSVB2NCBlbmNhcHN1 bGF0aW9uIGFuZCBtYW5kYXRvcnkgaW4gY2FzZSBvZg0KICAgSVB2Ni4gIFdoZW4gSVB2NHY2IFVE UCBjaGVja3N1bSBpcyB1c2VkLCBlYWNoIDE1ODgtYXdhcmUgTFNSIG11c3QNCiAgIGVpdGhlciBp bmNyZW1lbnRhbGx5IHVwZGF0ZSB0aGUgVURQIGNoZWNrc3VtIGFmdGVyIHRoZSBDRiB1cGRhdGUg b3INCiAgIHZlcmlmeSB0aGUgVURQIGNoZWNrc3VtIG9uIHJlY2VwdGlvbiBmcm9tIHVwc3RyZWFt IGFuZA0KICAgcmVjYWxjdWxhdGUgdGhlIGNoZWNrc3VtIGNvbXBsZXRlbHkgb24gdHJhbnNtaXNz aW9uIGFmdGVyIENGIHVwZGF0ZQ0KICAgdG8gZG93bnN0cmVhbSBub2RlLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAx MiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoN CjE0LiAgUm91dGluZyBleHRlbnNpb25zIGZvciAxNTg4LWF3YXJlIExTUnMNCg0KICAgTVBMUy1U RSByb3V0aW5nIHJlbGllcyBvbiBleHRlbnNpb25zIHRvIE9TUEYgW1JGQzIzMjhdIFtSRkM1MzQw XSBhbmQNCiAgIElTLUlTIFtJU09dIFtSRkMxMTk1XSBpbiBvcmRlciB0byBhZHZlcnRpc2UgVHJh ZmZpYyBFbmdpbmVlcmluZyAoVEUpDQogICBsaW5rIGluZm9ybWF0aW9uIHVzZWQgZm9yIGNvbnN0 cmFpbnQtYmFzZWQgcm91dGluZy4NCg0KICAgSW5kZWVkLCBpdCBpcyB1c2VmdWwgdG8gYWR2ZXJ0 aXNlIGRhdGEgcGxhbmUgVEUgcm91dGVyIGxpbmsNCiAgIGNhcGFiaWxpdGllcywgc3VjaCBhcyB0 aGUgY2FwYWJpbGl0eSBmb3IgYSByb3V0ZXIgdG8gYmUgMTU4OC1hd2FyZS4NCiAgIFRoaXMgY2Fw YWJpbGl0eSBNVVNUIHRoZW4gYmUgdGFrZW4gaW50byBhY2NvdW50IGR1cmluZyBwYXRoDQogICBj b21wdXRhdGlvbiB0byBwcmVmZXIgb3IgZXZlbiByZXF1aXJlIGxpbmtzIHRoYXQgYWR2ZXJ0aXNl IHRoZW1zZWx2ZXMNCiAgIGFzIDE1ODgtYXdhcmUuICBJbiB0aGlzIHdheSB0aGUgcGF0aCBjYW4g ZW5zdXJlIHRoZSBlbnRyeSBhbmQgZXhpdA0KICAgcG9pbnRzIGludG8gdGhlIExFUnMgYW5kLCBp ZiBkZXNpcmVkLCB0aGUgbGlua3MgaW50byB0aGUgTFNScyBhcmUNCiAgIGFibGUgdG8gcGVyZm9y bSBwb3J0IGJhc2VkIHRpbWVzLXRhbXBpbmcgdGh1cyBtaW5pbWl6aW5nIHRoZWlyIGltcGFjdA0K ICAgb24gdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBzbGF2ZSBjbG9jay4NCg0KICAgRm9yIHRoaXMg cHVycG9zZSwgdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBzcGVjaWZ5IGV4dGVuc2lvbnMgdG8gT1NQ Rg0KICAgYW5kIElTLUlTIGluIG9yZGVyIHRvIGFkdmVydGlzZSAxNTg4IGF3YXJlIGNhcGFiaWxp dGllcyBvZiBhIGxpbmsuDQoNCjE0LjEuICAxNTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBP U1BGDQoNCiAgIE9TUEYgdXNlcyB0aGUgTGluayBUTFYgKFR5cGUgMikgdGhhdCBpcyBpdHNlbGYg Y2FycmllZCB3aXRoaW4gZWl0aGVyDQogICB0aGUgVHJhZmZpYyBFbmdpbmVlcmluZyBMU0Egc3Bl Y2lmaWVkIGluIFtSRkMzNjMwXSBvciB0aGUgT1NQRnYzDQogICBJbnRyYS1BcmVhLVRFIExTQSAo ZnVuY3Rpb24gY29kZSAxMCkgZGVmaW5lZCBpbiBbUkZDNTMyOV0gdG8NCiAgIGFkdmVydGlzZSB0 aGUgVEUgcmVsYXRlZCBpbmZvcm1hdGlvbiBmb3IgdGhlIGxvY2FsbHkgYXR0YWNoZWQgcm91dGVy DQogICBsaW5rcy4gIEZvciBhbiBMU0EgVHlwZSAxMCwgb25lIExTQSBjYW4gY29udGFpbiBvbmUg TGluayBUTFYNCiAgIGluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsaW5rLiAgVGhpcyBleHRlbnNp b24gZGVmaW5lcyBhIG5ldyAxNTg4LQ0KICAgYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIHRoYXQg Y2FuIGJlIGNhcnJpZWQgYXMgcGFydCBvZiB0aGUgTGluayBUTFYuDQoNCiAgIFRoZSAxNTg4LWF3 YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBPUFRJT05BTCBhbmQgTVVTVCBOT1QgYXBwZWFyDQog ICBtb3JlIHRoYW4gb25jZSB3aXRoaW4gdGhlIExpbmsgVExWLiAgSWYgYSBzZWNvbmQgaW5zdGFu Y2Ugb2YgdGhlDQogICAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBwcmVzZW50LCB0 aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUDQogICBvbmx5IHByb2Nlc3MgdGhlIGZpcnN0IGluc3Rh bmNlIG9mIHRoZSBzdWItVExWLiAgSXQgaXMgZGVmaW5lZCBhcw0KICAgZm9sbG93czoNCg0KICAg ICAgMCAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgIEZsYWdzICAgICB8DQogICAgICArLSstKy0rLSst Ky0rLSstKw0KDQogICAgICAgICAgICAgICAgRmlndXJlIDM6IDE1ODgtYXdhcmUgQ2FwYWJpbGl0 eSBUTFYNCg0KDQogICBXaGVyZToNCg0KICAgVHlwZSwgMTYgYml0czogMTU4OC1hd2FyZSBDYXBh YmlsaXR5IFRMViB3aGVyZSB0aGUgdmFsdWUgaXMgVEJEDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDIy XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAg ICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgTGVuZ3RoLCAxNiBiaXRzOiBHaXZlcyB0aGUg bGVuZ3RoIG9mIHRoZSBmbGFncyBmaWVsZCBpbiBvY3RldHMsIGFuZA0KICAgaXMgY3VycmVudGx5 IHNldCB0byAxDQoNCiAgIEZsYWdzLCA4IGJpdHM6IFRoZSBiaXRzIGFyZSBkZWZpbmVkIGxlYXN0 LXNpZ25pZmljYW50LWJpdCAoTFNCKQ0KICAgZmlyc3QsIHNvIGJpdCA3IGlzIHRoZSBsZWFzdCBz aWduaWZpY2FudCBiaXQgb2YgdGhlIGZsYWdzIG9jdGV0Lg0KDQoNCiAgICAgICAwIDEgMiAzIDQg NSA2IDcNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgUmVzZXJ2ZWQgIHxDfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICBGaWd1cmUgNDogRmxhZ3MgRm9ybWF0DQoN Cg0KICAgQ29ycmVjdGlvbiAoQykgZmllbGQgVXBkYXRlIGZpZWxkLCAxIGJpdDogU2V0dGluZyB0 aGUgQyBiaXQgdG8gMQ0KICAgaW5kaWNhdGVzIHRoYXQgdGhlIGxpbmsgaXMgY2FwYWJsZSBvZiBy ZWNvZ25pemluZyB0aGUgUFRQIGV2ZW50DQogICBwYWNrZXRzIGFuZCBjYW4gY29tcGVuc2F0ZSBm b3IgcmVzaWRlbmNlIHRpbWUgYnkgdXBkYXRpbmcgdGhlIFBUUA0KICAgcGFja2V0IENvcnJlY3Rp b24gRmllbGQuICBXaGVuIHRoaXMgaXMgc2V0IHRvIDAsIGl0IG1lYW5zIHRoYXQgdGhpcw0KICAg bGluayBjYW5ub3QgcGVyZm9ybSB0aGUgcmVzaWRlbmNlIHRpbWUgY29ycmVjdGlvbiBidXQgaXMg Y2FwYWJsZSBvZg0KICAgcGVyZm9ybWluZyBNUExTIGZyYW1lIGZvcndhcmRpbmcgb2YgdGhlIGZy YW1lcyB3aXRoIFBUUCBsYWJlbHMgdXNpbmcNCiAgIGEgbWV0aG9kIHRoYXQgc3VwcG9ydCB0aGUg ZW5kIHRvIGVuZCBkZWxpdmVyeSBvZiBhY2N1cmF0ZSB0aW1pbmcuDQogICBUaGUgZXhhY3QgbWV0 aG9kIGlzIG5vdCBkZWZpbmVkIGhlcmVpbi4NCg0KICAgUmVzZXJ2ZWQsIDcgYml0czogUmVzZXJ2 ZWQgZm9yIGZ1dHVyZSB1c2UuICBUaGUgcmVzZXJ2ZWQgYml0cyBtdXN0IGJlDQogICBpZ25vcmVk IGJ5IHRoZSByZWNlaXZlci4NCg0KICAgVGhlIDE1ODgtYXdhcmUgQ2FwYWJpbGl0eSBzdWItVExW IGlzIGFwcGxpY2FibGUgdG8gYm90aCBPU1BGdjIgYW5kDQogICBPU1BGdjMuDQoNCjE0LjIuICAx NTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBJUy1JUw0KDQogICBUaGUgSVMtSVMgVHJhZmZp YyBFbmdpbmVlcmluZyBbUkZDMzc4NF0gZGVmaW5lcyB0aGUgaW50cmEtYXJlYQ0KICAgdHJhZmZp YyBlbmdpbmVlcmluZyBlbmhhbmNlbWVudHMgYW5kIHVzZXMgdGhlIEV4dGVuZGVkIElTDQogICBS ZWFjaGFiaWxpdHkgVExWIChUeXBlIDIyKSBbUkZDNTMwNV0gdG8gY2FycnkgdGhlIHBlciBsaW5r IFRFLXJlbGF0ZWQNCiAgIGluZm9ybWF0aW9uLiAgVGhpcyBleHRlbnNpb24gZGVmaW5lcyBhIG5l dyAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLQ0KICAgVExWIHRoYXQgY2FuIGJlIGNhcnJpZWQg YXMgcGFydCBvZiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5IFRMVi4NCg0KICAgVGhlIDE1 ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGlzIE9QVElPTkFMIGFuZCBNVVNUIE5PVCBhcHBl YXINCiAgIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5 IFRMViBvciB0aGUgTXVsdGktDQogICBUb3BvbG9neSAoTVQpIEludGVybWVkaWF0ZSBTeXN0ZW1z IFRMViAodHlwZSAyMjIpIHNwZWNpZmllZCBpbg0KICAgW1JGQzUxMjBdLiAgSWYgYSBzZWNvbmQg aW5zdGFuY2Ugb2YgdGhlIDE1ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWDQogICBpcyBwcmVz ZW50LCB0aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUIG9ubHkgcHJvY2VzcyB0aGUgZmlyc3QgaW5z dGFuY2UNCiAgIG9mIHRoZSBzdWItVExWLg0KDQogICBUaGUgZm9ybWF0IG9mIHRoZSBJUy1JUyAx NTg4LWF3YXJlIHN1Yi1UTFYgaXMgaWRlbnRpY2FsIHRvIHRoZSBUTFYNCiAgIGZvcm1hdCB1c2Vk IGJ5IHRoZSBUcmFmZmljIEVuZ2luZWVyaW5nIEV4dGVuc2lvbnMgdG8gSVMtSVMgW1JGQzM3ODRd Lg0KICAgVGhhdCBpcywgdGhlIFRMViBpcyBjb21wcmlzZWQgb2YgMSBvY3RldCBmb3IgdGhlIHR5 cGUsIDEgb2N0ZXQNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNl cHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQogICBzcGVjaWZ5aW5nIHRoZSBUTFYgbGVuZ3RoLCBhbmQgYSB2YWx1ZSBmaWVsZC4gIFRo ZSBMZW5ndGggZmllbGQNCiAgIGRlZmluZXMgdGhlIGxlbmd0aCBvZiB0aGUgdmFsdWUgcG9ydGlv biBpbiBvY3RldHMuDQoNCiAgICAgIDAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMg0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICB8ICAgICBUeXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgRmxhZ3Mg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQoNCiAgICAgICAgICAgICBGaWd1cmUgNTogMTU4OC1hd2FyZSBDYXBhYmlsaXR5IHN1 Yi1UTFYNCg0KICAgV2hlcmU6DQoNCiAgIFR5cGUsIDggYml0czogMTU4OC1hd2FyZSBDYXBhYmls aXR5IHN1Yi1UTFYgd2hlcmUgdGhlIHZhbHVlIGlzIFRCRA0KDQogICBMZW5ndGgsIDggYml0czog R2l2ZXMgdGhlIGxlbmd0aCBvZiB0aGUgZmxhZ3MgZmllbGQgaW4gb2N0ZXRzLCBhbmQgaXMNCiAg IGN1cnJlbnRseSBzZXQgdG8gMQ0KDQogICBGbGFncywgOCBiaXRzOiBUaGUgYml0cyBhcmUgZGVm aW5lZCBsZWFzdC1zaWduaWZpY2FudC1iaXQgKExTQikNCiAgIGZpcnN0LCBzbyBiaXQgNyBpcyB0 aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0IG9mIHRoZSBmbGFncyBvY3RldC4NCg0KDQogICAgICAg MCAxIDIgMyA0IDUgNiA3DQogICAgICArLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgIFJlc2Vy dmVkICB8Q3wNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgRmlndXJlIDY6IEZsYWdz IEZvcm1hdA0KDQogICBDb3JyZWN0aW9uIChDKSBmaWVsZCBVcGRhdGUgZmllbGQsIDEgYml0OiBT ZXR0aW5nIHRoZSBDIGJpdCB0byAxDQogICBpbmRpY2F0ZXMgdGhhdCB0aGUgbGluayBpcyBjYXBh YmxlIG9mIHJlY29nbml6aW5nIHRoZSBQVFAgZXZlbnQNCiAgIHBhY2tldHMgYW5kIGNhbiBjb21w ZW5zYXRlIGZvciByZXNpZGVuY2UgdGltZSBieSB1cGRhdGluZyB0aGUgUFRQDQogICBwYWNrZXQg Q29ycmVjdGlvbiBGaWVsZC4gIFdoZW4gdGhpcyBpcyBzZXQgdG8gMCwgaXQgbWVhbnMgdGhhdCB0 aGlzDQogICBsaW5rIGNhbm5vdCBwZXJmb3JtIHRoZSByZXNpZGVuY2UgdGltZSBjb3JyZWN0aW9u IGJ1dCBpcyBjYXBhYmxlIG9mDQogICBwZXJmb3JtaW5nIE1QTFMgZnJhbWUgZm9yd2FyZGluZyBv ZiB0aGUgZnJhbWVzIHdpdGggUFRQIGxhYmVscyB1c2luZw0KICAgYSBtZXRob2QgdGhhdCBzdXBw b3J0IHRoZSBlbmQgdG8gZW5kIGRlbGl2ZXJ5IG9mIGFjY3VyYXRlIHRpbWluZy4NCiAgIFRoZSBl eGFjdCBtZXRob2QgaXMgbm90IGRlZmluZWQgaGVyZWluLg0KDQogICBSZXNlcnZlZCwgNyBiaXRz OiBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gIFRoZSByZXNlcnZlZCBiaXRzIG11c3QgYmUNCiAg IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJp LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAg W1BhZ2UgMjRdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMg ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxNS4gIFJTVlAtVEUgRXh0ZW5zaW9u cyBmb3Igc3VwcG9ydCBvZiAxNTg4DQoNCiAgIFJTVlAtVEUgc2lnbmFsaW5nIE1BWSBiZSB1c2Vk IHRvIHNldHVwIHRoZSBQVFAgTFNQcy4gIEEgbmV3IFJTVlANCiAgIG9iamVjdCBpcyBkZWZpbmVk IHRvIHNpZ25hbCB0aGF0IHRoaXMgaXMgYSBQVFAgTFNQLiAgVGhlIE9GRlNFVCB0bw0KICAgdGhl IHN0YXJ0IG9mIHRoZSBQVFAgbWVzc2FnZSBoZWFkZXIgTUFZIGFsc28gYmUgc2lnbmFsZWQuDQog ICBJbXBsZW1lbnRhdGlvbnMgY2FuIHRyaXZpYWxseSBsb2NhdGUgdGhlIENvcnJlY3Rpb24gRmll bGQgKENGKQ0KICAgbG9jYXRpb24gZ2l2ZW4gdGhpcyBpbmZvcm1hdGlvbi4gIFRoZSBPRkZTRVQg cG9pbnRzIHRvIHRoZSBzdGFydCBvZg0KICAgdGhlIFBUUCBoZWFkZXIgYXMgYSBub2RlIG1heSB3 YW50IHRvIGNoZWNrIHRoZSBQVFAgbWVzc2FnZSBUeXBlIGJlZm9yZQ0KICAgaXQgdG91Y2hlcyB0 aGUgY29ycmVjdGlvbiBGaWVsZCAoQ0YpLiAgVGhlIE9GRlNFVCBpcyBjb3VudGVkIGZyb20gYm90 dG9tDQogICBvZiBsYWJlbCBzdGFjay4NCg0KICAgVGhlIExTUnMgdGhhdCByZWNlaXZlIGFuZCBw cm9jZXNzIHRoZSBSU1ZQLVRFL0dNUExTIG1lc3NhZ2VzIE1BWSB1c2UNCiAgIHRoZSBPRkZTRVQg dG8gbG9jYXRlIHRoZSBzdGFydCBvZiB0aGUgUFRQIG1lc3NhZ2UgaGVhZGVyLg0KDQogICBOb3Rl IHRoYXQgdGhlIG5ldyBvYmplY3QvVExWIE1VU1QgYmUgaWdub3JlZCBieSBMU1JzIHRoYXQgYXJl IG5vdA0KICAgY29tcGxpYW50IHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KICAgVGhlIG5ldyBS U1ZQIDE1ODhfUFRQX0xTUCBvYmplY3Qgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHNpZ25hbGluZyBQ VFANCiAgIExTUHMgYW5kIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0KICAgICAgICAgICAgICAg ICAgIDAgICAgICAgICAgICAgMSAgICAgICAgICAgICAyICAgICAgICAgICAgIDMNCiAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgfCAgICAgICBMZW5ndGggKGJ5dGVzKSAgICAgIHwgIENsYXNzLU51 bSAgfCAgIEMtVHlwZSAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgIHwgT2Zmc2V0IHRv IGxvY2F0ZSB0aGUgc3RhcnQgb2YgdGhlIFBUUCBtZXNzYWdlIGhlYWRlciAgfA0KICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0rDQoNCiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3OiBSU1ZQIDE1ODhfUFRQX0xTUCBv YmplY3QNCg0KDQogICBUaGUgaW5ncmVzcyBMU1IgTVVTVCBpbmNsdWRlIHRoaXMgb2JqZWN0IGlu IHRoZSBSU1ZQIFBBVEggTWVzc2FnZS4NCiAgIEl0IGlzIGp1c3QgYSBub3JtYWwgUlNWUCBwYXRo IHRoYXQgaXMgZXhjbHVzaXZlbHkgc2V0IHVwIGZvciBQVFANCiAgIG1lc3NhZ2VzLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KMTYuICBCZWhhdmlvciBvZiBMRVIvTFNSDQoNCjE2LjEuIEJlaGF2 aW9yIG9mIDE1ODgtY2FwYWJsZS9hd2FyZSBMRVINCg0KICAgQSAxNTg4LWNhcGFibGUvYXdhcmUg TEVSIGFkdmVydGlzZXMgaXQncyAxNTg4LWNhcGFiaWxpdHkgdmlhIHRoZSBPU1BGIA0KICAgb3Ig SVMtSVMgcHJvY2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gIA0KICAgVGhlIDE1ODgtY2FiYWxlL2F3YXJlIExFUiB0aGVuIHNpZ25hbHMg UFRQIExTUHMgYnkgaW5jbHVkaW5nIHRoZSANCiAgIDE1ODhfUFRQX0xTUCBvYmplY3QgaW4gdGhl IFJTVlAtVEUgc2lnbmFsaW5nLg0KDQogICBXaGVuIGEgMTU4OCBtZXNzYWdlIGlzIHJlY2VpdmVk IGZyb20gYSBub24tTVBMUyBpbnRlcmZhY2UsIHRoZSBMRVINCiAgIE1VU1QgcmVkaXJlY3QgdGhl bSB0byBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgUFRQIExTUC4gIFdoZW4gYSAxNTg4DQogICBv dmVyIE1QTFMgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGFuIE1QTFMgaW50ZXJmYWNlLCB0aGUg cHJvY2Vzc2luZw0KICAgaXMgc2ltaWxhciB0byAxNTg4LWF3YXJlIExTUiBwcm9jZXNzaW5nLg0K DQoxNi4yLiBCZWhhdmlvciBvZiAxNTg4LWNhcGFibGUvYXdhcmUgTFNSDQoNCiAgIDE1ODgtY2Fw YWJsZS9hd2FyZSBMU1JzIGFyZSBMU1JzIHRoYXQgdW5kZXJzdGFuZCB0aGUgMTU4OF9QVFBfTFNQ IFJTVlANCiAgIG9iamVjdCBhbmQgY2FuIHBlcmZvcm0gMTU4OCBwcm9jZXNzaW5nIChlLmcudHJh bnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZykuDQoNCiAgIEEgMTU4OC1jYXBhYmxlIExTUiBhZHZl cnRpc2VzIGl0J3MgMTU4OC1jYXBhYmlsaXR5IHZpYSB0aGUgT1NQRiBvciBJUy1JUw0KICAgcHJv Y2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4NCg0KICAgV2hlbiBhIDE1ODgtY2FwYWJsZS9hd2FyZSBMU1IgZGlzdHJpYnV0ZXMgYSBsYWJl bCBmb3IgUFRQIExTUCwgaXQgbWFpbnRhaW5zDQogICB0aGlzIGluZm9ybWF0aW9uLiAgV2hlbiB0 aGUgMTU4OC1jYXBhYmxlL2F3YXJlIExTUiByZWNlaXZlcyBhbiBNUExTIHBhY2tldCwNCiAgIGl0 IHBlcmZvcm1zIGEgbGFiZWwgbG9va3VwIGFuZCBpZiB0aGUgbGFiZWwgbG9va3VwIGluZGljYXRl cyBpdCBpcyBhIFBUUCANCiAgIGxhYmVsIHRoZW4gZnVydGhlciBwYXJzaW5nIG11c3QgYmUgZG9u ZSB0byBwb3NpdGl2ZWx5IGlkZW50aWZ5IHRoYXQgdGhlIA0KICAgIHBheWxvYWQgaXMgMTU4OCBh bmQgbm90IE9BTSwgQkZEIG9yIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQuDQoNCiAgIFJ1bGluZyBv dXQgbm9uLTE1ODggbWVzc2FnZXMgY2FuIGVhc2lseSBiZSBkb25lIHdoZW4gcGFyc2luZw0KICAg aW5kaWNhdGVzIHRoZSBwcmVzZW5jZSBvZiBHQUwsIEFDSCBvciBWQ0NWIChUeXBlIDEsIDIsIDMp IG9yIHdoZW4gdGhlDQogICBVRFAgcG9ydCBudW1iZXIgZG9lcyBub3QgbWF0Y2ggb25lIG9mIHRo ZSAxNTg4IFVEUCBwb3J0IG51bWJlcnMuDQoNCiAgIEFmdGVyIGEgMTU4OCBtZXNzYWdlIGlzIHBv c2l0aXZlbHkgaWRlbnRpZmllZCBpbiBhIFBUUCBMU1AsIHRoZSBQVFANCiAgIG1lc3NhZ2UgdHlw ZSBpbmRpY2F0ZXMgd2hldGhlciBhbnkgdGltZXN0YW1wIHByb2Nlc3NpbmcgaXMgcmVxdWlyZWQu DQogICBBZnRlciAxNTg4IHByb2Nlc3NpbmcgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgYXMgYSBu b3JtYWwgTVBMUyBwYWNrZXQNCiAgIHRvIGRvd25zdHJlYW0gbm9kZS4NCg0KMTYuMy4gQmVoYXZp b3Igb2Ygbm9uLTE1ODgtY2FwYWJsZS9hd2FyZSBMU1INCg0KICAgVGhlcmUgYXJlIHR3byB0eXBl cyBvZiBMU1JzIHRoYXQgY2FuP3QgcGFydGljaXBhdGUgaW4gcHJvY2Vzc2luZyBQVFAgDQogICBt ZXNzYWdlcyBpbiBhbiBSU1ZQLVRFIHNpZ25hbGVkIFBUUCBMU1A6DQoNCiAgIDEpIExTUnMgdGhh dCBkb24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb2Nlc3MgMTU4OCBwYWNrZXRzIChlLmcuIA0K ICAgICAgcGVyZm9ybSB0cmFuc3BhcmVudCBjbG9jayBwcm9jZXNzaW5nKS4gVGhlc2UgTFNScyBh cmUgY2FsbGVkIA0KICAgICAgbm9uLTE1ODgtY2FwYWJsZSBMU1JzLg0KDQogICAyKSBMU1JzIHRo YXQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBwcm9jZXNzIDE1ODggcGFja2V0cyAoZS5nLiANCiAg ICAgIHBlcmZvcm0gdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZywgYnV0IGRvbid0IHVuZGVy c3RhbmQgICAgICAgdGhlIDE1ODhfUFRQX0xTUCBSU1ZQIG9iamVjdC4gVGhlc2UgTFNScyBhcmUg Y2FsbGVkIA0KICAgICAgbm9uLTE1ODgtYXdhcmUgTFNScy4NCiAgIA0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy Nl0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQpJdCBpcyBtb3N0IGJlbmVmaWNpYWwgdGhhdCBhbGwg TFNScyBpbiB0aGUgcGF0aCBvZiBhIFBUUCBMU1AgYmUgMTU4OC0NCiAgIENhcGFibGUgYW5kIGF3 YXJlIExTUnMuICBUaGlzIHdvdWxkIGVuc3VyZSB0aGUgaGlnaGVzdCBxdWFsaXR5IHRpbWUgDQog ICBhbmQgY2xvY2sgc3luY2hyb25pemF0aW9uIGJ5IDE1ODggU2xhdmUgQ2xvY2tzLiBIb3dldmVy LCB0aGlzIA0KICAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIHRoYXQgYWxsIExTUnMg aW4gcGF0aCBvZiBhIFBUUCBMU1AgDQogICBiZSAxNTg4LWNhcGFibGUgYW5kIGF3YXJlLg0KDQoN CiAgIE5vbi0xNTg4LWNhYmFibGUgYW5kIG5vbi0xNTg4LWF3YXJlIExTUnMgaWdub3JlIHRoZSBS U1ZQIA0KICAgMTU4OF9QVFBfTFNQIG9iamVjdCBhbmQganVzdCBzd2l0Y2ggdGhlIE1QTFMgcGFj a2V0cyBjYXJyeWluZyAxNTg4IA0KICAgbWVzc2FnZXMgYXMgZGF0YSBwYWNrZXRzIGFuZCBkb24n dCBwZXJmb3JtIGFueSB0aW1lc3RhbXAgcmVsYXRlZCANCiAgIHByb2Nlc3NpbmcuICBIb3dldmVy IGFzIGV4cGxhaW5lZCBpbiBRb1Mgc2VjdGlvbiB0aGUgMTU4OCBvdmVyIE1QTFMgDQogICBwYWNr ZXRzIE1VU1QgYmUgc3RpbGwgYmUgdHJlYXRlZCB3aXRoIHRoZSBoaWdoZXN0IHByaW9yaXR5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDEyDQoNCg0KMTcuICBPdGhlciBjb25zaWRlcmF0aW9ucw0KDQogICBUaGUgdXNlIG9mIEV4cGxp Y2l0IE51bGwgKExhYmVsPSAwIG9yIDIpIGlzIGFjY2VwdGFibGUgYXMgbG9uZyBhcw0KICAgZWl0 aGVyIHRoZSBFeHBsaWNpdCBOdWxsIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFiZWwN CiAgIChhcHBsaWNhYmxlIG9ubHkgdG8gVURQL0lQIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBsYWJl bCBiZWxvdyB0aGUNCiAgIEV4cGxpY2l0IE51bGwgbGFiZWwgaXMgYSBQVFAgbGFiZWwuDQoNCiAg IFRoZSB1c2Ugb2YgUGVudWx0aW1hdGUgSG9wIFBvcCAoUEhQKSBpcyBhY2NlcHRhYmxlIGFzIGxv bmcgYXMgZWl0aGVyDQogICB0aGUgUEhQIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFi ZWwgKGFwcGxpY2FibGUgb25seSB0byBVRFAvSVANCiAgIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBs YWJlbCBiZWxvdyB0aGUgUEhQIGxhYmVsIGlzIGEgUFRQIGxhYmVsLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KMTguICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBNUExTIFBXIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGluIGdlbmVyYWwgYXJlIGRpc2N1c3NlZCBpbiBbUkZDMzk4NV0NCiAgIGFuZCBbUkZDNDQ0 N10sYW5kIHRob3NlIGNvbnNpZGVyYXRpb25zIGFsc28gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4N Cg0KICAgQW4gZXhwZXJpbWVudGFsIHNlY3VyaXR5IHByb3RvY29sIGlzIGRlZmluZWQgaW4gW0lF RUVdLiAgVGhlIFBUUA0KICAgc2VjdXJpdHkgZXh0ZW5zaW9uIGFuZCBwcm90b2NvbCBwcm92aWRl cyBncm91cCBzb3VyY2UgYXV0aGVudGljYXRpb24sDQogICBtZXNzYWdlIGludGVncml0eSwgYW5k IHJlcGxheSBhdHRhY2sgcHJvdGVjdGlvbiBmb3IgUFRQIG1lc3NhZ2VzLg0KDQoNCjE5LiAgQXBw bGljYWJpbGl0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIDE1ODggb3ZlciBNUExTIHRyYW5zcG9ydCBt ZXRob2RzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgYXBwbGllcyB0byB0aGUgZm9s bG93aW5nIG5ldHdvcmsgRWxlbWVudHM6DQoNCiAgLSBBbiBMRVIgcmVjZWl2ZXMgSVAgb3IgRXRo ZXJuZXQgRW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGEgDQogICAgbm9uLU1QTFMgaW50 ZXJmYWNlIGFuZCBmb3J3YXJkcyB0aGVtIG92ZXIgTFNQL1BXIGJ5LCB3aGlsZSBwZXJmb3JtaW5n DQogICAgVEMgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExFUiByZWNlaXZlcyBNUExTIGVuY2Fwc3Vs YXRlZCBQVFAgbWVzc2FnZXMgYW5kIGZvcndhcmRzIHRoZW0NCiAgICBhcyBJUCBvciBFdGhlcm5l dCBFbmNhcHN1bGF0ZWQgUFRQIG1lc3NhZ2VzIHRvIGEgbm9uLSAgICBNUExTIGludGVyZmFjZSwg d2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgZnVuY3Rpb25hbGl0eS0gQW4gTEVSIA0KICAgIHJlY2Vp dmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBhbmQgdGVybWluYXRlcyB0aGVtLCB3 aGlsZSANCiAgICBwZXJmb3JtaW5nIHRoZSBPQyBvciBCQyBmdW5jdGlvbmFsaXR5DQogIC0gQW4g TFNSIHJlY2VpdmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGFuIE1QTFMg aW50ZXJmYWNlDQogICAgYW5kIGZvcndhcmRzIHRoZW0gdG8gYW5vdGhlciBNUExTIGludGVyZmFj ZSwgd2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgDQogICAgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExT UiByZWNlaXZlcyBNUExTIGVuY2Fwc3VsYXRlZCBQVFAgbWVzc2FnZXMgYW5kIHRlcm1pbmF0ZXMg dGhlbSwgDQogICAgd2hpbGUgcGVyZm9ybWluZyB0aGUgT0Mgb3IgQkMgZnVuY3Rpb25hbGl0eQ0K DQogICBUaGlzIGRvY3VtZW50IGFsc28gc3VwcG9ydHMgdGhlIGNhc2Ugd2hlcmUgbm90IGFsbCBM U1JzL0xFUnMgYXJlIDE1ODgNCiAgIG92ZXIgTVBMUyBjYXBhYmxlLiBJdCBhbHNvIHN1cHBvcnRz IHRoZSBjYXNlIHdoZXJlIG5vdCBhbGwgTEVSL0xTUiANCiAgIGludGVyZmFjZXMgYXJlIDE1ODgg b3ZlciBNUExTIGNhcGFibGUuDQoNCg0KDQogICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAyOV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjIwLiAgQWNr bm93bGVkZ2VtZW50cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEx1Y2Eg TWFydGluaSwgUm9uIENvaGVuLCBZYWFrb3YNCiAgIFN0ZWluLCBUYWwgTWl6cmFoaSwgU3RlZmFu byBSdWZmaW5pLCBMdWNhIE1vbml0aSBhbmQgb3RoZXIgbWVtYmVycyANCiAgIG9mIElFVEYgZm9y IHJldmlld2luZyAgYW5kIHByb3ZpZGluZyBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAxMg0KDQoNCjIxLiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQoyMS4xLiAgSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgT1NQRg0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJlZ2lzdHJ5 IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiBhbiBPU1BGDQogICBURSBMaW5rIFRMViAodHlw ZSAyKS4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBzdWItVExWDQogICBjb2Rl cG9pbnQgZm9yIHRoZSAxNTg4YXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGNhcnJpZWQgd2l0aGlu IHRoZQ0KICAgUm91dGVyIExpbmsgVExWLg0KDQogICAgICBWYWx1ZSAgICAgICAgICAgIFN1Yi1U TFYgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlcw0KICAgICAgLS0tLS0gICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gICAgICAgICAgIC0tLS0tLS0tLS0NCiAgICAgICBUQkQgICAgICAgMTU4 OGF3YXJlIG5vZGUgc3ViLVRMViAgICAgICAgKHRoaXMgZG9jdW1lbnQpDQoNCjIxLjIuICBJQU5B IENvbnNpZGVyYXRpb25zIGZvciBJUy1JUw0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJl Z2lzdHJ5IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiB0aGUgSVMtSVMNCiAgIEV4dGVuZGVk IElTIFJlYWNhYmlsaXR5IFRMVi4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBz dWItDQogICBUTFYgY29kZS1wb2ludCBmb3IgdGhlIDE1ODhhd2FyZSBjYXBhYmlsaXR5IHN1Yi1U TFYgY2FycmllZCB3aXRoaW4NCiAgIHRoZSBFeHRlbmRlZCBJUyBSZWFjYWJpbGl0eSBUTFYuDQoN Cg0KICAgICAgVmFsdWUgICAgICAgICAgICBTdWItVExWICAgICAgICAgICAgICAgICAgIFJlZmVy ZW5jZXMNCiAgICAgIC0tLS0tICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAt LS0tLS0tLS0tDQogICAgICAgVEJEICAgICAgIDE1ODhhd2FyZSBub2RlIHN1Yi1UTFYgICAgICAg ICh0aGlzIGRvY3VtZW50KQ0KDQoyMS4zLiAgSUFOQSBDb25zaWRlcmF0aW9ucyBmb3IgUlNWUA0K DQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhc3NpZ24gYSBuZXcgQ2xhc3MgTnVtYmVyIGZvciAx NTg4IFBUUCBMU1ANCiAgIG9iamVjdCB0aGF0IGlzIHVzZWQgdG8gc2lnbmFsIFBUUCBMU1BzLg0K DQogICAxNTg4IFBUUCBMU1AgT2JqZWN0DQoNCiAgIENsYXNzLU51bSBvZiB0eXBlIDExYmJiYmJi DQoNCiAgIFN1Z2dlc3RlZCB2YWx1ZSBUQkQNCg0KICAgRGVmaW5lZCBDVHlwZTogMSAoMTU4OCBQ VFAgTFNQKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMjIuICBSZWZlcmVuY2VzDQoNCjIyLjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcw0KDQogICBbSUVFRV0gICAgIElFRUUgMTU4OC0yMDA4LCAiSUVFRSBTdGFuZGFy ZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sNCiAgICAgICAgICAgICAgU3luY2hyb25pemF0aW9uIFBy b3RvY29sIGZvciBOZXR3b3JrZWQgTWVhc3VyZW1lbnQgYW5kDQogICAgICAgICAgICAgIENvbnRy b2wgU3lzdGVtcyIuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMzOTg1XSAgQnJ5YW50 LCBTLiBhbmQgUC4gUGF0ZSwgIlBzZXVkbyBXaXJlIEVtdWxhdGlvbiBFZGdlLXRvLQ0KICAgICAg ICAgICAgICBFZGdlIChQV0UzKSBBcmNoaXRlY3R1cmUiLCBSRkMgMzk4NSwgTWFyY2ggMjAwNS4N Cg0KICAgW1JGQzQzODldICBUaGFsZXIsIEQuLCBUYWx3YXIsIE0uLCBhbmQgQy4gUGF0ZWwsICJO ZWlnaGJvciBEaXNjb3ZlcnkNCiAgICAgICAgICAgICAgUHJveGllcyAoTkQgUHJveHkpIiwgUkZD IDQzODksIEFwcmlsIDIwMDYuDQoNCiAgIFtSRkM0NDQ3XSAgTWFydGluaSwgTC4sIFJvc2VuLCBF LiwgRWwtQWF3YXIsIE4uLCBTbWl0aCwgVC4sIGFuZCBHLg0KICAgICAgICAgICAgICBIZXJvbiwg IlBzZXVkb3dpcmUgU2V0dXAgYW5kIE1haW50ZW5hbmNlIFVzaW5nIHRoZSBMYWJlbA0KICAgICAg ICAgICAgICBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkiLCBSRkMgNDQ0NywgQXByaWwgMjAw Ni4NCg0KICAgW1JGQzQ0NDhdICBNYXJ0aW5pLCBMLiwgUm9zZW4sIEUuLCBFbC1BYXdhciwgTi4s IGFuZCBHLiBIZXJvbiwNCiAgICAgICAgICAgICAgIkVuY2Fwc3VsYXRpb24gTWV0aG9kcyBmb3Ig VHJhbnNwb3J0IG9mIEV0aGVybmV0IG92ZXIgTVBMUw0KICAgICAgICAgICAgICBOZXR3b3JrcyIs IFJGQyA0NDQ4LCBBcHJpbCAyMDA2Lg0KDQogICBbUkZDNDcyMF0gIE1hbGlzLCBBLiwgQWxsYW4s IEQuLCBhbmQgTi4gRGVsIFJlZ25vLCAiUHNldWRvd2lyZQ0KICAgICAgICAgICAgICBFbXVsYXRp b24gRWRnZS10by1FZGdlIChQV0UzKSBGcmFtZSBDaGVjayBTZXF1ZW5jZQ0KICAgICAgICAgICAg ICBSZXRlbnRpb24iLCBSRkMgNDcyMCwgTm92ZW1iZXIgMjAwNi4NCg0KICAgW1JGQzUwODVdICBO YWRlYXUsIFQuIGFuZCBDLiBQaWduYXRhcm8sICJQc2V1ZG93aXJlIFZpcnR1YWwgQ2lyY3VpdA0K ICAgICAgICAgICAgICBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChWQ0NWKTogQSBDb250cm9s IENoYW5uZWwgZm9yDQogICAgICAgICAgICAgIFBzZXVkb3dpcmVzIiwgUkZDIDUwODUsIERlY2Vt YmVyIDIwMDcuDQoNCiAgIFtSRkM1ODgwXSAgS2F0eiwgRC4gYW5kIEQuIFdhcmQsICJCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uDQogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4 ODAsIEp1bmUgMjAxMC4NCg0KICAgW1JGQzU4ODRdICBBZ2dhcndhbCwgUi4sIEtvbXBlbGxhLCBL LiwgTmFkZWF1LCBULiwgYW5kIEcuIFN3YWxsb3csDQogICAgICAgICAgICAgICJCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGZvciBNUExTIExhYmVsDQogICAgICAgICAg ICAgIFN3aXRjaGVkIFBhdGhzIChMU1BzKSIsIFJGQyA1ODg0LCBKdW5lIDIwMTAuDQoNCjIyLjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJLUQuaWV0Zi1wd2UzLWZhdC1wd10NCiAg ICAgICAgICAgICAgQnJ5YW50LCBTLiwgRmlsc2ZpbHMsIEMuLCBEcmFmeiwgVS4sIEtvbXBlbGxh LCBWLiwgUmVnYW4sDQogICAgICAgICAgICAgIEouLCBhbmQgUy4gQW1hbnRlLCAiRmxvdyBBd2Fy ZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMNCiAgICAgICAgICAgICAgb3ZlciBhbiBNUExTIFBh Y2tldCBTd2l0Y2hlZCBOZXR3b3JrIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZh dC1wdy0wNyAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMS4NCg0KDQoNCg0KRGF2YXJpLCBl dCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1Bh Z2UgMzJdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIFtJU09dICAgICAgSVNPL0lFQyAx MDU4OToxOTkyLCAiSW50ZXJtZWRpYXRlIHN5c3RlbSB0byBJbnRlcm1lZGlhdGUNCiAgICAgICAg ICAgICAgc3lzdGVtIHJvdXRlaW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHByb3RvY29sIGZvciB1 c2UgaW4NCiAgICAgICAgICAgICAgY29uanVuY3Rpb24gd2l0aCB0aGUgUHJvdG9jb2wgZm9yIHBy b3ZpZGluZyB0aGUNCiAgICAgICAgICAgICAgQ29ubmVjdGlvbmxlc3MtbW9kZSBOZXR3b3JrIFNl cnZpY2UgKElTTyA4NDczKSIuDQoNCiAgIFtSRkMxMTk1XSAgQ2FsbG9uLCBSLiwgIlVzZSBvZiBP U0kgSVMtSVMgZm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZA0KICAgICAgICAgICAgICBkdWFsIGVu dmlyb25tZW50cyIsIFJGQyAxMTk1LCBEZWNlbWJlciAxOTkwLg0KDQogICBbUkZDMjMyOF0gIE1v eSwgSi4sICJPU1BGIFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsIEFwcmlsIDE5OTguDQoN CiAgIFtSRkMzNjMwXSAgS2F0eiwgRC4sIEtvbXBlbGxhLCBLLiwgYW5kIEQuIFlldW5nLCAiVHJh ZmZpYyBFbmdpbmVlcmluZw0KICAgICAgICAgICAgICAoVEUpIEV4dGVuc2lvbnMgdG8gT1NQRiBW ZXJzaW9uIDIiLCBSRkMgMzYzMCwNCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMuDQoNCiAg IFtSRkMzNzg0XSAgU21pdCwgSC4gYW5kIFQuIExpLCAiSW50ZXJtZWRpYXRlIFN5c3RlbSB0byBJ bnRlcm1lZGlhdGUNCiAgICAgICAgICAgICAgU3lzdGVtIChJUy1JUykgRXh0ZW5zaW9ucyBmb3Ig VHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIiwNCiAgICAgICAgICAgICAgUkZDIDM3ODQsIEp1bmUg MjAwNC4NCg0KICAgW1JGQzQ5NzBdICBMaW5kZW0sIEEuLCBTaGVuLCBOLiwgVmFzc2V1ciwgSlAu LCBBZ2dhcndhbCwgUi4sIGFuZCBTLg0KICAgICAgICAgICAgICBTaGFmZmVyLCAiRXh0ZW5zaW9u cyB0byBPU1BGIGZvciBBZHZlcnRpc2luZyBPcHRpb25hbA0KICAgICAgICAgICAgICBSb3V0ZXIg Q2FwYWJpbGl0aWVzIiwgUkZDIDQ5NzAsIEp1bHkgMjAwNy4NCg0KICAgW1JGQzQ5NzFdICBWYXNz ZXVyLCBKUC4sIFNoZW4sIE4uLCBhbmQgUi4gQWdnYXJ3YWwsICJJbnRlcm1lZGlhdGUNCiAgICAg ICAgICAgICAgU3lzdGVtIHRvIEludGVybWVkaWF0ZSBTeXN0ZW0gKElTLUlTKSBFeHRlbnNpb25z IGZvcg0KICAgICAgICAgICAgICBBZHZlcnRpc2luZyBSb3V0ZXIgSW5mb3JtYXRpb24iLCBSRkMg NDk3MSwgSnVseSAyMDA3Lg0KDQogICBbUkZDNTEyMF0gIFByenlnaWVuZGEsIFQuLCBTaGVuLCBO LiwgYW5kIE4uIFNoZXRoLCAiTS1JU0lTOiBNdWx0aQ0KICAgICAgICAgICAgICBUb3BvbG9neSAo TVQpIFJvdXRpbmcgaW4gSW50ZXJtZWRpYXRlIFN5c3RlbSB0bw0KICAgICAgICAgICAgICBJbnRl cm1lZGlhdGUgU3lzdGVtcyAoSVMtSVNzKSIsIFJGQyA1MTIwLCBGZWJydWFyeSAyMDA4Lg0KDQog ICBbUkZDNTMwNV0gIExpLCBULiBhbmQgSC4gU21pdCwgIklTLUlTIEV4dGVuc2lvbnMgZm9yIFRy YWZmaWMNCiAgICAgICAgICAgICAgRW5naW5lZXJpbmciLCBSRkMgNTMwNSwgT2N0b2JlciAyMDA4 Lg0KDQogICBbUkZDNTMyOV0gIElzaGlndXJvLCBLLiwgTWFucmFsLCBWLiwgRGF2ZXksIEEuLCBh bmQgQS4gTGluZGVtLA0KICAgICAgICAgICAgICAiVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNp b25zIHRvIE9TUEYgVmVyc2lvbiAzIiwNCiAgICAgICAgICAgICAgUkZDIDUzMjksIFNlcHRlbWJl ciAyMDA4Lg0KDQogICBbUkZDNTM0MF0gIENvbHR1biwgUi4sIEZlcmd1c29uLCBELiwgTW95LCBK LiwgYW5kIEEuIExpbmRlbSwgIk9TUEYNCiAgICAgICAgICAgICAgZm9yIElQdjYiLCBSRkMgNTM0 MCwgSnVseSAyMDA4Lg0KDQogICBbUkZDMzI0Nl0gRGF2aWUsIGV0LiBhbC4sID9BbiBFeHBlZGl0 ZWQgRm9yd2FyZGluZyBQSEIgKFBlci1Ib3AgQmVoYXZpb3IpDQogICAgICAgICAgICAgUkZDIDMy NDYsIE1hcmNoIDIwMDINCg0KICAgW1JGQzI2OTddIEouIEhlaW5hbmVuIEouLCBHdWVyaW4sIFIu ICJBIFNpbmdsZSBSYXRlIFRocmVlIENvbG9yIE1hcmtlciwgDQogICAgICAgICAgICAgUkZDIDI2 OTcsIFNlcHRlbWJlciAxOTk5LiANCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMzXQ0KDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMTINCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgU2hhaHJhbSBEYXZh cmkNCiAgIEJyb2FkY29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0K ICAgRW1haWw6IGRhdmFyaUBicm9hZGNvbS5jb20NCg0KDQogICBBbWl0IE9yZW4NCiAgIEJyb2Fk Y29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0KICAgRW1haWw6IGFt aXRvQGJyb2FkY29tLmNvbQ0KDQoNCiAgIE1hbmF2IEJoYXRpYQ0KICAgQWxjYXRlbC1MdWNlbnQN CiAgIEJhbmdhbG9yZSwNCiAgIEluZGlhDQoNCiAgIEVtYWlsOiBtYW5hdi5iaGF0aWFAYWxjYXRl bC1sdWNlbnQuY29tDQoNCg0KICAgUGV0ZXIgUm9iZXJ0cw0KICAgQWxjYXRlbC1MdWNlbnQNCiAg IEthbmF0YSwNCiAgIENhbmFkYQ0KDQogICBFbWFpbDogcGV0ZXIucm9iZXJ0c0BhbGNhdGVsLWx1 Y2VudC5jb20NCg0KDQogICBMYXVyZW50IE1vbnRpbmkNCiAgIENpc2NvIFN5c3RlbXMNCiAgIFNh biBKb3NlIENBDQogICBVU0ENCg0KICAgRW1haWw6IGxtb250aW5pQGNpc2NvLmNvbQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEy LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDQo= --_004_2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308SJEXCHCCR02co_-- From rajiva@cisco.com Tue Mar 13 15:46:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11221E8024 for ; Tue, 13 Mar 2012 15:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dyf+q6uijmG6 for ; Tue, 13 Mar 2012 15:46:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4830A21F85D5 for ; Tue, 13 Mar 2012 15:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=11574; q=dns/txt; s=iport; t=1331678787; x=1332888387; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fJih0FrNJ7jnc9cpx5nUZ6I0wcnqnXD1/22aEAUkfyc=; b=HF4acLt1ECJ1G0nmENtnFXZUl9IfdhOWR5JIr3o6dSWoSouAd0cDxeUG Sk+TXxR6ZI5KhyEBNyfhOq3VlJZJicFzOw/IKxETz6uUiCRggaVC+937B gi7PbuRlLHRQN4BMcS5HFOKYO2AfTwBq2AmFDdmJV7mTjKyyhVI0JLJlz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOXMX0+tJXG8/2dsb2JhbABDtW+BB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEgBh8JCAIEARIIGodoC5xIAZ51iUKGUWMEiFWYJoR4gwOBPg X-IronPort-AV: E=Sophos;i="4.73,579,1325462400"; d="scan'208";a="66155183" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2012 22:46:26 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DMkQ9k027544; Tue, 13 Mar 2012 22:46:26 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 17:46:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 17:46:25 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C079FA9F0@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAABijSAAAV9zQAA6PK9w References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA23F@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Dutta, Pranjal K (Pranjal)" , "Henderickx, Wim (Wim)" , X-OriginalArrivalTime: 13 Mar 2012 22:46:27.0266 (UTC) FILETIME=[1FF17A20:01CD016B] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org, lizhong.jin@zte.com.cn Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:46:31 -0000 Hi Pranjal, rfc6074 solves it well enough. I request you to refer to the following sections: http://tools.ietf.org/html/rfc6074#section-3.3.3 http://tools.ietf.org/html/rfc6074#section-3.2.3 No router-id / LSR id relevance here, suffice to say. A PE router involved in BGP AD (say) would use the IPv4|IPv6 address conveyed by BGP nh for the subsequent LDP signaling. I would be glad to clarify further, if needed. Thanks. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:32 PM > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, > How would you solve the following: >=20 > Protocol that says "here is the BGP next-hop X but its LSR-ID is Y".> >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:28 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > You know transport address only after exchanging hellos. First hellos > need > > to be sent to right remote LSR-ID. >=20 > Hellos should be sent to the correct transport address (unicast or > multicast), not to the chosen LSR-ID. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:45 PM > > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajeev, > > > > Not really. There are applications that auto-instantiate T-LDP > sessions. > > You know transport address only after exchanging hellos. First hellos > need > > to be sent to right remote LSR-ID. We don't run another discovery > protocol > > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you > suggesting > > that all such applications are irrelevant and needs to be wiped > > out from deployments. I haven't heard of any text in RFC 5036 that > says > > "4 byte router-id MUST not be a routable address". > > > > Cheers, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:06 AM > > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, Mustapha, Wim, > > > > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc > has > > to > > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and > T- > > > LDP has to auto-create targeted sessions. We can't force to set-up > > another > > > ip4 network just for some applications. It won't be possible to map > 4 > > byte ldp > > > > I hope that we are not misunderstanding 32-bit integer value in > RouterID > > in an IPv6-only router to mean having IPv4 network. > > Also, such applications must use 'transport IP address', not the > > Router-ID when it comes to setting up the session. If they don't, then > > they are incorrect and must be fixed. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Dutta, Pranjal K (Pranjal) > > [mailto:pranjal.dutta@alcatel-lucent.com] > > > Sent: Friday, March 02, 2012 12:02 PM > > > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > > mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, > > > We shouldn't be ruling out the fact that there are some > > differences in > > > applications of LDP compared to OSPF or BGP. If we have IPV6 only > > transport > > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc > has > > to > > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and > T- > > > LDP has to auto-create targeted sessions. We can't force to set-up > > another > > > ip4 network just for some applications. It won't be possible to map > 4 > > byte ldp > > > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > > is must > > > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > > and better > > > to add it now. > > > > > > Thanks, > > > Pranjal > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Henderickx, Wim (Wim) > > > Sent: Friday, March 02, 2012 12:41 AM > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, > > > > > > I understand we didn't add a IPv6 router ID option in BGP/OSPF but > we > > > should look at the future to get to IPv6 only networks and as such > it > > will be > > > required. So we are now at a point where we should add this option > in > > all > > > protocols. Since LDP for Ipv6 is open we need to add it now. > > > > > > My 2 cents > > > > > > Cheers, > > > Wim > > > > > > -----Original Message----- > > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > > Sent: vrijdag 2 maart 2012 8:08 > > > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Wim, > > > > > > That's a reasonable point, but no such proposal has been made for > > other > > > protocols. In fact, IPv6 deployments have already accommodated > 4-octet > > > router-id for routing protocols (which was also a departure from the > > > common practice in IPv4 realm). As Mark T and I discussed in the > > > previous email, the router-id consistency across protocols would be > an > > > operational benefit. > > > > > > Focusing on the technicalities, Router ID is meant to ensure the > > > uniqueness of the router within the network while following the > > > protocol, so are we thinking that 4-octet is not good enough to > ensure > > > the uniqueness? If so, then it would be worth having that discussion > > in > > > the Routing and Internet areas that have been focusing on IPv6 at > > large. > > > > > > > > > While I do agree to 128-bit future expandability as a benefit, the > > > benefit would be trivial (at the expense of message structure > changes) > > > if we expanded it for the sake of it, but didn't address the root of > > the > > > problem. > > > > > > Do you think otherwise? > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > lucent.com] > > > > Sent: Friday, March 02, 2012 1:42 AM > > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > > lizhong.jin@zte.com.cn > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Rajiv, I believe we need to provide both options to ensure both > are > > > possible. > > > > If we do not introduce the IPv6 LSR ID now I will be very hard to > ad > > > it in the > > > > future. > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Rajiv Asati (rajiva) > > > > Sent: vrijdag 2 maart 2012 7:39 > > > > To: mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > > lizhong.jin@zte.com.cn > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Mark, > > > > > > > > Well said. > > > > > > > > I take that we are in agreement wrt 4-octet entity for LDP > router-id > > > in > > > > the context of IPv6, as specified. > > > > > > > > Cheers, > > > > Rajiv > > > > > > > > > -----Original Message----- > > > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > > > Sent: Friday, March 02, 2012 1:31 AM > > > > > To: Rajiv Asati (rajiva) > > > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > > > lizhong.jin@zte.com.cn; > > > > > vishwas.ietf@gmail.com > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > > > wrote: > > > > > > > > > > > In the past, implementations provided the router-id CLI > > > > > > for any interface IPv4 address to be chosen as router-id > > > > > > for various protocols including LDP. > > > > > > > > > > > However, many implementations already evolved the CLI to > > > > > > not even give an "interface" IP address for router-id, > > > > > > to accommodate IPv6. Almost all deployed networks > > > > > > already accommodated that. > > > > > > > > > > We do operate some implementations today that "still" allow > > > > > you to specify the Router-ID for various protocols as an > > > > > independent 32-bit integer (only), and also allow you to > > > > > define the LSR-ID for LDP as an interface (only). This is > > > > > current, shipping 2012 code. > > > > > > > > > > So both scenarios you mention above are still much in play > > > > > today. Whether operators are using them or not (I know we > > > > > are) is another matter entirely. > > > > > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > > > implementations could evolve LDP router-id as well to > > > > > > accommodate IPv6. This would make LDP router-id to be > > > > > > consistent with other protocols delving with IPv6. And > > > > > > this can certainly be operationally beneficial from IPv6 > > > > > > POV. > > > > > > > > > > Agree. > > > > > > > > > > > In fact, one of the implementations allow the router-id > > > > > > to be configured just once and let all protocols just > > > > > > use it, if they wanted. > > > > > > > > > > Yes, we operate some implementations that use this method > > > > > too. It's quite elegant, in that you configure once and > > > > > forget. Other implementations that are more structured means > > > > > operators could easily forget to specify the Router-ID for a > > > > > particular protocol, for better or worse. > > > > > > > > > > Cheers, > > > > > > > > > > Mark. > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Tue Mar 13 17:13:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A421E8013 for ; Tue, 13 Mar 2012 17:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.41 X-Spam-Level: X-Spam-Status: No, score=-7.41 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3WtY1UNVXTx for ; Tue, 13 Mar 2012 17:13:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5B21F84B6 for ; Tue, 13 Mar 2012 17:13:39 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2E0DEWw003923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Mar 2012 19:13:20 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2E0DCn4015662 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Mar 2012 05:43:12 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 14 Mar 2012 05:43:12 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Rajiv Asati (rajiva)" , "Henderickx, Wim (Wim)" , "mtinka@globaltransit.net" Date: Wed, 14 Mar 2012 05:43:09 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Acz4Phf6G2KHWDP7RueJbnw5+QRC/QAALNAwAAArAKAAAHbooAADqr9gABFRFeABwumLkAAzft+AAABijSAAAV9zQAA6PK9wAAWkEJA= Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD527419C@USNAVSXCHMBSC2.ndc.alcatel-lucent.com><201203021109.05568.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE5CB@XMB-RCD-111.cisco.com><201203021431.19153.mtinka@globaltransit.net><067E6CE33034954AAC05C9EC85E2577C078BE618@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0C4D@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com><067E6CE33034954AAC05C9EC85E2577C078BE626@XMB-RCD-111.cisco.com><14C7F4F06DB5814AB0DE29716C4F6D671DDB0CD7@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA092@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA23F@XMB-RCD-111.cisco.com> <067E6CE33034954AAC05C9EC85E2577C079FA9F0@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA9F0@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" , "lizhong.jin@zte.com.cn" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 00:13:41 -0000 Hi Rajiv, Deriving LSP LSR-ID from PE_Addr part of L2VPN NLRI is one way f= or BGP-AD but that can't be generalized since same doesn't apply for Dynami= c MS-PW NLRI type (AII Type 2). http://tools.ietf.org/html/rfc5003#section-3.2 T-PE1------S-PE2-------S-PE3------T-PE2 The T-PE1 won't have direct T-LDP session to T-PE2 that originated the AII = Type 2 =3D AGI:Global-Id:Prefix:AC-ID, rather would have T-LDP session with= =20 S-PE2 only. So T-PE1 can't derive router-id part of LDP LSR-ID from the=20 Prefix advertised by T-PE2.=20 On the same note, issue would be applicable when dynamic MS-PW is used for = provisioning BGP-AD (with AII Type 1 without aggregation of prefix). In suc= h a case there won't be a direct T-LDP sessions between T-PEs hosting the V= SI for BGP-AD (or the T-PEs that originated the L2VPN NLRI).=20 Cheers, Pranjal=20 =20 -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com]=20 Sent: Tuesday, March 13, 2012 3:46 PM To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); mtinka@globaltransit= .net Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Pranjal, rfc6074 solves it well enough. I request you to refer to the following sections: http://tools.ietf.org/html/rfc6074#section-3.3.3 http://tools.ietf.org/html/rfc6074#section-3.2.3 No router-id / LSR id relevance here, suffice to say. A PE router involved in BGP AD (say) would use the IPv4|IPv6 address conveyed by BGP nh for the subsequent LDP signaling. I would be glad to clarify further, if needed. Thanks. Cheers, Rajiv > -----Original Message----- > From: Dutta, Pranjal K (Pranjal) [mailto:pranjal.dutta@alcatel-lucent.com] > Sent: Monday, March 12, 2012 1:32 PM > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Rajiv, > How would you solve the following: >=20 > Protocol that says "here is the BGP next-hop X but its LSR-ID is Y".> >=20 > Cheers, > Pranjal >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 10:28 AM > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > mtinka@globaltransit.net > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; lizhong.jin@zte.com.cn > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Pranjal, >=20 > > You know transport address only after exchanging hellos. First hellos > need > > to be sent to right remote LSR-ID. >=20 > Hellos should be sent to the correct transport address (unicast or > multicast), not to the chosen LSR-ID. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Dutta, Pranjal K (Pranjal) > [mailto:pranjal.dutta@alcatel-lucent.com] > > Sent: Monday, March 12, 2012 12:45 PM > > To: Rajiv Asati (rajiva); Henderickx, Wim (Wim); > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajeev, > > > > Not really. There are applications that auto-instantiate T-LDP > sessions. > > You know transport address only after exchanging hellos. First hellos > need > > to be sent to right remote LSR-ID. We don't run another discovery > protocol > > that says "here is the BGP next-hop X but its LSR-ID is Y". Are you > suggesting > > that all such applications are irrelevant and needs to be wiped > > out from deployments. I haven't heard of any text in RFC 5036 that > says > > "4 byte router-id MUST not be a routable address". > > > > Cheers, > > Pranjal > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Rajiv Asati (rajiva) > > Sent: Monday, March 12, 2012 7:06 AM > > To: Dutta, Pranjal K (Pranjal); Henderickx, Wim (Wim); > > mtinka@globaltransit.net > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > lizhong.jin@zte.com.cn > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Pranjal, Mustapha, Wim, > > > > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc > has > > to > > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and > T- > > > LDP has to auto-create targeted sessions. We can't force to set-up > > another > > > ip4 network just for some applications. It won't be possible to map > 4 > > byte ldp > > > > I hope that we are not misunderstanding 32-bit integer value in > RouterID > > in an IPv6-only router to mean having IPv4 network. > > Also, such applications must use 'transport IP address', not the > > Router-ID when it comes to setting up the session. If they don't, then > > they are incorrect and must be fixed. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Dutta, Pranjal K (Pranjal) > > [mailto:pranjal.dutta@alcatel-lucent.com] > > > Sent: Friday, March 02, 2012 12:02 PM > > > To: Henderickx, Wim (Wim); Rajiv Asati (rajiva); > > mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, > > > We shouldn't be ruling out the fact that there are some > > differences in > > > applications of LDP compared to OSPF or BGP. If we have IPV6 only > > transport > > > network tomorrow then applications like BGP-AD, Dynamic MS-PW etc > has > > to > > > advertise L2VPN NLRI/MS-PW NLRI etc using an IPV6 BGP next-hop and > T- > > > LDP has to auto-create targeted sessions. We can't force to set-up > > another > > > ip4 network just for some applications. It won't be possible to map > 4 > > byte ldp > > > LSR-ID to the BGP IPV6 next-hop. I am not saying that 16 byte LSR-ID > > is must > > > for LDP IPV6. It's OPTIONAL and adds lot of operational flexibility > > and better > > > to add it now. > > > > > > Thanks, > > > Pranjal > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Henderickx, Wim (Wim) > > > Sent: Friday, March 02, 2012 12:41 AM > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Rajiv, > > > > > > I understand we didn't add a IPv6 router ID option in BGP/OSPF but > we > > > should look at the future to get to IPv6 only networks and as such > it > > will be > > > required. So we are now at a point where we should add this option > in > > all > > > protocols. Since LDP for Ipv6 is open we need to add it now. > > > > > > My 2 cents > > > > > > Cheers, > > > Wim > > > > > > -----Original Message----- > > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > > Sent: vrijdag 2 maart 2012 8:08 > > > To: Henderickx, Wim (Wim); mtinka@globaltransit.net > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > lizhong.jin@zte.com.cn > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Wim, > > > > > > That's a reasonable point, but no such proposal has been made for > > other > > > protocols. In fact, IPv6 deployments have already accommodated > 4-octet > > > router-id for routing protocols (which was also a departure from the > > > common practice in IPv4 realm). As Mark T and I discussed in the > > > previous email, the router-id consistency across protocols would be > an > > > operational benefit. > > > > > > Focusing on the technicalities, Router ID is meant to ensure the > > > uniqueness of the router within the network while following the > > > protocol, so are we thinking that 4-octet is not good enough to > ensure > > > the uniqueness? If so, then it would be worth having that discussion > > in > > > the Routing and Internet areas that have been focusing on IPv6 at > > large. > > > > > > > > > While I do agree to 128-bit future expandability as a benefit, the > > > benefit would be trivial (at the expense of message structure > changes) > > > if we expanded it for the sake of it, but didn't address the root of > > the > > > problem. > > > > > > Do you think otherwise? > > > > > > Cheers, > > > Rajiv > > > > > > > -----Original Message----- > > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > lucent.com] > > > > Sent: Friday, March 02, 2012 1:42 AM > > > > To: Rajiv Asati (rajiva); mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > > lizhong.jin@zte.com.cn > > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Rajiv, I believe we need to provide both options to ensure both > are > > > possible. > > > > If we do not introduce the IPv6 LSR ID now I will be very hard to > ad > > > it in the > > > > future. > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Rajiv Asati (rajiva) > > > > Sent: vrijdag 2 maart 2012 7:39 > > > > To: mtinka@globaltransit.net > > > > Cc: Aissaoui, Mustapha (Mustapha); mpls@ietf.org; > > > lizhong.jin@zte.com.cn > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Mark, > > > > > > > > Well said. > > > > > > > > I take that we are in agreement wrt 4-octet entity for LDP > router-id > > > in > > > > the context of IPv6, as specified. > > > > > > > > Cheers, > > > > Rajiv > > > > > > > > > -----Original Message----- > > > > > From: Mark Tinka [mailto:mtinka@globaltransit.net] > > > > > Sent: Friday, March 02, 2012 1:31 AM > > > > > To: Rajiv Asati (rajiva) > > > > > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha); > > > > lizhong.jin@zte.com.cn; > > > > > vishwas.ietf@gmail.com > > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > > > On Friday, March 02, 2012 11:35:26 AM Rajiv Asati (rajiva) > > > > > wrote: > > > > > > > > > > > In the past, implementations provided the router-id CLI > > > > > > for any interface IPv4 address to be chosen as router-id > > > > > > for various protocols including LDP. > > > > > > > > > > > However, many implementations already evolved the CLI to > > > > > > not even give an "interface" IP address for router-id, > > > > > > to accommodate IPv6. Almost all deployed networks > > > > > > already accommodated that. > > > > > > > > > > We do operate some implementations today that "still" allow > > > > > you to specify the Router-ID for various protocols as an > > > > > independent 32-bit integer (only), and also allow you to > > > > > define the LSR-ID for LDP as an interface (only). This is > > > > > current, shipping 2012 code. > > > > > > > > > > So both scenarios you mention above are still much in play > > > > > today. Whether operators are using them or not (I know we > > > > > are) is another matter entirely. > > > > > > > > > > > Now that LDP is being enhanced to use IPv6, > > > > > > implementations could evolve LDP router-id as well to > > > > > > accommodate IPv6. This would make LDP router-id to be > > > > > > consistent with other protocols delving with IPv6. And > > > > > > this can certainly be operationally beneficial from IPv6 > > > > > > POV. > > > > > > > > > > Agree. > > > > > > > > > > > In fact, one of the implementations allow the router-id > > > > > > to be configured just once and let all protocols just > > > > > > use it, if they wanted. > > > > > > > > > > Yes, we operate some implementations that use this method > > > > > too. It's quite elegant, in that you configure once and > > > > > forget. Other implementations that are more structured means > > > > > operators could easily forget to specify the Router-ID for a > > > > > particular protocol, for better or worse. > > > > > > > > > > Cheers, > > > > > > > > > > Mark. > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Wed Mar 14 18:01:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A6021F8780 for ; Wed, 14 Mar 2012 18:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLDh8imSPJt8 for ; Wed, 14 Mar 2012 18:01:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 342AC11E8080 for ; Wed, 14 Mar 2012 18:01:39 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2F11Slj000961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Mar 2012 20:01:31 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 14 Mar 2012 21:01:27 -0400 From: Gregory Mirsky To: "cts@etri.re.kr" , "ryoo@etri.re.kr" , "wyaacov@gmail.com" , "nurit.sprecher@nsn.com" , "daniel@olddog.co.uk" , "mpls@ietf.org" Date: Wed, 14 Mar 2012 21:01:26 -0400 Thread-Topic: Note on draft-cheung-mpls-tp-mesh-protection-05 Thread-Index: Ac0CRyYi8Txz2ou8QoqjmCLFUmXvZg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13550254409EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Note on draft-cheung-mpls-tp-mesh-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 01:01:42 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13550254409EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., I have a single note to the draft-cheung-mpls-tp-mesh-protection-05: * Section 2.2 "The shared protection resource may be a node, ..." I t= hink that a node by itself can not be viewed as shared resource. Only if BW= of a link, physical or logical, is being shared, only then terminating nod= es can be viewed as shared resource. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13550254409EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
I have a single note to the draft-cheung-mpls-tp-mesh-protection-05:
  • Section 2.2 "The shared protection resource may be a node, …= " I think that a node by itself can not be viewed as shared resource. = Only if BW of a link, physical or logical, is being shared, only then termi= nating nodes can be viewed as shared resource.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF13550254409EUSAACMS0715e_-- From gregimirsky@gmail.com Wed Mar 14 19:07:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047BB21F86D1; Wed, 14 Mar 2012 19:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMzLtOPGfIYn; Wed, 14 Mar 2012 19:07:46 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B12A421F86D0; Wed, 14 Mar 2012 19:07:45 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2892532ggm.31 for ; Wed, 14 Mar 2012 19:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J+MyZBV34GDYczu5F0l9tQ2V9dyZAJnroW3jyNgQ9FU=; b=UC9UFDMKOnqdy1qEQ8zpy5khTJq8NHYtrrCpjrW2Tn9ejok4ATF33pZNdBGZwrVohr MYmgM+hNafj6rb+HiWqmjHhgBCFdxgD/xORv14NQCJK+aDW3gczvxhuIavcUgHe4VS4j mpVWvYsnaoNShLChojYAo5DD09TJIpiMoD0zLungRaaplx6TxioxE+eQ3zZj8k5g58tD bd9wnFpy5CnWhUl3ltllM5yVMuBnP24H4x0ohskE2vmgAtMeWmeBR+6PuJPNW/T+iQpc zt3F0+1NQis3ullC8ZtAxfzIVdjcbQ2ukGE1HnvFiMfuLYQy8CzLddQYKO0b07+9m3jC jcmg== MIME-Version: 1.0 Received: by 10.60.4.162 with SMTP id l2mr6438142oel.3.1331777265088; Wed, 14 Mar 2012 19:07:45 -0700 (PDT) Received: by 10.182.114.98 with HTTP; Wed, 14 Mar 2012 19:07:44 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 14 Mar 2012 19:07:44 -0700 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=e89a8ff1c5aece36f804bb3e8e44 Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:07:47 -0000 --e89a8ff1c5aece36f804bb3e8e44 Content-Type: text/plain; charset=ISO-8859-1 Dear Shahram, perhaps because of "This document provides extensions to OSPF, ISIS ..." review by OSPF and ISIS WGs should be solicited as well. Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari wrote: > Hi,**** > > ** ** > > Please find attached the latest 1588 over MPLS draft (03). Since cut-off > date was yesterday, we will upload this after the Paris meeting.**** > > Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some > aspects from each of these groups are used in this draft. **** > > ** ** > > We will present this draft in the relevant WGs in Paris.**** > > ** ** > > Regards,**** > > Shahram Davari**** > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --e89a8ff1c5aece36f804bb3e8e44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shahram,
perhaps because of "This document provides extensions= to OSPF, ISIS ..." review by OSPF and ISIS WGs should be solicited as= well.

Regards,
Greg

On Mon, Ma= r 12, 2012 at 5:16 PM, Shahram Davari <davari@broadcom.com> wrote:

Hi,

=A0

Please find attached the latest 1588 over MPLS draft= (03). Since cut-off date was yesterday, we will upload this after the Pari= s meeting.

Review is required from = TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these gro= ups are used in this draft.

=A0

We will = present this draft in the relevant WGs in Paris.

=A0

Regards,<= u>

Shahram Davari


____= ___________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--e89a8ff1c5aece36f804bb3e8e44-- From loa@pi.nu Thu Mar 15 03:32:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6359921F86C5 for ; Thu, 15 Mar 2012 03:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2K24EPLjGAZ for ; Thu, 15 Mar 2012 03:32:52 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id B875921F86B8 for ; Thu, 15 Mar 2012 03:32:52 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8FBF62A8002; Thu, 15 Mar 2012 11:32:50 +0100 (CET) Message-ID: <4F61C551.8070009@pi.nu> Date: Thu, 15 Mar 2012 11:32:49 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "rtg-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] draft-ietf-mpls-ldp-gtsm-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:32:53 -0000 Working Group, this is to start a working group last call on draft-ietf-mpls-ldp-gtsm-04. Normally we do two week wg last calls, but since this is across the IETF meeting in Paris we make it a week longer. The working group last call ends eob Friday April 6 2012. Please send comments to the mpls working group mailing list (mpls@ietf.org). /Loa for the MPLS WG co-chairs PS There are nit warnings depending on that draft were published last year and that one of the references has been updated, no need to report that. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Thu Mar 15 05:20:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFE21F86AB for ; Thu, 15 Mar 2012 05:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap5hrLeC9O33 for ; Thu, 15 Mar 2012 05:20:35 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A3DED21F86A8 for ; Thu, 15 Mar 2012 05:20:31 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8CC5E2A8002; Thu, 15 Mar 2012 13:20:29 +0100 (CET) Message-ID: <4F61DE8C.3000802@pi.nu> Date: Thu, 15 Mar 2012 13:20:28 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "rtg-ads@tools.ietf.org" References: <4F61C551.8070009@pi.nu> In-Reply-To: <4F61C551.8070009@pi.nu> X-Forwarded-Message-Id: <4F61C551.8070009@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:20:37 -0000 Working Group, (slight change of the subject, please use this one to send lc comments). This is to start a working group last call on draft-ietf-mpls-ldp-gtsm-04. Normally we do two week wg last calls, but since this is across the IETF meeting in Paris we make it a week longer. The working group last call ends eob Friday April 6 2012. Please send comments to the mpls working group mailing list (mpls@ietf.org). /Loa for the MPLS WG co-chairs PS There are nit warnings depending on that draft were published last year and that one of the references has been updated, no need to report that. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wyaacov@gmail.com Thu Mar 15 06:34:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8379D21F858A for ; Thu, 15 Mar 2012 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5JoRlz+Rkx3 for ; Thu, 15 Mar 2012 06:34:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5101B21F8585 for ; Thu, 15 Mar 2012 06:34:52 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1649595eaa.31 for ; Thu, 15 Mar 2012 06:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wRbXmC848KdVlTL4ZggoGm+ZLIv5tpcLSV+H4robMyQ=; b=ZvrZiSiAsas+uo9Zt6mbdVzXLLaEEVphEVaLOa/8uleQQgqJJNaN48JDadeA6V/2aT pTpZSYaYhYJEPFE7eCZp97kfaAts0m6aQyShAr3lnjLSzkWgD8jbiJRlOe3zQ9+ch3W3 9nMZgGVSFD7HRHKedKv4FGAA2LeM9efQ+UONX0oNEfq+f41PikIMGDcN1Z5UUWr5dQqr VT9iwL3olz98agj5qrdLVwKDQGrRuwF9ygqwQc78aVq/ad7bs7C34VkQTjCe5DVB97y/ usz1KTy+nBCna6MP+wftj0arDb6utZ+okB7XPFar5zcWrgPCj12FyqGfqRhwQPoxYIRV xuLg== MIME-Version: 1.0 Received: by 10.224.31.18 with SMTP id w18mr7650313qac.44.1331818490784; Thu, 15 Mar 2012 06:34:50 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 15 Mar 2012 06:34:50 -0700 (PDT) Date: Thu, 15 Mar 2012 15:34:50 +0200 Message-ID: From: Yaacov Weingarten To: mpls@ietf.org, draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org Content-Type: multipart/alternative; boundary=20cf3074b4620c6c9404bb4828b9 Subject: [mpls] Comments/Questions about "p2mp shared protection" draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:37:48 -0000 --20cf3074b4620c6c9404bb4828b9 Content-Type: text/plain; charset=ISO-8859-1 Hi, authors I have read your draft and find that I have quite a few questions and comments about the proposals in the draft and the presentation: 1. You present two different scenarios for protection of p2mp MPLS-TP traffic, but you do not really define what the architecture of your protection domain is. Taking the first solution, where you propose using a 1:n protection scheme - normally, and as presented in the Survivability Framework a 1:n protection domain consists of several working paths and a single protection path that all have the same set of root and leaves. Yet in your figure 3 you show a 1:2 domain that the working paths have different roots and different sets of leafs! It would be helpful, IMO, if you could define what protection domain you are referencing. 2. In the scenario that you present in figure 3, your protection path starts at a different root than either working path (for which I commented above) but what worries me more is that its destination leafs seem to be the union of the leafs of all of the working paths. Doesn't this raise some security and congestion problems? For example, let's take the simple case of a single failure on one of the working paths - by switching over to the protection path the traffic from this service will be delivered to some destinations that it was not intended to receive the packets? In addition, the sections to this destination are suddenly carrying packets that are unnecessary and just causing additional traffic on the links! 3. Both of your solutions are greatly dependent upon the RDI functionality, and you state that the root will be able to identify the relevant working transport path based on this information. However, the RDI for MPLS-TP is defined as part of the Extension to BFD and only within the CC messages (it is ignored in the CV message) that do not include a LSP/PW identifier TLV. And considering that p2mp paths in MPLS-TP are unidirectional, I think that you need to clearly explain how the root receives the RDI and how it correlates this RDI to a particular LSP. 4. In your solution that is based on (1:1)^n protection - you state that the root must "compare the priority among these protection paths..." - but I thought that in this protection scheme the protection switch is performed within a single 1:1 domain, so there is nothing for the root to compare to! What I believe that you meant is that each shared segment may need (in the case of multiple faults) to compare the priorities of the different requests for the shared resources! 5. Can you explain the relationship between your proposals and the drafts that are available for 1:n protection and shared mesh protection (in particular draft-cheung that is also based on (1:1)^n protection)? Can you use the same extensions that are proposed in those drafts? Thank you, Yaacov Weingarten --20cf3074b4620c6c9404bb4828b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, authors=A0

I have read your draft a= nd find that I have quite a few questions and comments about the proposals = in the draft and the presentation:

1. =A0You prese= nt two different scenarios for protection of p2mp MPLS-TP traffic, but you = do not really define what the architecture of your protection domain is.
Taking the first solution, where you propose using a 1:n protection sc= heme - normally, and as presented in the Survivability Framework a 1:n prot= ection domain consists of several working paths and a single protection pat= h that all have the same set of root and leaves. =A0Yet in your figure 3 yo= u show a 1:2 domain that the working paths have different roots and differe= nt sets of leafs! =A0It would be helpful, IMO, if you could define what pro= tection domain you are referencing.

2. In the scenario that you present in figure 3, your p= rotection path starts at a different root than either working path (for whi= ch I commented above) but what worries me more is that its destination leaf= s seem to be the union of the leafs of all of the working paths. =A0Doesn&#= 39;t this raise some security and congestion problems? =A0For example, let&= #39;s take the simple case of a single failure on one of the working paths = - by switching over to the protection path the traffic from this service wi= ll be delivered to some destinations that it was not intended to receive th= e packets? =A0In addition, the sections to this destination are suddenly ca= rrying packets that are unnecessary and just causing additional traffic on = the links!

3. Both of your solutions are greatly dependent upon th= e RDI functionality, and you state that the root will be able to identify t= he relevant working transport path based on this information. =A0However, t= he RDI for MPLS-TP is defined as part of the Extension to BFD and only with= in the CC messages (it is ignored in the CV message) that do not include a = LSP/PW identifier TLV. =A0And considering that p2mp paths in MPLS-TP are un= idirectional, I think that you need to clearly explain how the root receive= s the RDI and how it correlates this RDI to a particular LSP.

4. In your solution that is based on (1:1)^n protection= - you state that the root must "compare the priority among these prot= ection paths..." - but I thought that in this protection scheme the pr= otection switch is performed within a single 1:1 domain, so there is nothin= g for the root to compare to! =A0What I believe that you meant is that each= shared segment may need (in the case of multiple faults) to compare the pr= iorities of the different requests for the shared resources!

5. =A0Can you explain the relationship between your pro= posals and the drafts that are available for 1:n protection and shared mesh= protection (in particular draft-cheung that is also based on (1:1)^n prote= ction)? =A0Can you use the same extensions that are proposed in those draft= s?

Thank you,
Yaacov Weingarten
--20cf3074b4620c6c9404bb4828b9-- From wyaacov@gmail.com Thu Mar 15 06:43:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6205121F869A for ; Thu, 15 Mar 2012 06:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1advQSyEl-z for ; Thu, 15 Mar 2012 06:43:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7001321F8698 for ; Thu, 15 Mar 2012 06:43:27 -0700 (PDT) Received: by yhkk25 with SMTP id k25so450228yhk.31 for ; Thu, 15 Mar 2012 06:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GJDiR6n93+XYqKyEjLWFfR5uQ3bpSFCwfs/m3+2228s=; b=yZEGmQPjH7AKIMNdvzO6uId5KQ0AN03hQIdIiXBHert5qz77hVIRZIcWHxmgUE0bLQ vX0DqHM1Swex5AF4ZRXyQCeGUW/+Rr6HLD6Yf2b2+/6PcGtjr0oZVsbIc1p6zAhcDuw7 qPVtRgYb/ib/s0IEB1L1xGlOBUsV7oRwz6Grql7c5UAbQT8KzNSXrDOlZP5tKfKIBLsg gyPqkM8pYyCfVEX+/09utBTW2moEOYsEvdiKHS1gAJAvXdIOFIZR6WNzp1PBKyG5I/sd XmGN1fSUq+1hs6B8Qlik6AvCmcSEzL15GEslCCxTImsEEwWnd5sETphqFHvbDnNowoo4 tsdg== MIME-Version: 1.0 Received: by 10.224.30.206 with SMTP id v14mr1792677qac.18.1331819006975; Thu, 15 Mar 2012 06:43:26 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 15 Mar 2012 06:43:26 -0700 (PDT) Date: Thu, 15 Mar 2012 15:43:26 +0200 Message-ID: From: Yaacov Weingarten To: draft-liu-mpls-tp-p2mp-shared-protection@tools.ietf.org, mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d6a6d0dcdb04bb4846ad Subject: [mpls] Comments/Questions on the p2mp shared protection draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:43:28 -0000 --20cf3074d6a6d0dcdb04bb4846ad Content-Type: text/plain; charset=ISO-8859-1 Hi, authors I have read your draft and find that I have quite a few questions and comments about the proposals in the draft and the presentation: 1. You present two different scenarios for protection of p2mp MPLS-TP traffic, but you do not really define what the architecture of your protection domain is. Taking the first solution, where you propose using a 1:n protection scheme - normally, and as presented in the Survivability Framework a 1:n protection domain consists of several working paths and a single protection path that all have the same set of root and leaves. Yet in your figure 3 you show a 1:2 domain that the working paths have different roots and different sets of leafs! It would be helpful, IMO, if you could define what protection domain you are referencing. 2. In the scenario that you present in figure 3, your protection path starts at a different root than either working path (for which I commented above) but what worries me more is that its destination leafs seem to be the union of the leafs of all of the working paths. Doesn't this raise some security and congestion problems? For example, let's take the simple case of a single failure on one of the working paths - by switching over to the protection path the traffic from this service will be delivered to some destinations that it was not intended to receive the packets? In addition, the sections to this destination are suddenly carrying packets that are unnecessary and just causing additional traffic on the links! 3. Both of your solutions are greatly dependent upon the RDI functionality, and you state that the root will be able to identify the relevant working transport path based on this information. However, the RDI for MPLS-TP is defined as part of the Extension to BFD and only within the CC messages (it is ignored in the CV message) that do not include a LSP/PW identifier TLV. And considering that p2mp paths in MPLS-TP are unidirectional, I think that you need to clearly explain how the root receives the RDI and how it correlates this RDI to a particular LSP. 4. In your solution that is based on (1:1)^n protection - you state that the root must "compare the priority among these protection paths..." - but I thought that in this protection scheme the protection switch is performed within a single 1:1 domain, so there is nothing for the root to compare to! What I believe that you meant is that each shared segment may need (in the case of multiple faults) to compare the priorities of the different requests for the shared resources! 5. Can you explain the relationship between your proposals and the drafts that are available for 1:n protection and shared mesh protection (in particular draft-cheung that is also based on (1:1)^n protection)? Can you use the same extensions that are proposed in those drafts? Thank you, Yaacov Weingarten --20cf3074d6a6d0dcdb04bb4846ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, authors=A0

I have read= your draft and find that I have quite a few questions and comments about t= he proposals in the draft and the presentation:

1. =A0You present two different scenarios for protection of = p2mp MPLS-TP traffic, but you do not really define what the architecture of= your protection domain is.
Taking the first solution, where you = propose using a 1:n protection scheme - normally, and as presented in the S= urvivability Framework a 1:n protection domain consists of several working = paths and a single protection path that all have the same set of root and l= eaves. =A0Yet in your figure 3 you show a 1:2 domain that the working paths= have different roots and different sets of leafs! =A0It would be helpful, = IMO, if you could define what protection domain you are referencing.

2. In the scenario that you present in figure 3, your p= rotection path starts at a different root than either working path (for whi= ch I commented above) but what worries me more is that its destination leaf= s seem to be the union of the leafs of all of the working paths. =A0Doesn&#= 39;t this raise some security and congestion problems? =A0For example, let&= #39;s take the simple case of a single failure on one of the working paths = - by switching over to the protection path the traffic from this service wi= ll be delivered to some destinations that it was not intended to receive th= e packets? =A0In addition, the sections to this destination are suddenly ca= rrying packets that are unnecessary and just causing additional traffic on = the links!

3. Both of your solutions are greatly dependent upon th= e RDI functionality, and you state that the root will be able to identify t= he relevant working transport path based on this information. =A0However, t= he RDI for MPLS-TP is defined as part of the Extension to BFD and only with= in the CC messages (it is ignored in the CV message) that do not include a = LSP/PW identifier TLV. =A0And considering that p2mp paths in MPLS-TP are un= idirectional, I think that you need to clearly explain how the root receive= s the RDI and how it correlates this RDI to a particular LSP.

4. In your solution that is based on (1:1)^n protection= - you state that the root must "compare the priority among these prot= ection paths..." - but I thought that in this protection scheme the pr= otection switch is performed within a single 1:1 domain, so there is nothin= g for the root to compare to! =A0What I believe that you meant is that each= shared segment may need (in the case of multiple faults) to compare the pr= iorities of the different requests for the shared resources!

5. =A0Can you explain the relationship between your pro= posals and the drafts that are available for 1:n protection and shared mesh= protection (in particular draft-cheung that is also based on (1:1)^n prote= ction)? =A0Can you use the same extensions that are proposed in those draft= s?

Thank you,
Yaacov Weingarten
--20cf3074d6a6d0dcdb04bb4846ad-- From wwwrun@rfc-editor.org Thu Mar 15 07:53:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6094F21F86EC for ; Thu, 15 Mar 2012 07:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJY0PX1Zvdku for ; Thu, 15 Mar 2012 07:53:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8486E21F8718 for ; Thu, 15 Mar 2012 07:53:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BBF20B1E002; Thu, 15 Mar 2012 07:52:47 -0700 (PDT) To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20120315145247.BBF20B1E002@rfc-editor.org> Date: Thu, 15 Mar 2012 07:52:47 -0700 (PDT) Cc: mpls@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC5036 (3156) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:53:27 -0000 The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=3156 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.5.8 Original Text ------------- Path Vector Specifies the LSRs along the LSR being set up by the Label Request message. Section "Path Vector Procedures" describes how to handle this TLV. Corrected Text -------------- Path Vector Specifies the LSRs along the LSP being set up by the Label Request message. Section "Path Vector Procedures" describes how to handle this TLV. Notes ----- Erroneously typed LSR instead of the LSP. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From davari@broadcom.com Thu Mar 15 11:45:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6621F8692; Thu, 15 Mar 2012 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU+ul-bKnHzU; Thu, 15 Mar 2012 11:45:06 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5821F8622; Thu, 15 Mar 2012 11:45:06 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 15 Mar 2012 11:54:43 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 15 Mar 2012 11:44:55 -0700 From: "Shahram Davari" To: "Greg Mirsky" Date: Thu, 15 Mar 2012 11:44:52 -0700 Thread-Topic: [PWE3] Updated 1588 over MPLS draf-03 Thread-Index: Ac0CUHHbsZe5OTtyTdCk7/roMMK5gQAizr7w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EE@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 637CE5794GW5121498-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:45:07 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes, agree. Thx Shahram From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, March 14, 2012 7:08 PM To: Shahram Davari Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 Dear Shahram, perhaps because of "This document provides extensions to OSPF, ISIS ..." re= view by OSPF and ISIS WGs should be solicited as well. Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari > wrote: Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Yes, agre= e.

 

Thx

Shahram

&n= bsp;

From: Greg Mirsky [mailt= o:gregimirsky@gmail.com]
Sent: Wednesday, March 14, 2012 7:08 PM=
To: Shahram Davari
Cc: tictoc@ietf.org; mpls@ietf.org;= pwe3@ietf.org; CCAMP
Subject: Re: [PWE3] Updated 1588 over MPLS = draf-03

 

Dear Shahram,
perh= aps because of "This document provides extensions to OSPF, ISIS ...&qu= ot; review by OSPF and ISIS WGs should be solicited as well.

Regards= ,
Greg

On Mon, Mar 12, 2012 at 5= :16 PM, Shahram Davari <davari@br= oadcom.com> wrote:

Hi,

=

 

Please find attached the latest 1588 ove= r MPLS draft (03). Since cut-off date was yesterday, we will upload this af= ter the Paris meeting.

Review is required from TICTOC,= MPLS, PWE3 and CCAMP WGs, since some aspects from each of these groups are= used in this draft.

 

We w= ill present this draft in the relevant WGs in Paris.

&= nbsp;

Regards,

Shahram Davari

=
_______________________________________________
pwe3 mailing listpwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

&nbs= p;

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDEEBE6EESJEXCHCCR02co_-- From ryoo@etri.re.kr Thu Mar 15 19:31:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0190221E8011 for ; Thu, 15 Mar 2012 19:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.853 X-Spam-Level: X-Spam-Status: No, score=-98.853 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d74OHD9GExVs for ; Thu, 15 Mar 2012 19:31:33 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2287F21E800F for ; Thu, 15 Mar 2012 19:31:32 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 16 Mar 2012 11:31:30 +0900 Priority: normal X-ReadCheckName: mpls%40ietf.org Thread-Topic: Note on draft-cheung-mpls-tp-mesh-protection-05 Content-Transfer-Encoding: 7bit X-ReadCheckMessageID: thread-index: Ac0DHOUEXrBQxblcQr2AGZbzF3bUwQ== From: "Ryoo, Jeong-dong" To: "Gregory Mirsky" , , , , , Date: Fri, 16 Mar 2012 11:31:30 +0900 Comment: ??, ???, Message-ID: <30B1E58F6DAB464CA57DBBD13E9DEC08@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4B5F_01CD0368.54EE2DF0" X-Mailer: Microsoft CDO for Exchange 2000 Content-class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 16 Mar 2012 02:31:30.0233 (UTC) FILETIME=[E52A3A90:01CD031C] Subject: Re: [mpls] Note on draft-cheung-mpls-tp-mesh-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Ryoo, Jeong-dong" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 02:31:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_4B5F_01CD0368.54EE2DF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_4B5F_01CD0368.54EE2DF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPkdyZWcsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5Zb3UgYXJlIHJp Z2h0LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SW5kZWVkLCZuYnNwO3RoZXJlIGV4 aXN0cyBhIGNhc2UgdGhhdCBqdXN0IGEgbm9kZSBjYW5ub3QgYmUgdmlld2VkIGFzIGJlaW5nIHNo YXJlZC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoYW5rcyBmb3IgdGhlIHNvZmlz dGljYXRlZCBjb25zaWRlcmF0aW9uLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SmVv bmctZG9uZyBhbmQgVGFlc2lrPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48QlI+Jm5i c3A7PC9ESVY+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlMWTogOyBXT1JELUJSRUFLOiBicmVhay1h bGwiPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiAiPg0KPERJVj4NCjxESVYgc3R5 bGU9IkZPTlQtRkFNSUxZOiAiPg0KPERJVj4NCjxESVYgc3R5bGU9IkZPTlQtRkFNSUxZOiAiPjxC Uj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gIkdyZWdvcnkgTWly c2t5IiAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tJmd0OzxCUj48Qj5Gcm9tIERhdGU6 PC9CPiAyMDEyLTAzLTE1IEFNIDEwOjAxOjI2PEJSPjxCPlRvOjwvQj4gImN0c0BldHJpLnJlLmty IiAmbHQ7Y3RzQGV0cmkucmUua3ImZ3Q7LCAicnlvb0BldHJpLnJlLmtyIiAmbHQ7cnlvb0BldHJp LnJlLmtyJmd0OywgInd5YWFjb3ZAZ21haWwuY29tIiAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7 LCAibnVyaXQuc3ByZWNoZXJAbnNuLmNvbSIgJmx0O251cml0LnNwcmVjaGVyQG5zbi5jb20mZ3Q7 LCAiZGFuaWVsQG9sZGRvZy5jby51ayIgJmx0O2RhbmllbEBvbGRkb2cuY28udWsmZ3Q7LCAibXBs c0BpZXRmLm9yZyIgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PEJSPjxCPkNjOjwvQj4gPEJSPjxCPlN1 YmplY3Q6PC9CPiBOb3RlIG9uIGRyYWZ0LWNoZXVuZy1tcGxzLXRwLW1lc2gtcHJvdGVjdGlvbi0w NTxCUj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PC9ESVY+PCEtLSBj b252ZXJ0ZWQgZnJvbSBydGYgLS0+PCEtLSBzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2lu LWxlZnQ6IDFwdDsgcGFkZGluZy1sZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBz b2xpZDsgfSAtLT48L1NUWUxFIC0tPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT0iQXJpYWwsIHNh bnMtc2VyaWYiPg0KPERJVj5EZWFyIEF1dGhvcnMsIGV0IGFsLiw8L0RJVj4NCjxESVY+SSBoYXZl IGEgc2luZ2xlIG5vdGUgdG8gdGhlIGRyYWZ0LWNoZXVuZy1tcGxzLXRwLW1lc2gtcHJvdGVjdGlv bi0wNTo8L0RJVj4NCjxVTCBzdHlsZT0iTUFSR0lOLVRPUDogMHB0OyBNQVJHSU4tQk9UVE9NOiAw cHQ7IE1BUkdJTi1MRUZUOiAxOXB0Ij4NCjxMST5TZWN0aW9uIDIuMiAiVGhlIHNoYXJlZCBwcm90 ZWN0aW9uIHJlc291cmNlIG1heSBiZSBhIG5vZGUsIOKApiIgSSB0aGluayB0aGF0IGEgbm9kZSBi eSBpdHNlbGYgY2FuIG5vdCBiZSB2aWV3ZWQgYXMgc2hhcmVkIHJlc291cmNlLiBPbmx5IGlmIEJX IG9mIGEgbGluaywgcGh5c2ljYWwgb3IgbG9naWNhbCwgaXMgYmVpbmcgc2hhcmVkLCBvbmx5IHRo ZW4gdGVybWluYXRpbmcgbm9kZXMgY2FuIGJlIHZpZXdlZCBhcyBzaGFyZWQgcmVzb3VyY2UuPC9M ST48L1VMPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRk9OVD48L0RJ Vj48L0RJVj48aW1nIHN0eWxlPSJkaXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJo dHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1tcGxz QGlldGYub3JnJm5hbWU9bXBscyU0MGlldGYub3JnJmZyb21lbWFpbD1yeW9vQGV0cmkucmUua3Im bWVzc2FnZWlkPSUzQ2Q5NDBkZTM5LTBmZWItNGNhMi04MThkLTNhZDAwMmE1M2JhM0BldHJpLnJl LmtyJTNFIj4= ------=_NextPart_000_4B5F_01CD0368.54EE2DF0-- From lavallee01@yahoo.com Fri Mar 16 09:42:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9073D21F8755 for ; Fri, 16 Mar 2012 09:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_95=3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGIYGU3284HT for ; Fri, 16 Mar 2012 09:42:33 -0700 (PDT) Received: from smtp104.prem.mail.ac4.yahoo.com (smtp104.prem.mail.ac4.yahoo.com [76.13.13.43]) by ietfa.amsl.com (Postfix) with SMTP id 8986221F8749 for ; Fri, 16 Mar 2012 09:42:26 -0700 (PDT) Received: (qmail 37044 invoked from network); 16 Mar 2012 16:42:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Importance:X-MimeOLE; b=CjbzjQzQa4HbYGqsf0kVyvRCsFkEJu5Y182+MVzSvRBCtiDzev9683/Lnd2knkyZZ9emRCuk0YHs7uDjo0R4+rLWH8V1qZeYhZY8r10msBy2uveUw+pyPm3mSe4Esl2IJ+0QefTPxPyAfzPf++TcwbOSskq7TTo2uN60BBHeie8= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1331916141; bh=DJ8c++mTnMIqtT1MKPgr5BJUgZrwYHP7yr3i/R557AQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Importance:X-MimeOLE; b=Oc6EiLMnsK3ZUARkKOiNeBFhuWTcZRAmZPyOgUbmRNsx2uiXCsG8mXjqdyXL250zEvnrfgsqMCJbrFoa6sskjOAfOMWuldZLCwhSAOJvYv0tI9ZuVoWqcP4SJP0zsSVVk/PUUYYl9BYOz+2hXhSLOtpD+KAaf7+392S9XWYPqhw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6ppurE0VM1ka03jbTrcRJlZuD0zXa1Bu3rj4KA33Nt9fhrw JTMXOteFwrIsOTykaep_oZ3_6QjepF0AOg3Lns.EWIcs87ifEXWpaYfOsIVX SokLQLKc0JYOEQpFPRve6QPNrwA5717KM1KHcMRYDEigd7K30oxe7Hge96N9 rIwJXHYqkVwY3NRWWSMFbThw3nGbETkkN0NLGjUzAy6dBvJMtt1OYbK8Gbf8 ZFMBsGgj5tjBlHHB8QPTLjIFGovcsjwFc4todByqQcmk.h.VJQCDMTy79rj4 dgKA9hCj2N3nLcRIdnCs9uFn4LjnZSLVingeUnI0R7ZRdjIreXT62BxwzvTs rXA5Pv.qRUEQtTwt.hb3ETsmcgQuea3v5yL5ok2hhbOj5KUkOw4VCttXIVkh NoDm_gNNrFg4VF25n2VsJME7TgIU9N1OHGwf_PA_LsP8w3RxXpy6v X-Yahoo-SMTP: q1Ifts2swBB.EYJ6F5fF0TU1erB0ddE- Received: from D152PD81 (lavallee01@71.29.175.171 with login) by smtp104.prem.mail.ac4.yahoo.com with SMTP; 16 Mar 2012 09:42:21 -0700 PDT From: "Craig La Vallee" To: Date: Fri, 16 Mar 2012 12:42:41 -0400 Message-ID: <4B6DFC14AF8C48C7A7FF4747FED7E2C2@D152PD81> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6863 Thread-Index: Ac0Dk84Kl3l9tjXaToGsPGEqDi2/8A== Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [mpls] Does any know if the header contains a content identifier? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:42:34 -0000 Does the header portion comprise a creation date identifier or content identifier? Thank you, CJ From liu.guoman@zte.com.cn Mon Mar 19 02:08:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7622721F8528 for ; Mon, 19 Mar 2012 02:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.335 X-Spam-Level: X-Spam-Status: No, score=-96.335 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSl83SAg5Du8 for ; Mon, 19 Mar 2012 02:08:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A5AE621F8513 for ; Mon, 19 Mar 2012 02:08:10 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12280806486374; Mon, 19 Mar 2012 16:34:23 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84000.806486374; Mon, 19 Mar 2012 17:07:01 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id q2J971lE002943 for ; Mon, 19 Mar 2012 17:07:01 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2G9XN2Q043477; Fri, 16 Mar 2012 17:33:23 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) Message-Id: <201203190907.q2J971lE002943@mse01.zte.com.cn> In-Reply-To: To: Yaacov Weingarten MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 From: liu.guoman@zte.com.cn Date: Fri, 16 Mar 2012 17:33:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-16 17:33:24, Serialize complete at 2012-03-16 17:33:24 Content-Type: multipart/alternative; boundary="=_alternative 0034839B482579C3_=" X-MAIL: mse01.zte.com.cn q2J971lE002943 X-MSS: AUDITRELEASE@mse01.zte.com.cn Cc: mpls@ietf.org, draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org Subject: Re: [mpls] Comments/Questions about "p2mp shared protection" draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 09:08:12 -0000 This is a multipart message in MIME format. --=_alternative 0034839B482579C3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWFhY292o6xoaQ0KdGhhbmsgeW91IGZvciBwcm92aWRpbmcgYSBsb3Qgb2YgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyBmb3IgdGhpcyBkcmFmdC4gDQpxdWVzdGlvbiAxLCBmb3IgdGhlIGFyY2hpdGVj dHVyZSBvZiBwcm90ZWN0aW9uIGRvbWFpbi4gSU1PLCBpdCBpcyB2ZXJ5IA0KcmFyZSBzZW5hcmlv IHRvIHVzZSBvbmUgcHJvdGVjdGlvbiBwYXRoIHRvIHByb3RlY3Qgc2V2ZXJhbCB3b3JraW5nIHBh dGhzIA0Kd2hpY2ggYWxsIGhhdmUgdGhlIHNhbWUgc2V0IG9mIHJvb3QgYW5kIGxlYXZlcy4gaWYg d2UgY29uc2lkZXIgdGhlIA0Kc2NlbmFyaW8gaW4gdGhpcyBkcmFmdCwgbWF5YmUgaXQgdXNlIG9u ZSBwcm90ZWN0aW9uIHBhdGggdG8gcHJvdGVjdCANCnNldmVyYWwgd29ya2luZyBwYXRocyB3aGlj aCBuZWVkbid0IGhhdmUgdGhlIHNhbWUgc2V0IG9mIHJvb3QgYW5kIGxlYXZlcy4gDQppIHRoaW5r IG1vcmUgc2VuYXJpb3MgaW4gcmVhbCBuZXR3b3JrIGJlbG9uZyB0byB0aGUgc2l0dWF0aW9uLiBz byBpdCBtYXliZSANCm92ZXIgdGhlIHNjb3BlIG9mIHRoZSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29y ay4NCg0KIHF1ZXN0aW9uIDIsIGkgdGhpbmsgeW91ciB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0LCBz b21lIGxlYXZlcyB3aGljaCBub3QgDQppbnRlbmRlZCB0byByZWNlaXZlIHRoZSBwYWNrZXQgd2ls bCByZWNlaXZlIHRoZSBwYWNrZXQuIG1heSB3ZSBmdXJ0aGVyIA0KY29uc2lkZXIgdGhlIHByb2Js ZW0gaW4gdGhlIGZ1dHVyZS4NCg0KIHF1ZXN0aW9uIDMsIGkgdGhpbmsgaWYgdGhlcmUgaXMgbm8g TFNQL1BXIGlkZW50aWZlciBUTFYgaW4gUkRJIHBhY2tldCwgaXQgDQppcyBuZWNlc3NhcnkgZm9y IHRoZSByb290IG5vZGUgdG8gYmluZCBSREkgcGFja2V0IHRvIGEgc3BlY2lhbCBMU1AgLCBmb3Ig DQpleG1hcGxlLCBpdCBtYXliZSBjb3JyZWxhdGUgUkRJDQogdG8gYSBzcGVjaWFsIHJldHVybiBw YXRoLiBzbyB0aGF0IHRoZSByb290IG5vZGUgY2FuIGtub3cgd2hpY2ggd29ya2luZyANCnBhdGgg aGFzIHRoZSBmYWlsdXJlIGJhc2VkIG9uIHRoZSByZXR1cm4gcGF0aDsNCg0KIHF1ZXN0aW9uIDQs NSx0aGlzIGlzIGVuZCB0byBlbmQgcHJvdGVjdGlvbiBzb2x1dGlvbi4gaWYgdGhlIGZhaWx1cmUg DQpoYXBwZW5lZCBvbiBvbmUgb2YgdGhlIG4gd29ya2luZyBwYXRoLCB0aGV5IG11c3Qgbm90aWZ5 IHRoZSBmYWlsdXJlIA0KbWVzc2FnZSB0byB0aGUgcm9vdCBvZiBwcm90ZWN0aW9uIHBhdGguIHNv IHRoZSByb290DQp3aWxsIHNlbGVjdCBvbmUgZmFpbHVyZSB3b3JraW5nIHBhdGggd2hpY2ggaXMg dGhlIGhpZ2hlc3QgcHJpb3JpdHkgdG8gYmUgDQpwcm90ZWNlZC4gaXQgZG9uJ3QgcmVxdWlyZSB0 aGUgbm9kZSBvZiBzaGFyZWQgcHJvdGVjdGlvbiBzZWdtZW50IHRvIA0KY29tcGFyZSB0aGUgcHJp b3JpdHkgdG8gc2VsZWN0IG9uZSB3b3JraW5nIHBhdGggdG8gYmUgcHJvdGVjdGVkLiBzbyBpdCBp cyANCmRpZmZlcmVudCBmcm9tIHRoZSBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uLg0KDQp3aGF0IGkg c2FpZCBtYXkgbm90IGJlIHJpZ2h0PyB0aGFuayB5b3UNCg0KYmVzdCByZWdhcmRzDQpsaXUNCg0K DQoNCg0KDQoNCg0KDQoNCllhYWNvdiBXZWluZ2FydGVuIDx3eWFhY292QGdtYWlsLmNvbT4gDQq3 orz+yMs6ICBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTItMDMtMTUgMjE6MzQNCg0KytW8/sjL DQptcGxzQGlldGYub3JnLCANCmRyYWZ0LWxpdS1wd2UzLW1wbHMtdHAtcDJtcC1zaGFyZWQtcHJv dGVjdGlvbkB0b29scy5pZXRmLm9yZw0Ks63LzQ0KDQrW98ziDQpbbXBsc10gQ29tbWVudHMvUXVl c3Rpb25zIGFib3V0ICJwMm1wIHNoYXJlZCBwcm90ZWN0aW9uIiBkcmFmdA0KDQoNCg0KDQoNCg0K SGksIGF1dGhvcnMgDQoNCkkgaGF2ZSByZWFkIHlvdXIgZHJhZnQgYW5kIGZpbmQgdGhhdCBJIGhh dmUgcXVpdGUgYSBmZXcgcXVlc3Rpb25zIGFuZCANCmNvbW1lbnRzIGFib3V0IHRoZSBwcm9wb3Nh bHMgaW4gdGhlIGRyYWZ0IGFuZCB0aGUgcHJlc2VudGF0aW9uOg0KDQoxLiAgWW91IHByZXNlbnQg dHdvIGRpZmZlcmVudCBzY2VuYXJpb3MgZm9yIHByb3RlY3Rpb24gb2YgcDJtcCBNUExTLVRQIA0K dHJhZmZpYywgYnV0IHlvdSBkbyBub3QgcmVhbGx5IGRlZmluZSB3aGF0IHRoZSBhcmNoaXRlY3R1 cmUgb2YgeW91ciANCnByb3RlY3Rpb24gZG9tYWluIGlzLg0KVGFraW5nIHRoZSBmaXJzdCBzb2x1 dGlvbiwgd2hlcmUgeW91IHByb3Bvc2UgdXNpbmcgYSAxOm4gcHJvdGVjdGlvbiBzY2hlbWUgDQot IG5vcm1hbGx5LCBhbmQgYXMgcHJlc2VudGVkIGluIHRoZSBTdXJ2aXZhYmlsaXR5IEZyYW1ld29y ayBhIDE6biANCnByb3RlY3Rpb24gZG9tYWluIGNvbnNpc3RzIG9mIHNldmVyYWwgd29ya2luZyBw YXRocyBhbmQgYSBzaW5nbGUgDQpwcm90ZWN0aW9uIHBhdGggdGhhdCBhbGwgaGF2ZSB0aGUgc2Ft ZSBzZXQgb2Ygcm9vdCBhbmQgbGVhdmVzLiAgWWV0IGluIA0KeW91ciBmaWd1cmUgMyB5b3Ugc2hv dyBhIDE6MiBkb21haW4gdGhhdCB0aGUgd29ya2luZyBwYXRocyBoYXZlIGRpZmZlcmVudCANCnJv b3RzIGFuZCBkaWZmZXJlbnQgc2V0cyBvZiBsZWFmcyEgIEl0IHdvdWxkIGJlIGhlbHBmdWwsIElN TywgaWYgeW91IGNvdWxkIA0KZGVmaW5lIHdoYXQgcHJvdGVjdGlvbiBkb21haW4geW91IGFyZSBy ZWZlcmVuY2luZy4NCg0KMi4gSW4gdGhlIHNjZW5hcmlvIHRoYXQgeW91IHByZXNlbnQgaW4gZmln dXJlIDMsIHlvdXIgcHJvdGVjdGlvbiBwYXRoIA0Kc3RhcnRzIGF0IGEgZGlmZmVyZW50IHJvb3Qg dGhhbiBlaXRoZXIgd29ya2luZyBwYXRoIChmb3Igd2hpY2ggSSBjb21tZW50ZWQgDQphYm92ZSkg YnV0IHdoYXQgd29ycmllcyBtZSBtb3JlIGlzIHRoYXQgaXRzIGRlc3RpbmF0aW9uIGxlYWZzIHNl ZW0gdG8gYmUgDQp0aGUgdW5pb24gb2YgdGhlIGxlYWZzIG9mIGFsbCBvZiB0aGUgd29ya2luZyBw YXRocy4gIERvZXNuJ3QgdGhpcyByYWlzZSANCnNvbWUgc2VjdXJpdHkgYW5kIGNvbmdlc3Rpb24g cHJvYmxlbXM/ICBGb3IgZXhhbXBsZSwgbGV0J3MgdGFrZSB0aGUgc2ltcGxlIA0KY2FzZSBvZiBh IHNpbmdsZSBmYWlsdXJlIG9uIG9uZSBvZiB0aGUgd29ya2luZyBwYXRocyAtIGJ5IHN3aXRjaGlu ZyBvdmVyIA0KdG8gdGhlIHByb3RlY3Rpb24gcGF0aCB0aGUgdHJhZmZpYyBmcm9tIHRoaXMgc2Vy dmljZSB3aWxsIGJlIGRlbGl2ZXJlZCB0byANCnNvbWUgZGVzdGluYXRpb25zIHRoYXQgaXQgd2Fz IG5vdCBpbnRlbmRlZCB0byByZWNlaXZlIHRoZSBwYWNrZXRzPyAgSW4gDQphZGRpdGlvbiwgdGhl IHNlY3Rpb25zIHRvIHRoaXMgZGVzdGluYXRpb24gYXJlIHN1ZGRlbmx5IGNhcnJ5aW5nIHBhY2tl dHMgDQp0aGF0IGFyZSB1bm5lY2Vzc2FyeSBhbmQganVzdCBjYXVzaW5nIGFkZGl0aW9uYWwgdHJh ZmZpYyBvbiB0aGUgbGlua3MhDQoNCjMuIEJvdGggb2YgeW91ciBzb2x1dGlvbnMgYXJlIGdyZWF0 bHkgZGVwZW5kZW50IHVwb24gdGhlIFJESSANCmZ1bmN0aW9uYWxpdHksIGFuZCB5b3Ugc3RhdGUg dGhhdCB0aGUgcm9vdCB3aWxsIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlIA0KcmVsZXZhbnQgd29y a2luZyB0cmFuc3BvcnQgcGF0aCBiYXNlZCBvbiB0aGlzIGluZm9ybWF0aW9uLiAgSG93ZXZlciwg dGhlIA0KUkRJIGZvciBNUExTLVRQIGlzIGRlZmluZWQgYXMgcGFydCBvZiB0aGUgRXh0ZW5zaW9u IHRvIEJGRCBhbmQgb25seSB3aXRoaW4gDQp0aGUgQ0MgbWVzc2FnZXMgKGl0IGlzIGlnbm9yZWQg aW4gdGhlIENWIG1lc3NhZ2UpIHRoYXQgZG8gbm90IGluY2x1ZGUgYSANCkxTUC9QVyBpZGVudGlm aWVyIFRMVi4gIEFuZCBjb25zaWRlcmluZyB0aGF0IHAybXAgcGF0aHMgaW4gTVBMUy1UUCBhcmUg DQp1bmlkaXJlY3Rpb25hbCwgSSB0aGluayB0aGF0IHlvdSBuZWVkIHRvIGNsZWFybHkgZXhwbGFp biBob3cgdGhlIHJvb3QgDQpyZWNlaXZlcyB0aGUgUkRJIGFuZCBob3cgaXQgY29ycmVsYXRlcyB0 aGlzIFJESSB0byBhIHBhcnRpY3VsYXIgTFNQLg0KDQo0LiBJbiB5b3VyIHNvbHV0aW9uIHRoYXQg aXMgYmFzZWQgb24gKDE6MSlebiBwcm90ZWN0aW9uIC0geW91IHN0YXRlIHRoYXQgDQp0aGUgcm9v dCBtdXN0ICJjb21wYXJlIHRoZSBwcmlvcml0eSBhbW9uZyB0aGVzZSBwcm90ZWN0aW9uIHBhdGhz Li4uIiAtIGJ1dCANCkkgdGhvdWdodCB0aGF0IGluIHRoaXMgcHJvdGVjdGlvbiBzY2hlbWUgdGhl IHByb3RlY3Rpb24gc3dpdGNoIGlzIA0KcGVyZm9ybWVkIHdpdGhpbiBhIHNpbmdsZSAxOjEgZG9t YWluLCBzbyB0aGVyZSBpcyBub3RoaW5nIGZvciB0aGUgcm9vdCB0byANCmNvbXBhcmUgdG8hICBX aGF0IEkgYmVsaWV2ZSB0aGF0IHlvdSBtZWFudCBpcyB0aGF0IGVhY2ggc2hhcmVkIHNlZ21lbnQg bWF5IA0KbmVlZCAoaW4gdGhlIGNhc2Ugb2YgbXVsdGlwbGUgZmF1bHRzKSB0byBjb21wYXJlIHRo ZSBwcmlvcml0aWVzIG9mIHRoZSANCmRpZmZlcmVudCByZXF1ZXN0cyBmb3IgdGhlIHNoYXJlZCBy ZXNvdXJjZXMhDQoNCjUuICBDYW4geW91IGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVu IHlvdXIgcHJvcG9zYWxzIGFuZCB0aGUgZHJhZnRzIA0KdGhhdCBhcmUgYXZhaWxhYmxlIGZvciAx Om4gcHJvdGVjdGlvbiBhbmQgc2hhcmVkIG1lc2ggcHJvdGVjdGlvbiAoaW4gDQpwYXJ0aWN1bGFy IGRyYWZ0LWNoZXVuZyB0aGF0IGlzIGFsc28gYmFzZWQgb24gKDE6MSlebiBwcm90ZWN0aW9uKT8g IENhbiANCnlvdSB1c2UgdGhlIHNhbWUgZXh0ZW5zaW9ucyB0aGF0IGFyZSBwcm9wb3NlZCBpbiB0 aG9zZSBkcmFmdHM/DQoNClRoYW5rIHlvdSwNCllhYWNvdiBXZWluZ2FydGVuX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 0034839B482579C3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllhYWNvdqOsaGk8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rIHlvdSBmb3IgcHJvdmlkaW5n IGEgbG90IG9mIGNvbW1lbnRzDQphbmQgcXVlc3Rpb25zIGZvciB0aGlzIGRyYWZ0LiA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnF1ZXN0aW9uIDEsIGZvciB0aGUg YXJjaGl0ZWN0dXJlIG9mDQpwcm90ZWN0aW9uIGRvbWFpbi4gSU1PLCBpdCBpcyB2ZXJ5IHJhcmUg c2VuYXJpbyB0byB1c2Ugb25lIHByb3RlY3Rpb24gcGF0aA0KdG8gcHJvdGVjdCBzZXZlcmFsIHdv cmtpbmcgcGF0aHMgd2hpY2ggYWxsIGhhdmUgdGhlIHNhbWUgc2V0IG9mIHJvb3QgYW5kDQpsZWF2 ZXMuIGlmIHdlIGNvbnNpZGVyIHRoZSBzY2VuYXJpbyBpbiB0aGlzIGRyYWZ0LCBtYXliZSBpdCB1 c2Ugb25lIHByb3RlY3Rpb24NCnBhdGggdG8gcHJvdGVjdCBzZXZlcmFsIHdvcmtpbmcgcGF0aHMg d2hpY2ggbmVlZG4ndCBoYXZlIHRoZSBzYW1lIHNldCBvZg0Kcm9vdCBhbmQgbGVhdmVzLiBpIHRo aW5rIG1vcmUgc2VuYXJpb3MgaW4gcmVhbCBuZXR3b3JrIGJlbG9uZyB0byB0aGUgc2l0dWF0aW9u Lg0Kc28gaXQgbWF5YmUgb3ZlciB0aGUgc2NvcGUgb2YgdGhlIHN1cnZpdmFiaWxpdHkgZnJhbWV3 b3JrLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7cXVlc3Rpb24gMiwgaSB0aGluayB5b3VyIHVuZGVyc3RhbmRpbmcNCmlzIHJpZ2h0LCBzb21l IGxlYXZlcyB3aGljaCBub3QgaW50ZW5kZWQgdG8gcmVjZWl2ZSB0aGUgcGFja2V0IHdpbGwgcmVj ZWl2ZQ0KdGhlIHBhY2tldC4gbWF5IHdlIGZ1cnRoZXIgY29uc2lkZXIgdGhlIHByb2JsZW0gaW4g dGhlIGZ1dHVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwO3F1ZXN0aW9uIDMsIGkgdGhpbmsgaWYgdGhlcmUgaXMNCm5vIExTUC9QVyBpZGVu dGlmZXIgVExWIGluIFJESSBwYWNrZXQsIGl0IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIHJvb3Qgbm9k ZQ0KdG8gYmluZCBSREkgcGFja2V0IHRvIGEgc3BlY2lhbCBMU1AgLCBmb3IgZXhtYXBsZSwgaXQg bWF5YmUgY29ycmVsYXRlIFJESTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7dG8gYSBzcGVjaWFsIHJldHVybiBwYXRoLiBzbyB0aGF0DQp0aGUgcm9vdCBu b2RlIGNhbiBrbm93IHdoaWNoIHdvcmtpbmcgcGF0aCBoYXMgdGhlIGZhaWx1cmUgYmFzZWQgb24g dGhlDQpyZXR1cm4gcGF0aDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwO3F1ZXN0aW9uIDQsNSx0aGlzIGlzIGVuZCB0byBlbmQNCnByb3RlY3Rp b24gc29sdXRpb24uIGlmIHRoZSBmYWlsdXJlIGhhcHBlbmVkIG9uIG9uZSBvZiB0aGUgbiB3b3Jr aW5nIHBhdGgsDQp0aGV5IG11c3Qgbm90aWZ5IHRoZSBmYWlsdXJlIG1lc3NhZ2UgdG8gdGhlIHJv b3Qgb2YgcHJvdGVjdGlvbiBwYXRoLiBzbw0KdGhlIHJvb3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPndpbGwgc2VsZWN0IG9uZSBmYWlsdXJlIHdvcmtpbmcgcGF0 aA0Kd2hpY2ggaXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHkgdG8gYmUgcHJvdGVjZWQuIGl0IGRvbid0 IHJlcXVpcmUgdGhlIG5vZGUNCm9mIHNoYXJlZCBwcm90ZWN0aW9uIHNlZ21lbnQgdG8gY29tcGFy ZSB0aGUgcHJpb3JpdHkgdG8gc2VsZWN0IG9uZSB3b3JraW5nDQpwYXRoIHRvIGJlIHByb3RlY3Rl ZC4gc28gaXQgaXMgZGlmZmVyZW50IGZyb20gdGhlIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24uPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53aGF0IGkgc2Fp ZCBtYXkgbm90IGJlIHJpZ2h0PyB0aGFuaw0KeW91PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRp diBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5ZYWFjb3YgV2VpbmdhcnRlbiAmbHQ7d3lh YWNvdkBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21wbHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAzLTE1IDIxOjM0PC9mb250Pg0K PHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHNAaWV0 Zi5vcmcsIGRyYWZ0LWxpdS1wd2UzLW1wbHMtdHAtcDJtcC1zaGFyZWQtcHJvdGVjdGlvbkB0b29s cy5pZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+W21wbHNdIENvbW1lbnRzL1F1ZXN0aW9ucyBhYm91dCAmcXVvdDtwMm1wDQpz aGFyZWQgcHJvdGVjdGlvbiZxdW90OyBkcmFmdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5IaSwgYXV0aG9ycyZuYnNwOzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+SSBoYXZlIHJlYWQgeW91ciBkcmFmdCBhbmQgZmluZCB0aGF0IEkg aGF2ZSBxdWl0ZSBhIGZldw0KcXVlc3Rpb25zIGFuZCBjb21tZW50cyBhYm91dCB0aGUgcHJvcG9z YWxzIGluIHRoZSBkcmFmdCBhbmQgdGhlIHByZXNlbnRhdGlvbjo8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPjEuICZuYnNwO1lvdSBwcmVzZW50IHR3byBkaWZmZXJlbnQgc2NlbmFyaW9z IGZvciBwcm90ZWN0aW9uDQpvZiBwMm1wIE1QTFMtVFAgdHJhZmZpYywgYnV0IHlvdSBkbyBub3Qg cmVhbGx5IGRlZmluZSB3aGF0IHRoZSBhcmNoaXRlY3R1cmUNCm9mIHlvdXIgcHJvdGVjdGlvbiBk b21haW4gaXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5UYWtpbmcgdGhlIGZpcnN0IHNvbHV0 aW9uLCB3aGVyZSB5b3UgcHJvcG9zZSB1c2luZyBhIDE6bg0KcHJvdGVjdGlvbiBzY2hlbWUgLSBu b3JtYWxseSwgYW5kIGFzIHByZXNlbnRlZCBpbiB0aGUgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsN CmEgMTpuIHByb3RlY3Rpb24gZG9tYWluIGNvbnNpc3RzIG9mIHNldmVyYWwgd29ya2luZyBwYXRo cyBhbmQgYSBzaW5nbGUNCnByb3RlY3Rpb24gcGF0aCB0aGF0IGFsbCBoYXZlIHRoZSBzYW1lIHNl dCBvZiByb290IGFuZCBsZWF2ZXMuICZuYnNwO1lldA0KaW4geW91ciBmaWd1cmUgMyB5b3Ugc2hv dyBhIDE6MiBkb21haW4gdGhhdCB0aGUgd29ya2luZyBwYXRocyBoYXZlIGRpZmZlcmVudA0Kcm9v dHMgYW5kIGRpZmZlcmVudCBzZXRzIG9mIGxlYWZzISAmbmJzcDtJdCB3b3VsZCBiZSBoZWxwZnVs LCBJTU8sIGlmIHlvdQ0KY291bGQgZGVmaW5lIHdoYXQgcHJvdGVjdGlvbiBkb21haW4geW91IGFy ZSByZWZlcmVuY2luZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjIuIEluIHRoZSBz Y2VuYXJpbyB0aGF0IHlvdSBwcmVzZW50IGluIGZpZ3VyZSAzLCB5b3VyDQpwcm90ZWN0aW9uIHBh dGggc3RhcnRzIGF0IGEgZGlmZmVyZW50IHJvb3QgdGhhbiBlaXRoZXIgd29ya2luZyBwYXRoIChm b3INCndoaWNoIEkgY29tbWVudGVkIGFib3ZlKSBidXQgd2hhdCB3b3JyaWVzIG1lIG1vcmUgaXMg dGhhdCBpdHMgZGVzdGluYXRpb24NCmxlYWZzIHNlZW0gdG8gYmUgdGhlIHVuaW9uIG9mIHRoZSBs ZWFmcyBvZiBhbGwgb2YgdGhlIHdvcmtpbmcgcGF0aHMuICZuYnNwO0RvZXNuJ3QNCnRoaXMgcmFp c2Ugc29tZSBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBwcm9ibGVtcz8gJm5ic3A7Rm9yIGV4YW1w bGUsIGxldCdzDQp0YWtlIHRoZSBzaW1wbGUgY2FzZSBvZiBhIHNpbmdsZSBmYWlsdXJlIG9uIG9u ZSBvZiB0aGUgd29ya2luZyBwYXRocyAtDQpieSBzd2l0Y2hpbmcgb3ZlciB0byB0aGUgcHJvdGVj dGlvbiBwYXRoIHRoZSB0cmFmZmljIGZyb20gdGhpcyBzZXJ2aWNlDQp3aWxsIGJlIGRlbGl2ZXJl ZCB0byBzb21lIGRlc3RpbmF0aW9ucyB0aGF0IGl0IHdhcyBub3QgaW50ZW5kZWQgdG8gcmVjZWl2 ZQ0KdGhlIHBhY2tldHM/ICZuYnNwO0luIGFkZGl0aW9uLCB0aGUgc2VjdGlvbnMgdG8gdGhpcyBk ZXN0aW5hdGlvbiBhcmUgc3VkZGVubHkNCmNhcnJ5aW5nIHBhY2tldHMgdGhhdCBhcmUgdW5uZWNl c3NhcnkgYW5kIGp1c3QgY2F1c2luZyBhZGRpdGlvbmFsIHRyYWZmaWMNCm9uIHRoZSBsaW5rcyE8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjMuIEJvdGggb2YgeW91ciBzb2x1dGlvbnMg YXJlIGdyZWF0bHkgZGVwZW5kZW50IHVwb24gdGhlDQpSREkgZnVuY3Rpb25hbGl0eSwgYW5kIHlv dSBzdGF0ZSB0aGF0IHRoZSByb290IHdpbGwgYmUgYWJsZSB0byBpZGVudGlmeQ0KdGhlIHJlbGV2 YW50IHdvcmtpbmcgdHJhbnNwb3J0IHBhdGggYmFzZWQgb24gdGhpcyBpbmZvcm1hdGlvbi4gJm5i c3A7SG93ZXZlciwNCnRoZSBSREkgZm9yIE1QTFMtVFAgaXMgZGVmaW5lZCBhcyBwYXJ0IG9mIHRo ZSBFeHRlbnNpb24gdG8gQkZEIGFuZCBvbmx5DQp3aXRoaW4gdGhlIENDIG1lc3NhZ2VzIChpdCBp cyBpZ25vcmVkIGluIHRoZSBDViBtZXNzYWdlKSB0aGF0IGRvIG5vdCBpbmNsdWRlDQphIExTUC9Q VyBpZGVudGlmaWVyIFRMVi4gJm5ic3A7QW5kIGNvbnNpZGVyaW5nIHRoYXQgcDJtcCBwYXRocyBp biBNUExTLVRQDQphcmUgdW5pZGlyZWN0aW9uYWwsIEkgdGhpbmsgdGhhdCB5b3UgbmVlZCB0byBj bGVhcmx5IGV4cGxhaW4gaG93IHRoZSByb290DQpyZWNlaXZlcyB0aGUgUkRJIGFuZCBob3cgaXQg Y29ycmVsYXRlcyB0aGlzIFJESSB0byBhIHBhcnRpY3VsYXIgTFNQLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+NC4gSW4geW91ciBzb2x1dGlvbiB0aGF0IGlzIGJhc2VkIG9uICgxOjEp Xm4gcHJvdGVjdGlvbg0KLSB5b3Ugc3RhdGUgdGhhdCB0aGUgcm9vdCBtdXN0ICZxdW90O2NvbXBh cmUgdGhlIHByaW9yaXR5IGFtb25nIHRoZXNlIHByb3RlY3Rpb24NCnBhdGhzLi4uJnF1b3Q7IC0g YnV0IEkgdGhvdWdodCB0aGF0IGluIHRoaXMgcHJvdGVjdGlvbiBzY2hlbWUgdGhlIHByb3RlY3Rp b24NCnN3aXRjaCBpcyBwZXJmb3JtZWQgd2l0aGluIGEgc2luZ2xlIDE6MSBkb21haW4sIHNvIHRo ZXJlIGlzIG5vdGhpbmcgZm9yDQp0aGUgcm9vdCB0byBjb21wYXJlIHRvISAmbmJzcDtXaGF0IEkg YmVsaWV2ZSB0aGF0IHlvdSBtZWFudCBpcyB0aGF0IGVhY2gNCnNoYXJlZCBzZWdtZW50IG1heSBu ZWVkIChpbiB0aGUgY2FzZSBvZiBtdWx0aXBsZSBmYXVsdHMpIHRvIGNvbXBhcmUgdGhlDQpwcmlv cml0aWVzIG9mIHRoZSBkaWZmZXJlbnQgcmVxdWVzdHMgZm9yIHRoZSBzaGFyZWQgcmVzb3VyY2Vz ITwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+NS4gJm5ic3A7Q2FuIHlvdSBleHBsYWlu IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB5b3VyDQpwcm9wb3NhbHMgYW5kIHRoZSBkcmFmdHMg dGhhdCBhcmUgYXZhaWxhYmxlIGZvciAxOm4gcHJvdGVjdGlvbiBhbmQgc2hhcmVkDQptZXNoIHBy b3RlY3Rpb24gKGluIHBhcnRpY3VsYXIgZHJhZnQtY2hldW5nIHRoYXQgaXMgYWxzbyBiYXNlZCBv biAoMToxKV5uDQpwcm90ZWN0aW9uKT8gJm5ic3A7Q2FuIHlvdSB1c2UgdGhlIHNhbWUgZXh0ZW5z aW9ucyB0aGF0IGFyZSBwcm9wb3NlZCBpbg0KdGhvc2UgZHJhZnRzPzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+VGhhbmsgeW91LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+WWFhY292 IFdlaW5nYXJ0ZW48L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBs c0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs czxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 0034839B482579C3_=-- From quintin.zhao@huawei.com Mon Mar 19 09:03:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11B321F87CF for ; Mon, 19 Mar 2012 09:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbKV2t1Yg6FH for ; Mon, 19 Mar 2012 09:03:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0621F8616 for ; Mon, 19 Mar 2012 09:03:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEN14696; Mon, 19 Mar 2012 12:03:45 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 09:02:34 -0700 Received: from QZHAO (10.212.244.245) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server id 14.1.323.3; Mon, 19 Mar 2012 09:02:31 -0700 From: Quintin Zhao To: Date: Mon, 19 Mar 2012 12:02:25 -0400 Message-ID: <003001cd05e9$ae7a6c70$0b6f4550$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz/+9wDVH2B7YMeThCTc7nuUpwzeAF7OI9w Content-Language: zh-cn X-Originating-IP: [10.212.244.245] X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-ietf-mpls-ldp-multi-topology-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:03:48 -0000 We have gotten a lot of comments and suggestions both from the Taipei = meeting and after the meeting. Especially thanks=20 for the comments and suggestions from Eric Rosen, Ijsbrand Wijnands, = Alia Atlas, Yiqun Cai and Dimitri Papadimitriou. =20 Based on the feedbacks we got, we updated the draft. In summary the new = version has the following updates:=20 1. The MT IP Address family is defined and it is used in the existing = prefix FEC element. 2. LDP MT capability advertisement TLV is updated to include the MT = Typed Wildcard FEC element. 3. New status codes are added; 4. The application scenario section is moved into the appendix section. .=09 We appreciate your further comments and suggestions. Quintin -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 2012=E5=B9=B43=E6=9C=8811=E6=97=A5 22:57 To: quintin.zhao@huawei.com Cc: czhou@cisco.com; lufang@cisco.com; ning.so@verizonbusiness.com; = lilianyuan@chinamobile.com Subject: New Version Notification for = draft-ietf-mpls-ldp-multi-topology-03.txt A new version of I-D, draft-ietf-mpls-ldp-multi-topology-03.txt has been = successfully submitted by Quintin Zhao and posted to the IETF = repository. Filename: draft-ietf-mpls-ldp-multi-topology Revision: 03 Title: LDP Extensions for Multi Topology Routing Creation date: 2012-03-11 WG ID: mpls Number of pages: 18 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. = =20 The IETF Secretariat From quintin.zhao@huawei.com Mon Mar 19 09:15:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C9821F871B for ; Mon, 19 Mar 2012 09:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAlrKwzpJHTI for ; Mon, 19 Mar 2012 09:15:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0921F8692 for ; Mon, 19 Mar 2012 09:15:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEF11001; Mon, 19 Mar 2012 12:15:25 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 09:13:45 -0700 Received: from QZHAO (10.212.244.245) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server id 14.1.323.3; Mon, 19 Mar 2012 09:13:42 -0700 From: Quintin Zhao To: Date: Mon, 19 Mar 2012 12:13:35 -0400 Message-ID: <003101cd05eb$3d3f6270$b7be2750$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Ap7dk/50TR+mJQJ+RKIboqrFTsAFQqEtQ Content-Language: zh-cn X-Originating-IP: [10.212.244.245] X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-zhao-mpls-mldp-protections-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:15:26 -0000 We have submitted the draft for mLDP protection in October, 2011 and = presented it in IETF82. We have gotten a lot of comments and suggestions = both from the Taipei meeting and after the meeting. Especially thanks = for the feedbacks from Ijsbrand Wijnands and Alia Atlas. Based on the = feedbacks we got, we updated the draft and now we have submitted the new = version. The major updates in the new version includes:=20 1. The procedure details added for the backup p2p LSP=E2=80=99s cleanup = for p2p based mLDp node protections. 2. The protocol extensions added for the backup p2p LSP=E2=80=99s = cleanup for p2p based mLDp node protections. 3. Two switchover modes for backup path forwarding are added, one mode = is for the case when node failure=20 detection from the PLR node is available and another mode is for the = case when the node failure detection=20 from the PLR node is not available; 4. Examples added for p2p based mLDP node protection and p2mp based mLDP = node protections. We appreciate your further comments and suggestions. Quintin -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 2012=E5=B9=B43=E6=9C=8812=E6=97=A5 19:28 To: emily.chenying@huawei.com Cc: tao.chou@huawei.com; quintin.zhao@huawei.com; daniel@olddog.co.uk Subject: New Version Notification for = draft-zhao-mpls-mldp-protections-02.txt A new version of I-D, draft-zhao-mpls-mldp-protections-02.txt has been = successfully submitted by Emily Chen and posted to the IETF repository. Filename: draft-zhao-mpls-mldp-protections Revision: 02 Title: Protection Mechanisms for Label Distribution Protocol = P2MP/MP2MP Label Switched Paths Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 26 Abstract: Service providers continue to deploy real-time multicast applications using Multicast LDP (mLDP) across MPLS networks. There is a clear need to protect these real-time applications and to minimize switching times in the event of failure. This document outlines the requirements, procedures and extensions to facilitate mLDP Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP-to-MP) LSP protection within an MPLS network. = =20 The IETF Secretariat From martin.vigoureux@alcatel-lucent.com Mon Mar 19 15:20:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B921F884C for ; Mon, 19 Mar 2012 15:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJn-DXchNZkN for ; Mon, 19 Mar 2012 15:20:02 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0421F8843 for ; Mon, 19 Mar 2012 15:20:01 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2JMJxP2012469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Mar 2012 23:20:00 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Mar 2012 23:19:59 +0100 Received: from [135.244.4.101] (135.5.27.12) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 19 Mar 2012 18:19:57 -0400 Message-ID: <4F67B108.8070301@alcatel-lucent.com> Date: Mon, 19 Mar 2012 23:19:52 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [mpls] IETF83 - MPLS Sessions - Agenda Uploaded X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:20:03 -0000 Hi, you can find the agenda here: http://www.ietf.org/proceedings/83/agenda/agenda-83-mpls.txt Sorry for the delay martin From yaacov.weingarten@nsn.com Tue Mar 20 03:24:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE321F865F for ; Tue, 20 Mar 2012 03:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PasKexnW0Xyk for ; Tue, 20 Mar 2012 03:24:51 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B751621F861A for ; Tue, 20 Mar 2012 03:24:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2KAOko9005275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Mar 2012 11:24:46 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2KAOfJ3027985; Tue, 20 Mar 2012 11:24:41 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 11:24:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0683.A61EB0D4" Date: Tue, 20 Mar 2012 11:24:34 +0100 Message-ID: In-Reply-To: <201203190907.q2J971lE002943@mse01.zte.com.cn> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comments/Questions about "p2mp shared protection" draft Thread-Index: Ac0Fr+mINR3Qz9mdT5GhwYAkXkWUZAA0hQcQ References: <201203190907.q2J971lE002943@mse01.zte.com.cn> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: , "Yaacov Weingarten" X-OriginalArrivalTime: 20 Mar 2012 10:24:36.0730 (UTC) FILETIME=[A67CEDA0:01CD0683] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 26158 X-purgate-ID: 151667::1332239087-00003570-4E4EE05F/0-0/0-0 Cc: mpls@ietf.org, draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org Subject: Re: [mpls] Comments/Questions about "p2mp shared protection" draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:24:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0683.A61EB0D4 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 See my comments inline below =20 BR, yaacov =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext liu.guoman@zte.com.cn Sent: Friday, March 16, 2012 11:33 AM To: Yaacov Weingarten Cc: mpls@ietf.org; = draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org Subject: Re: [mpls] Comments/Questions about "p2mp shared protection" = draft =20 Yaacov=A3=AChi=20 thank you for providing a lot of comments and questions for this draft.=20 question 1, for the architecture of protection domain. IMO, it is very = rare senario to use one protection path to protect several working paths = which all have the same set of root and leaves. if we consider the = scenario in this draft, maybe it use one protection path to protect = several working paths which needn't have the same set of root and = leaves. i think more senarios in real network belong to the situation. = so it maybe over the scope of the survivability framework.=20 [yw>] I think that I can agree with you that there will not be many = situations where a single protection path will be used for a number of = p2mp working paths that all have the same root and leafs. However, that = means that calling this 1:n is unrealistic and therefore I am not sure = that this scenario is very useful. However, this makes it even more = important for you to clearly define what the domain that you are = addressing is and what are the requirements.=20 I certainly believe that 1:n protection for p2p bidirectional paths is = useful and important and that we should not be causing any confusion by = using the terms without a clear definition. question 2, i think your understanding is right, some leaves which not = intended to receive the packet will receive the packet. may we further = consider the problem in the future.=20 [yw>] I think it is important to consider the implications of this = before advancing this proposal, both the security and congestion = aspects! question 3, i think if there is no LSP/PW identifer TLV in RDI packet, = it is necessary for the root node to bind RDI packet to a special LSP , = for exmaple, it maybe correlate RDI=20 to a special return path. so that the root node can know which working = path has the failure based on the return path; [yw>] This is very confusing =A8C since there is no "natural" return = path for a p2mp path, since by definition they are unidirectional paths = and any return path would need to be dependent on some other forwarding = method, e.g. IP forwarding, or some other LSP that is not directly = correlated with all of the p2mp LSPs that emanate from the root node. question 4,5,this is end to end protection solution. if the failure = happened on one of the n working path, they must notify the failure = message to the root of protection path. so the root=20 will select one failure working path which is the highest priority to be = proteced. it don't require the node of shared protection segment to = compare the priority to select one working path to be protected. so it = is different from the shared mesh protection.=20 [yw>] So again I think that it is very important for you to clearly = define what the protection domain is! what i said may not be right? thank you=20 best regards=20 liu=20 =09 Yaacov Weingarten =20 =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org=20 2012-03-15 21:34=20 =CA=D5=BC=FE=C8=CB mpls@ietf.org, = draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org=20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [mpls] Comments/Questions about "p2mp shared protection" draft =20 =09 Hi, authors =20 I have read your draft and find that I have quite a few questions and = comments about the proposals in the draft and the presentation:=20 1. You present two different scenarios for protection of p2mp MPLS-TP = traffic, but you do not really define what the architecture of your = protection domain is.=20 Taking the first solution, where you propose using a 1:n protection = scheme - normally, and as presented in the Survivability Framework a 1:n = protection domain consists of several working paths and a single = protection path that all have the same set of root and leaves. Yet in = your figure 3 you show a 1:2 domain that the working paths have = different roots and different sets of leafs! It would be helpful, IMO, = if you could define what protection domain you are referencing.=20 2. In the scenario that you present in figure 3, your protection path = starts at a different root than either working path (for which I = commented above) but what worries me more is that its destination leafs = seem to be the union of the leafs of all of the working paths. Doesn't = this raise some security and congestion problems? For example, let's = take the simple case of a single failure on one of the working paths - = by switching over to the protection path the traffic from this service = will be delivered to some destinations that it was not intended to = receive the packets? In addition, the sections to this destination are = suddenly carrying packets that are unnecessary and just causing = additional traffic on the links!=20 3. Both of your solutions are greatly dependent upon the RDI = functionality, and you state that the root will be able to identify the = relevant working transport path based on this information. However, the = RDI for MPLS-TP is defined as part of the Extension to BFD and only = within the CC messages (it is ignored in the CV message) that do not = include a LSP/PW identifier TLV. And considering that p2mp paths in = MPLS-TP are unidirectional, I think that you need to clearly explain how = the root receives the RDI and how it correlates this RDI to a particular = LSP.=20 4. In your solution that is based on (1:1)^n protection - you state that = the root must "compare the priority among these protection paths..." - = but I thought that in this protection scheme the protection switch is = performed within a single 1:1 domain, so there is nothing for the root = to compare to! What I believe that you meant is that each shared = segment may need (in the case of multiple faults) to compare the = priorities of the different requests for the shared resources!=20 5. Can you explain the relationship between your proposals and the = drafts that are available for 1:n protection and shared mesh protection = (in particular draft-cheung that is also based on (1:1)^n protection)? = Can you use the same extensions that are proposed in those drafts?=20 Thank you,=20 Yaacov Weingarten_______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01CD0683.A61EB0D4 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

See my comments inline = below

 

BR,

yaacov

 

From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext liu.guoman@zte.com.cn
Sent: Friday, March 16, 2012 = 11:33 AM
To: Yaacov Weingarten
Cc: mpls@ietf.org; = draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org
Subjec= t: Re: [mpls] Comments/Questions about "p2mp shared = protection" draft

 


Yaacov= =A3=AChi =
thank you = for providing a lot of comments and questions for this draft. =
question 1, = for the architecture of protection domain. IMO, it is very rare senario = to use one protection path to protect several working paths which all = have the same set of root and leaves. if we consider the scenario in = this draft, maybe it use one protection path to protect several working = paths which needn't have the same set of root and leaves. i think more = senarios in real network belong to the situation. so it maybe over the = scope of the survivability framework.

[yw>] I think that I can agree with you that there = will not be many situations where a single protection path will be used = for a number of p2mp working paths that all have the same root and = leafs. However, that means that calling this 1:n is unrealistic and = therefore I am not sure that this scenario is very useful.  = However, this makes it even more important for you to clearly define = what the domain that you are addressing is and what are the = requirements.

I = certainly believe that 1:n protection for p2p bidirectional paths is = useful and important and that we should not be causing any confusion by = using the terms without a clear = definition.



 questio= n 2, i think your understanding is right, some leaves which not intended = to receive the packet will receive the packet. may we further consider = the problem in the future.

[yw>] I think it is important to consider the = implications of this before advancing this proposal, both the security = and congestion aspects!



 questio= n 3, i think if there is no LSP/PW identifer TLV in RDI packet, it is = necessary for the root node to bind RDI packet to a special LSP , for = exmaple, it maybe correlate RDI
 to a = special return path. so that the root node can know which working path = has the failure based on the return path;

[yw>] This is very confusing =A8C since there is = no "natural" return path for a p2mp path, since by definition = they are unidirectional paths and any return path would need to be = dependent on some other forwarding method, e.g. IP forwarding, or some = other LSP that is not directly correlated with all of the p2mp LSPs that = emanate from the root node.



 questio= n 4,5,this is end to end protection solution. if the failure happened on = one of the n working path, they must notify the failure message to the = root of protection path. so the root
will select = one failure working path which is the highest priority to be proteced. = it don't require the node of shared protection segment to compare the = priority to select one working path to be protected. so it is different = from the shared mesh protection.

[yw>] So again I think that it is very important = for you to clearly define what the protection domain = is!



what i said = may not be right? thank you

best = regards
liu =




Yaacov = Weingarten <wyaacov@gmail.com> =
=B7=A2=BC=FE=C8=CB:  mpls-bounces@ietf.org =

2012-03-15 = 21:34

mpls@ietf.org, draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org

=CA=D5=BC=FE=C8=CB

=B3=AD=CB=CD

=D6=F7=CC=E2

[mpls] = Comments/Questions about "p2mp shared protection" = draft

 




Hi, authors 

I have read your = draft and find that I have quite a few questions and comments about the = proposals in the draft and the presentation:

1.  You = present two different scenarios for protection of p2mp MPLS-TP traffic, = but you do not really define what the architecture of your protection = domain is.
Taking the first solution, where you propose using a 1:n = protection scheme - normally, and as presented in the Survivability = Framework a 1:n protection domain consists of several working paths and = a single protection path that all have the same set of root and leaves. =  Yet in your figure 3 you show a 1:2 domain that the working paths = have different roots and different sets of leafs!  It would be = helpful, IMO, if you could define what protection domain you are = referencing.

2. In the scenario that you present in figure 3, = your protection path starts at a different root than either working path = (for which I commented above) but what worries me more is that its = destination leafs seem to be the union of the leafs of all of the = working paths.  Doesn't this raise some security and congestion = problems?  For example, let's take the simple case of a single = failure on one of the working paths - by switching over to the = protection path the traffic from this service will be delivered to some = destinations that it was not intended to receive the packets?  In = addition, the sections to this destination are suddenly carrying packets = that are unnecessary and just causing additional traffic on the links! =

3. Both of your solutions are greatly dependent upon the RDI = functionality, and you state that the root will be able to identify the = relevant working transport path based on this information. =  However, the RDI for MPLS-TP is defined as part of the Extension = to BFD and only within the CC messages (it is ignored in the CV message) = that do not include a LSP/PW identifier TLV.  And considering that = p2mp paths in MPLS-TP are unidirectional, I think that you need to = clearly explain how the root receives the RDI and how it correlates this = RDI to a particular LSP.

4. In your solution that is based on = (1:1)^n protection - you state that the root must "compare the = priority among these protection paths..." - but I thought that in = this protection scheme the protection switch is performed within a = single 1:1 domain, so there is nothing for the root to compare to! =  What I believe that you meant is that each shared segment may need = (in the case of multiple faults) to compare the priorities of the = different requests for the shared resources!

5.  Can you = explain the relationship between your proposals and the drafts that are = available for 1:n protection and shared mesh protection (in particular = draft-cheung that is also based on (1:1)^n protection)?  Can you = use the same extensions that are proposed in those drafts?

Thank = you,
Yaacov = Weingarten_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/= mailman/listinfo/mpls

 
--------------------------------------------=
------------
ZTE Information Security Noti=
ce: The information contained in this mail&=
nbsp;is solely property of the sender's org=
anization. This mail communication is confidenti=
al. Recipients named above are obligated to=
 maintain secrecy and are not permitted&nbs=
p;to disclose the contents of this communic=
ation to others.
This email and any files=
 transmitted with it are confidential and&n=
bsp;intended solely for the use of the =
;individual or entity to whom they are =
;addressed. If you have received this email=
 in error please notify the originator =
;of the message. Any views expressed in&nbs=
p;this message are those of the individual&=
nbsp;sender.
This message has been sc=
anned for viruses and Spam by ZTE Anti=
-Spam system.
------_=_NextPart_001_01CD0683.A61EB0D4-- From alvaro.retana@hp.com Fri Mar 16 06:48:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701521F8554; Fri, 16 Mar 2012 06:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul1Wifq1K4Xz; Fri, 16 Mar 2012 06:48:58 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83FC121F8496; Fri, 16 Mar 2012 06:48:58 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 8A177143EC; Fri, 16 Mar 2012 13:48:57 +0000 (UTC) Received: from G1W0394.americas.hpqcorp.net (16.236.31.4) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Mar 2012 13:48:16 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0394.americas.hpqcorp.net ([16.236.31.4]) with mapi; Fri, 16 Mar 2012 13:48:16 +0000 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Fri, 16 Mar 2012 13:48:22 +0000 Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 Thread-Index: Ac0CvOa3qB+3BMszRBOE+ueahMap/gAvQYRg Message-ID: <24646CE17826CF4A8DF71F9856C7E656595E6C142B@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Mar 2012 12:45:55 -0700 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:48:59 -0000 Hi! Because the original work on GTSM (rfc5082) was done in rtgwg, I'm forwardi= ng the mpls WG last call for the draft that defines the GTSM use for LDP. Please make sure you include the mpls WG list on any comments. Thanks! Alvaro. -----Original Message----- From: Loa Andersson Date: Thu, 15 Mar 2012 13:20:28 +0100 To: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-ldp-gtsm@too= ls.ietf.org; rtg-ads@tools.ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 =20 Working Group, (slight change of the subject, please use this one to send lc comments). This is to start a working group last call on draft-ietf-mpls-ldp-gtsm-04. Normally we do two week wg last calls, but since this is across the IETF meeting in Paris we make it a week longer. The working group last call ends eob Friday April 6 2012. Please send comments to the mpls working group mailing list (mpls at ietf.org). /Loa for the MPLS WG co-chairs PS There are nit warnings depending on that draft were published last year and that one of the references has been updated, no need to report that. -- Loa Andersson email: loa.andersson at ericsson.com Sr Strategy and Standards Manager loa at pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From gregory.mirsky@ericsson.com Tue Mar 20 14:40:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31C621E8032 for ; Tue, 20 Mar 2012 14:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH0PRid3J4PX for ; Tue, 20 Mar 2012 14:40:35 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B964821E802B for ; Tue, 20 Mar 2012 14:40:35 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2KLe4uh004972; Tue, 20 Mar 2012 16:40:06 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 20 Mar 2012 17:40:02 -0400 From: Gregory Mirsky To: "ppan@infinera.com" , "rrao@infinera.com" , "blu@infinera.com" , "lufang@cisco.com" , "andrew.g.malis@verizon.com" , "zhangfatai@huawei.com" , "sam.aldrin@huawei.com" , "zhang.fei3@zte.com.cn" , "SriMohanS@Tellabs.com" Date: Tue, 20 Mar 2012 17:40:01 -0400 Thread-Topic: Comments to draft-pan-shared-mesh-protection-04 Thread-Index: Ac0G4gD1SnjNuoAtSECAB1aBIfwDQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135502DE4C7EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comments to draft-pan-shared-mesh-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:40:36 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135502DE4C7EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please find my comments to the latest version below: * Section 3 "All paths are assumed to be bi-directional." Do you make distinction between: * co-routed and associated bi-directional LSP * Coordinated and independent protection mode for associated bi-direc= tional LSP * Section 5.2 "If a sender is not getting the reply within a time int= erval." How this time interval defined, determined. Does it have to be the = same for both head- and tail-end of protecting path? * Section 6.1 "If the headend node is not receiving the acknowledgeme= nt within a time internal ..." Is this the same time interval referenced in= Section 5.2? Is there a default value for it? Perhaps it might be named fo= r ease of reference. Thank you for your kind consideration. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF135502DE4C7EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please find my comments to the latest version below:
  • Section 3 "All paths are assumed to be bi-directional."
    • =
Do you make distinction between:
  • co-routed and associated bi-directional LSP
  • Coordinated and ind= ependent protection mode for associated bi-directional LSP
  • Section 5.2 "If a sender is not getting the reply within a time in= terval." How this time interval defined, determined. Does it have to b= e the same for both head- and tail-end of protecting path?
  • Section = 6.1 "If the headend node is not receiving the acknowledgement within a= time internal …" Is this the same time interval referenced in S= ection 5.2? Is there a default value for it? Perhaps it might be named for = ease of reference.
 
Thank you for your kind consideration.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF135502DE4C7EUSAACMS0715e_-- From liu.guoman@zte.com.cn Tue Mar 20 18:42:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC1021E802C for ; Tue, 20 Mar 2012 18:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtWRkujhL2tF for ; Tue, 20 Mar 2012 18:42:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17821E8045 for ; Tue, 20 Mar 2012 18:42:51 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 52373806486374; Wed, 21 Mar 2012 09:35:00 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84000.3947152229; Wed, 21 Mar 2012 09:42:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2L1gi29076947; Wed, 21 Mar 2012 09:42:44 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Wed, 21 Mar 2012 09:42:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-21 09:42:45, Serialize complete at 2012-03-21 09:42:45 Content-Type: multipart/alternative; boundary="=_alternative 00096E8B482579C8_=" X-MAIL: mse02.zte.com.cn q2L1gi29076947 Cc: mpls@ietf.org, draft-liu-pwe3-mpls-tp-p2mp-shared-protection@tools.ietf.org Subject: [mpls] =?gb2312?b?tPC4tDogUkU6ICBDb21tZW50cy9RdWVzdGlvbnMgYWJv?= =?gb2312?b?dXQgInAybXAgc2hhcmVkIHByb3RlY3Rpb24iIGRyYWZ0?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 01:42:54 -0000 This is a multipart message in MIME format. --=_alternative 00096E8B482579C8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWFhY292LCBoaQ0KaSB0aGluayB5b3VyIGFkdmljZSBpcyB2ZXJ5IGdvb2QsIHdlIHdpbGwgdXBk YXRlIHRoZSBjb250ZXh0IG9mIHRoZSBkcmFmdCANCmluIHRoZSBuZXh0IHZlcnNpb24gYWNjb3Jk aW5nIHRvIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KZm9yIHByb3RlY3Rpb24gZG9t YWluLCBpIHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBjbGVhcmx5IGRlZmluZSB0aGUgDQpkb21h aW4uIElNTywgSSB0aGluayBpdCBtYWlubHkgcmVjb3ZlcnkgdGhlIGZhaWx1cmUgb2Ygc2VnbWVu dCBiZXR3ZWVuDQp0aGUgcm9vdCBub2RlIGFuZCBhbGwgbGVhZiBub2Rlcy4gYnV0IGl0IGNhbid0 IGluY2x1ZGUgdGhlIHByb3RlY3Rpb24gb2YgDQplbmQgbm9kZXMuDQpmb3Igc2VjdXJpdHkgb2Yg dGhlIHByb3RlY3Rpb24gc29sdXRpb24sIG1heWJlIHRoZSBwcm90ZWN0ZWQgc2VydmljZSBvbmx5 IA0KYmUgdHJhbnNwb3J0ZWQgYmV0d2VlbiB0aGUgcm9vdCBub2RlIGFuZCBhbGwgbGVhZiBub2Rl cyBvbiB0aGUgcHJvdGVjdGlvbiANCnBhdGguDQphbmQgc29tZSBsZWFmIG5vZGVzIHdoaWNoIG5l ZWRuJ3QgdG8gcmVjZWl2ZSB0aGUgc2VydmljZSBwYWNrZXQgd2lsbCANCmRpcmVjdGx5IGFiYW5k b24gaXQgYW5kIGNhbid0IHByb3BhZ2F0ZSB0aGUgc2VydmljZSBwYWNrZXQgdG8gb3RoZXIgDQpj dXN0b21lciBuZXR3b3JrLCBzbw0KdGhlIHByb3RlY3Rpb24gc29sdXRpb24gd2lsbCBoYXZlIG5v IHRvbyBtdWNoIGFmZmVjdCBvbiBzZWN1cml0eSBvZiB0aGUgDQpwMm1wIHNlcnZpY2UuIGl0IGlz IG15IHBlcnNvbmFsIG9waW5pb25zLCBkbyB5b3UgdGhpbmsgc28/DQpmb3IgdGhlIGZhaWx1cmUg bm90aWZpY2F0aW9uLCBzaG91bGQgIHRoZSBsZWFmIG5vZGUgbm90aWZ5IHRoZSBmYWlsdXJlIGJ5 IA0KUFNDIHBhY2tldCByZXBsYWNlIG9mIFJEST8gaXMgaXQgbW9yZSByZWFzb25hYmxlID8NCg0K dGhhbmsgeW91LCANCkIuUi4NCmxpdQ0KDQoNCg0KDQoNCg0KIldlaW5nYXJ0ZW4sIFlhYWNvdiAo TlNOIC0gSUwvSG9kIEhhU2hhcm9uKSIgPHlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20+IA0KMjAx Mi0wMy0yMCAxODoyNA0KDQrK1bz+yMsNCjxsaXUuZ3VvbWFuQHp0ZS5jb20uY24+LCAiWWFhY292 IFdlaW5nYXJ0ZW4iIDx3eWFhY292QGdtYWlsLmNvbT4NCrOty80NCjxtcGxzQGlldGYub3JnPiwg DQo8ZHJhZnQtbGl1LXB3ZTMtbXBscy10cC1wMm1wLXNoYXJlZC1wcm90ZWN0aW9uQHRvb2xzLmll dGYub3JnPg0K1vfM4g0KUkU6IFttcGxzXSBDb21tZW50cy9RdWVzdGlvbnMgYWJvdXQgInAybXAg c2hhcmVkIHByb3RlY3Rpb24iIGRyYWZ0DQoNCg0KDQoNCg0KDQpIaSwNCiANClNlZSBteSBjb21t ZW50cyBpbmxpbmUgYmVsb3cNCiANCkJSLA0KeWFhY292DQogDQpGcm9tOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCmV4 dCBsaXUuZ3VvbWFuQHp0ZS5jb20uY24NClNlbnQ6IEZyaWRheSwgTWFyY2ggMTYsIDIwMTIgMTE6 MzMgQU0NClRvOiBZYWFjb3YgV2VpbmdhcnRlbg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IA0KZHJhZnQt bGl1LXB3ZTMtbXBscy10cC1wMm1wLXNoYXJlZC1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIENvbW1lbnRzL1F1ZXN0aW9ucyBhYm91dCAicDJtcCBzaGFyZWQg cHJvdGVjdGlvbiIgDQpkcmFmdA0KIA0KDQpZYWFjb3ajrGhpIA0KdGhhbmsgeW91IGZvciBwcm92 aWRpbmcgYSBsb3Qgb2YgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBmb3IgdGhpcyBkcmFmdC4gDQpx dWVzdGlvbiAxLCBmb3IgdGhlIGFyY2hpdGVjdHVyZSBvZiBwcm90ZWN0aW9uIGRvbWFpbi4gSU1P LCBpdCBpcyB2ZXJ5IA0KcmFyZSBzZW5hcmlvIHRvIHVzZSBvbmUgcHJvdGVjdGlvbiBwYXRoIHRv IHByb3RlY3Qgc2V2ZXJhbCB3b3JraW5nIHBhdGhzIA0Kd2hpY2ggYWxsIGhhdmUgdGhlIHNhbWUg c2V0IG9mIHJvb3QgYW5kIGxlYXZlcy4gaWYgd2UgY29uc2lkZXIgdGhlIA0Kc2NlbmFyaW8gaW4g dGhpcyBkcmFmdCwgbWF5YmUgaXQgdXNlIG9uZSBwcm90ZWN0aW9uIHBhdGggdG8gcHJvdGVjdCAN CnNldmVyYWwgd29ya2luZyBwYXRocyB3aGljaCBuZWVkbid0IGhhdmUgdGhlIHNhbWUgc2V0IG9m IHJvb3QgYW5kIGxlYXZlcy4gDQppIHRoaW5rIG1vcmUgc2VuYXJpb3MgaW4gcmVhbCBuZXR3b3Jr IGJlbG9uZyB0byB0aGUgc2l0dWF0aW9uLiBzbyBpdCBtYXliZSANCm92ZXIgdGhlIHNjb3BlIG9m IHRoZSBzdXJ2aXZhYmlsaXR5IGZyYW1ld29yay4gDQpbeXc+XSBJIHRoaW5rIHRoYXQgSSBjYW4g YWdyZWUgd2l0aCB5b3UgdGhhdCB0aGVyZSB3aWxsIG5vdCBiZSBtYW55IA0Kc2l0dWF0aW9ucyB3 aGVyZSBhIHNpbmdsZSBwcm90ZWN0aW9uIHBhdGggd2lsbCBiZSB1c2VkIGZvciBhIG51bWJlciBv ZiANCnAybXAgd29ya2luZyBwYXRocyB0aGF0IGFsbCBoYXZlIHRoZSBzYW1lIHJvb3QgYW5kIGxl YWZzLiBIb3dldmVyLCB0aGF0IA0KbWVhbnMgdGhhdCBjYWxsaW5nIHRoaXMgMTpuIGlzIHVucmVh bGlzdGljIGFuZCB0aGVyZWZvcmUgSSBhbSBub3Qgc3VyZSANCnRoYXQgdGhpcyBzY2VuYXJpbyBp cyB2ZXJ5IHVzZWZ1bC4gIEhvd2V2ZXIsIHRoaXMgbWFrZXMgaXQgZXZlbiBtb3JlIA0KaW1wb3J0 YW50IGZvciB5b3UgdG8gY2xlYXJseSBkZWZpbmUgd2hhdCB0aGUgZG9tYWluIHRoYXQgeW91IGFy ZSANCmFkZHJlc3NpbmcgaXMgYW5kIHdoYXQgYXJlIHRoZSByZXF1aXJlbWVudHMuIA0KSSBjZXJ0 YWlubHkgYmVsaWV2ZSB0aGF0IDE6biBwcm90ZWN0aW9uIGZvciBwMnAgYmlkaXJlY3Rpb25hbCBw YXRocyBpcyANCnVzZWZ1bCBhbmQgaW1wb3J0YW50IGFuZCB0aGF0IHdlIHNob3VsZCBub3QgYmUg Y2F1c2luZyBhbnkgY29uZnVzaW9uIGJ5IA0KdXNpbmcgdGhlIHRlcm1zIHdpdGhvdXQgYSBjbGVh ciBkZWZpbml0aW9uLg0KDQoNCiBxdWVzdGlvbiAyLCBpIHRoaW5rIHlvdXIgdW5kZXJzdGFuZGlu ZyBpcyByaWdodCwgc29tZSBsZWF2ZXMgd2hpY2ggbm90IA0KaW50ZW5kZWQgdG8gcmVjZWl2ZSB0 aGUgcGFja2V0IHdpbGwgcmVjZWl2ZSB0aGUgcGFja2V0LiBtYXkgd2UgZnVydGhlciANCmNvbnNp ZGVyIHRoZSBwcm9ibGVtIGluIHRoZSBmdXR1cmUuIA0KW3l3Pl0gSSB0aGluayBpdCBpcyBpbXBv cnRhbnQgdG8gY29uc2lkZXIgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGlzIGJlZm9yZSANCmFkdmFu Y2luZyB0aGlzIHByb3Bvc2FsLCBib3RoIHRoZSBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBhc3Bl Y3RzIQ0KDQoNCiBxdWVzdGlvbiAzLCBpIHRoaW5rIGlmIHRoZXJlIGlzIG5vIExTUC9QVyBpZGVu dGlmZXIgVExWIGluIFJESSBwYWNrZXQsIGl0IA0KaXMgbmVjZXNzYXJ5IGZvciB0aGUgcm9vdCBu b2RlIHRvIGJpbmQgUkRJIHBhY2tldCB0byBhIHNwZWNpYWwgTFNQICwgZm9yIA0KZXhtYXBsZSwg aXQgbWF5YmUgY29ycmVsYXRlIFJESSANCiB0byBhIHNwZWNpYWwgcmV0dXJuIHBhdGguIHNvIHRo YXQgdGhlIHJvb3Qgbm9kZSBjYW4ga25vdyB3aGljaCB3b3JraW5nIA0KcGF0aCBoYXMgdGhlIGZh aWx1cmUgYmFzZWQgb24gdGhlIHJldHVybiBwYXRoOw0KW3l3Pl0gVGhpcyBpcyB2ZXJ5IGNvbmZ1 c2luZyCoQyBzaW5jZSB0aGVyZSBpcyBubyAibmF0dXJhbCIgcmV0dXJuIHBhdGggDQpmb3IgYSBw Mm1wIHBhdGgsIHNpbmNlIGJ5IGRlZmluaXRpb24gdGhleSBhcmUgdW5pZGlyZWN0aW9uYWwgcGF0 aHMgYW5kIGFueSANCnJldHVybiBwYXRoIHdvdWxkIG5lZWQgdG8gYmUgZGVwZW5kZW50IG9uIHNv bWUgb3RoZXIgZm9yd2FyZGluZyBtZXRob2QsIA0KZS5nLiBJUCBmb3J3YXJkaW5nLCBvciBzb21l IG90aGVyIExTUCB0aGF0IGlzIG5vdCBkaXJlY3RseSBjb3JyZWxhdGVkIHdpdGggDQphbGwgb2Yg dGhlIHAybXAgTFNQcyB0aGF0IGVtYW5hdGUgZnJvbSB0aGUgcm9vdCBub2RlLg0KDQoNCiBxdWVz dGlvbiA0LDUsdGhpcyBpcyBlbmQgdG8gZW5kIHByb3RlY3Rpb24gc29sdXRpb24uIGlmIHRoZSBm YWlsdXJlIA0KaGFwcGVuZWQgb24gb25lIG9mIHRoZSBuIHdvcmtpbmcgcGF0aCwgdGhleSBtdXN0 IG5vdGlmeSB0aGUgZmFpbHVyZSANCm1lc3NhZ2UgdG8gdGhlIHJvb3Qgb2YgcHJvdGVjdGlvbiBw YXRoLiBzbyB0aGUgcm9vdCANCndpbGwgc2VsZWN0IG9uZSBmYWlsdXJlIHdvcmtpbmcgcGF0aCB3 aGljaCBpcyB0aGUgaGlnaGVzdCBwcmlvcml0eSB0byBiZSANCnByb3RlY2VkLiBpdCBkb24ndCBy ZXF1aXJlIHRoZSBub2RlIG9mIHNoYXJlZCBwcm90ZWN0aW9uIHNlZ21lbnQgdG8gDQpjb21wYXJl IHRoZSBwcmlvcml0eSB0byBzZWxlY3Qgb25lIHdvcmtpbmcgcGF0aCB0byBiZSBwcm90ZWN0ZWQu IHNvIGl0IGlzIA0KZGlmZmVyZW50IGZyb20gdGhlIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24uIA0K W3l3Pl0gU28gYWdhaW4gSSB0aGluayB0aGF0IGl0IGlzIHZlcnkgaW1wb3J0YW50IGZvciB5b3Ug dG8gY2xlYXJseSBkZWZpbmUgDQp3aGF0IHRoZSBwcm90ZWN0aW9uIGRvbWFpbiBpcyENCg0KDQp3 aGF0IGkgc2FpZCBtYXkgbm90IGJlIHJpZ2h0PyB0aGFuayB5b3UgDQoNCmJlc3QgcmVnYXJkcyAN CmxpdSANCg0KDQoNCg0KDQoNCg0KDQpZYWFjb3YgV2VpbmdhcnRlbiA8d3lhYWNvdkBnbWFpbC5j b20+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0wMy0xNSAyMTozNCAN Cg0KDQrK1bz+yMsNCm1wbHNAaWV0Zi5vcmcsIA0KZHJhZnQtbGl1LXB3ZTMtbXBscy10cC1wMm1w LXNoYXJlZC1wcm90ZWN0aW9uQHRvb2xzLmlldGYub3JnIA0Ks63LzQ0KDQrW98ziDQpbbXBsc10g Q29tbWVudHMvUXVlc3Rpb25zIGFib3V0ICJwMm1wIHNoYXJlZCBwcm90ZWN0aW9uIiBkcmFmdA0K IA0KDQoNCg0KDQoNCg0KDQoNCkhpLCBhdXRob3JzIA0KDQpJIGhhdmUgcmVhZCB5b3VyIGRyYWZ0 IGFuZCBmaW5kIHRoYXQgSSBoYXZlIHF1aXRlIGEgZmV3IHF1ZXN0aW9ucyBhbmQgDQpjb21tZW50 cyBhYm91dCB0aGUgcHJvcG9zYWxzIGluIHRoZSBkcmFmdCBhbmQgdGhlIHByZXNlbnRhdGlvbjog DQoNCjEuICBZb3UgcHJlc2VudCB0d28gZGlmZmVyZW50IHNjZW5hcmlvcyBmb3IgcHJvdGVjdGlv biBvZiBwMm1wIE1QTFMtVFAgDQp0cmFmZmljLCBidXQgeW91IGRvIG5vdCByZWFsbHkgZGVmaW5l IHdoYXQgdGhlIGFyY2hpdGVjdHVyZSBvZiB5b3VyIA0KcHJvdGVjdGlvbiBkb21haW4gaXMuIA0K VGFraW5nIHRoZSBmaXJzdCBzb2x1dGlvbiwgd2hlcmUgeW91IHByb3Bvc2UgdXNpbmcgYSAxOm4g cHJvdGVjdGlvbiBzY2hlbWUgDQotIG5vcm1hbGx5LCBhbmQgYXMgcHJlc2VudGVkIGluIHRoZSBT dXJ2aXZhYmlsaXR5IEZyYW1ld29yayBhIDE6biANCnByb3RlY3Rpb24gZG9tYWluIGNvbnNpc3Rz IG9mIHNldmVyYWwgd29ya2luZyBwYXRocyBhbmQgYSBzaW5nbGUgDQpwcm90ZWN0aW9uIHBhdGgg dGhhdCBhbGwgaGF2ZSB0aGUgc2FtZSBzZXQgb2Ygcm9vdCBhbmQgbGVhdmVzLiAgWWV0IGluIA0K eW91ciBmaWd1cmUgMyB5b3Ugc2hvdyBhIDE6MiBkb21haW4gdGhhdCB0aGUgd29ya2luZyBwYXRo cyBoYXZlIGRpZmZlcmVudCANCnJvb3RzIGFuZCBkaWZmZXJlbnQgc2V0cyBvZiBsZWFmcyEgIEl0 IHdvdWxkIGJlIGhlbHBmdWwsIElNTywgaWYgeW91IGNvdWxkIA0KZGVmaW5lIHdoYXQgcHJvdGVj dGlvbiBkb21haW4geW91IGFyZSByZWZlcmVuY2luZy4gDQoNCjIuIEluIHRoZSBzY2VuYXJpbyB0 aGF0IHlvdSBwcmVzZW50IGluIGZpZ3VyZSAzLCB5b3VyIHByb3RlY3Rpb24gcGF0aCANCnN0YXJ0 cyBhdCBhIGRpZmZlcmVudCByb290IHRoYW4gZWl0aGVyIHdvcmtpbmcgcGF0aCAoZm9yIHdoaWNo IEkgY29tbWVudGVkIA0KYWJvdmUpIGJ1dCB3aGF0IHdvcnJpZXMgbWUgbW9yZSBpcyB0aGF0IGl0 cyBkZXN0aW5hdGlvbiBsZWFmcyBzZWVtIHRvIGJlIA0KdGhlIHVuaW9uIG9mIHRoZSBsZWFmcyBv ZiBhbGwgb2YgdGhlIHdvcmtpbmcgcGF0aHMuICBEb2Vzbid0IHRoaXMgcmFpc2UgDQpzb21lIHNl Y3VyaXR5IGFuZCBjb25nZXN0aW9uIHByb2JsZW1zPyAgRm9yIGV4YW1wbGUsIGxldCdzIHRha2Ug dGhlIHNpbXBsZSANCmNhc2Ugb2YgYSBzaW5nbGUgZmFpbHVyZSBvbiBvbmUgb2YgdGhlIHdvcmtp bmcgcGF0aHMgLSBieSBzd2l0Y2hpbmcgb3ZlciANCnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggdGhl IHRyYWZmaWMgZnJvbSB0aGlzIHNlcnZpY2Ugd2lsbCBiZSBkZWxpdmVyZWQgdG8gDQpzb21lIGRl c3RpbmF0aW9ucyB0aGF0IGl0IHdhcyBub3QgaW50ZW5kZWQgdG8gcmVjZWl2ZSB0aGUgcGFja2V0 cz8gIEluIA0KYWRkaXRpb24sIHRoZSBzZWN0aW9ucyB0byB0aGlzIGRlc3RpbmF0aW9uIGFyZSBz dWRkZW5seSBjYXJyeWluZyBwYWNrZXRzIA0KdGhhdCBhcmUgdW5uZWNlc3NhcnkgYW5kIGp1c3Qg Y2F1c2luZyBhZGRpdGlvbmFsIHRyYWZmaWMgb24gdGhlIGxpbmtzISANCg0KMy4gQm90aCBvZiB5 b3VyIHNvbHV0aW9ucyBhcmUgZ3JlYXRseSBkZXBlbmRlbnQgdXBvbiB0aGUgUkRJIA0KZnVuY3Rp b25hbGl0eSwgYW5kIHlvdSBzdGF0ZSB0aGF0IHRoZSByb290IHdpbGwgYmUgYWJsZSB0byBpZGVu dGlmeSB0aGUgDQpyZWxldmFudCB3b3JraW5nIHRyYW5zcG9ydCBwYXRoIGJhc2VkIG9uIHRoaXMg aW5mb3JtYXRpb24uICBIb3dldmVyLCB0aGUgDQpSREkgZm9yIE1QTFMtVFAgaXMgZGVmaW5lZCBh cyBwYXJ0IG9mIHRoZSBFeHRlbnNpb24gdG8gQkZEIGFuZCBvbmx5IHdpdGhpbiANCnRoZSBDQyBt ZXNzYWdlcyAoaXQgaXMgaWdub3JlZCBpbiB0aGUgQ1YgbWVzc2FnZSkgdGhhdCBkbyBub3QgaW5j bHVkZSBhIA0KTFNQL1BXIGlkZW50aWZpZXIgVExWLiAgQW5kIGNvbnNpZGVyaW5nIHRoYXQgcDJt cCBwYXRocyBpbiBNUExTLVRQIGFyZSANCnVuaWRpcmVjdGlvbmFsLCBJIHRoaW5rIHRoYXQgeW91 IG5lZWQgdG8gY2xlYXJseSBleHBsYWluIGhvdyB0aGUgcm9vdCANCnJlY2VpdmVzIHRoZSBSREkg YW5kIGhvdyBpdCBjb3JyZWxhdGVzIHRoaXMgUkRJIHRvIGEgcGFydGljdWxhciBMU1AuIA0KDQo0 LiBJbiB5b3VyIHNvbHV0aW9uIHRoYXQgaXMgYmFzZWQgb24gKDE6MSlebiBwcm90ZWN0aW9uIC0g eW91IHN0YXRlIHRoYXQgDQp0aGUgcm9vdCBtdXN0ICJjb21wYXJlIHRoZSBwcmlvcml0eSBhbW9u ZyB0aGVzZSBwcm90ZWN0aW9uIHBhdGhzLi4uIiAtIGJ1dCANCkkgdGhvdWdodCB0aGF0IGluIHRo aXMgcHJvdGVjdGlvbiBzY2hlbWUgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGlzIA0KcGVyZm9ybWVk IHdpdGhpbiBhIHNpbmdsZSAxOjEgZG9tYWluLCBzbyB0aGVyZSBpcyBub3RoaW5nIGZvciB0aGUg cm9vdCB0byANCmNvbXBhcmUgdG8hICBXaGF0IEkgYmVsaWV2ZSB0aGF0IHlvdSBtZWFudCBpcyB0 aGF0IGVhY2ggc2hhcmVkIHNlZ21lbnQgbWF5IA0KbmVlZCAoaW4gdGhlIGNhc2Ugb2YgbXVsdGlw bGUgZmF1bHRzKSB0byBjb21wYXJlIHRoZSBwcmlvcml0aWVzIG9mIHRoZSANCmRpZmZlcmVudCBy ZXF1ZXN0cyBmb3IgdGhlIHNoYXJlZCByZXNvdXJjZXMhIA0KDQo1LiAgQ2FuIHlvdSBleHBsYWlu IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB5b3VyIHByb3Bvc2FscyBhbmQgdGhlIGRyYWZ0cyAN CnRoYXQgYXJlIGF2YWlsYWJsZSBmb3IgMTpuIHByb3RlY3Rpb24gYW5kIHNoYXJlZCBtZXNoIHBy b3RlY3Rpb24gKGluIA0KcGFydGljdWxhciBkcmFmdC1jaGV1bmcgdGhhdCBpcyBhbHNvIGJhc2Vk IG9uICgxOjEpXm4gcHJvdGVjdGlvbik/ICBDYW4gDQp5b3UgdXNlIHRoZSBzYW1lIGV4dGVuc2lv bnMgdGhhdCBhcmUgcHJvcG9zZWQgaW4gdGhvc2UgZHJhZnRzPyANCg0KVGhhbmsgeW91LCANCllh YWNvdiBXZWluZ2FydGVuX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0 eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIA0KY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0K VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiAN CnRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 00096E8B482579C8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllhYWNvdiwgaGk8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmkgdGhpbmsgeW91ciBhZHZpY2UgaXMg dmVyeSBnb29kLCB3ZQ0Kd2lsbCB1cGRhdGUgdGhlIGNvbnRleHQgb2YgdGhlIGRyYWZ0IGluIHRo ZSBuZXh0IHZlcnNpb24gYWNjb3JkaW5nIHRvIHlvdXINCmNvbW1lbnRzIGFuZCBzdWdnZXN0aW9u cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvciBwcm90ZWN0 aW9uIGRvbWFpbiwgaSB0aGluayBpdCBpcw0KbmVjZXNzYXJ5IHRvIGNsZWFybHkgZGVmaW5lIHRo ZSBkb21haW4uIElNTywgSSB0aGluayBpdCBtYWlubHkgcmVjb3ZlcnkNCnRoZSBmYWlsdXJlIG9m IHNlZ21lbnQgYmV0d2VlbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+dGhlIHJvb3Qgbm9kZSBhbmQgYWxsIGxlYWYgbm9kZXMuIGJ1dA0KaXQgY2FuJ3QgaW5jbHVk ZSB0aGUgcHJvdGVjdGlvbiBvZiBlbmQgbm9kZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5mb3Igc2VjdXJpdHkgb2YgdGhlIHByb3RlY3Rpb24gc29sdXRpb24s DQptYXliZSB0aGUgcHJvdGVjdGVkIHNlcnZpY2Ugb25seSBiZSB0cmFuc3BvcnRlZCBiZXR3ZWVu IHRoZSByb290IG5vZGUgYW5kDQphbGwgbGVhZiBub2RlcyBvbiB0aGUgcHJvdGVjdGlvbiBwYXRo LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIHNvbWUgbGVh ZiBub2RlcyB3aGljaCBuZWVkbid0IHRvDQpyZWNlaXZlIHRoZSBzZXJ2aWNlIHBhY2tldCB3aWxs IGRpcmVjdGx5IGFiYW5kb24gaXQgYW5kIGNhbid0IHByb3BhZ2F0ZQ0KdGhlIHNlcnZpY2UgcGFj a2V0IHRvIG90aGVyIGN1c3RvbWVyIG5ldHdvcmssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj50aGUgcHJvdGVjdGlvbiBzb2x1dGlvbiB3aWxsIGhhdmUgbm8N CnRvbyBtdWNoIGFmZmVjdCBvbiBzZWN1cml0eSBvZiB0aGUgcDJtcCBzZXJ2aWNlLiBpdCBpcyBt eSBwZXJzb25hbCBvcGluaW9ucywNCmRvIHlvdSB0aGluayBzbz88L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZvciB0aGUgZmFpbHVyZSBub3RpZmljYXRpb24sIHNo b3VsZA0KJm5ic3A7dGhlIGxlYWYgbm9kZSBub3RpZnkgdGhlIGZhaWx1cmUgYnkgUFNDIHBhY2tl dCByZXBsYWNlIG9mIFJEST8gaXMNCml0IG1vcmUgcmVhc29uYWJsZSA/PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQp0aGFuayB5b3UsIDxicj4NCkIuUi48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmxpdTwvZm9udD4NCjx0 YWJsZT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1 b3Q7V2VpbmdhcnRlbiwgWWFhY292DQooTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7 eWFhY292LndlaW5nYXJ0ZW5AbnNuLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAzLTIwIDE4OjI0PC9mb250Pg0KPHRkIHdpZHRoPTYz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtsaXUuZ3VvbWFuQHp0ZS5j b20uY24mZ3Q7LCAmcXVvdDtZYWFjb3YNCldlaW5nYXJ0ZW4mcXVvdDsgJmx0O3d5YWFjb3ZAZ21h aWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7LCAmbHQ7 ZHJhZnQtbGl1LXB3ZTMtbXBscy10cC1wMm1wLXNoYXJlZC1wcm90ZWN0aW9uQHRvb2xzLmlldGYu b3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFttcGxzXSBDb21tZW50cy9RdWVzdGlvbnMg YWJvdXQNCiZxdW90O3AybXAgc2hhcmVkIHByb3RlY3Rpb24mcXVvdDsgZHJhZnQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzM2NWY5 MSBmYWNlPSJDb21pYyBTYW5zIE1TIj5IaSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMzNjVmOTEgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMzY1ZjkxIGZhY2U9IkNvbWljIFNhbnMgTVMiPlNlZSBteSBjb21tZW50cyBp bmxpbmUNCmJlbG93PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMzY1ZjkxIGZhY2U9 IkNvbWljIFNhbnMgTVMiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzM2 NWY5MSBmYWNlPSJDb21pYyBTYW5zIE1TIj5CUiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMzNjVmOTEgZmFjZT0iQ29taWMgU2FucyBNUyI+eWFhY292PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMzY1ZjkxIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5leHQgbGl1Lmd1b21hbkB6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IEZyaWRheSwg TWFyY2ggMTYsIDIwMTIgMTE6MzMgQU08Yj48YnI+DQpUbzo8L2I+IFlhYWNvdiBXZWluZ2FydGVu PGI+PGJyPg0KQ2M6PC9iPiBtcGxzQGlldGYub3JnOyBkcmFmdC1saXUtcHdlMy1tcGxzLXRwLXAy bXAtc2hhcmVkLXByb3RlY3Rpb25AdG9vbHMuaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4g UmU6IFttcGxzXSBDb21tZW50cy9RdWVzdGlvbnMgYWJvdXQgJnF1b3Q7cDJtcCBzaGFyZWQgcHJv dGVjdGlvbiZxdW90Ow0KZHJhZnQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CllhYWNvdjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o6w8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5oaTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQp0aGFuayB5b3Ug Zm9yIHByb3ZpZGluZyBhIGxvdCBvZiBjb21tZW50cyBhbmQgcXVlc3Rpb25zIGZvciB0aGlzIGRy YWZ0Lg0KPGJyPg0KcXVlc3Rpb24gMSwgZm9yIHRoZSBhcmNoaXRlY3R1cmUgb2YgcHJvdGVjdGlv biBkb21haW4uIElNTywgaXQgaXMgdmVyeQ0KcmFyZSBzZW5hcmlvIHRvIHVzZSBvbmUgcHJvdGVj dGlvbiBwYXRoIHRvIHByb3RlY3Qgc2V2ZXJhbCB3b3JraW5nIHBhdGhzDQp3aGljaCBhbGwgaGF2 ZSB0aGUgc2FtZSBzZXQgb2Ygcm9vdCBhbmQgbGVhdmVzLiBpZiB3ZSBjb25zaWRlciB0aGUgc2Nl bmFyaW8NCmluIHRoaXMgZHJhZnQsIG1heWJlIGl0IHVzZSBvbmUgcHJvdGVjdGlvbiBwYXRoIHRv IHByb3RlY3Qgc2V2ZXJhbCB3b3JraW5nDQpwYXRocyB3aGljaCBuZWVkbid0IGhhdmUgdGhlIHNh bWUgc2V0IG9mIHJvb3QgYW5kIGxlYXZlcy4gaSB0aGluayBtb3JlDQpzZW5hcmlvcyBpbiByZWFs IG5ldHdvcmsgYmVsb25nIHRvIHRoZSBzaXR1YXRpb24uIHNvIGl0IG1heWJlIG92ZXIgdGhlDQpz Y29wZSBvZiB0aGUgc3Vydml2YWJpbGl0eSBmcmFtZXdvcmsuPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzM2NWY5 MSBmYWNlPSJDb21pYyBTYW5zIE1TIj48Yj48aT5beXcmZ3Q7XSBJIHRoaW5rDQp0aGF0IEkgY2Fu IGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmUgd2lsbCBub3QgYmUgbWFueSBzaXR1YXRpb25zIHdo ZXJlDQphIHNpbmdsZSBwcm90ZWN0aW9uIHBhdGggd2lsbCBiZSB1c2VkIGZvciBhIG51bWJlciBv ZiBwMm1wIHdvcmtpbmcgcGF0aHMNCnRoYXQgYWxsIGhhdmUgdGhlIHNhbWUgcm9vdCBhbmQgbGVh ZnMuIEhvd2V2ZXIsIHRoYXQgbWVhbnMgdGhhdCBjYWxsaW5nDQp0aGlzIDE6biBpcyB1bnJlYWxp c3RpYyBhbmQgdGhlcmVmb3JlIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIHNjZW5hcmlvDQppcyB2 ZXJ5IHVzZWZ1bC4gJm5ic3A7SG93ZXZlciwgdGhpcyBtYWtlcyBpdCBldmVuIG1vcmUgaW1wb3J0 YW50IGZvciB5b3UNCnRvIGNsZWFybHkgZGVmaW5lIHdoYXQgdGhlIGRvbWFpbiB0aGF0IHlvdSBh cmUgYWRkcmVzc2luZyBpcyBhbmQgd2hhdCBhcmUNCnRoZSByZXF1aXJlbWVudHMuIDwvaT48L2I+ PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMzY1ZjkxIGZhY2U9IkNvbWljIFNhbnMg TVMiPjxiPjxpPkkgY2VydGFpbmx5IGJlbGlldmUNCnRoYXQgMTpuIHByb3RlY3Rpb24gZm9yIHAy cCBiaWRpcmVjdGlvbmFsIHBhdGhzIGlzIHVzZWZ1bCBhbmQgaW1wb3J0YW50DQphbmQgdGhhdCB3 ZSBzaG91bGQgbm90IGJlIGNhdXNpbmcgYW55IGNvbmZ1c2lvbiBieSB1c2luZyB0aGUgdGVybXMg d2l0aG91dA0KYSBjbGVhciBkZWZpbml0aW9uLjwvaT48L2I+PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQogcXVlc3Rpb24gMiwgaSB0aGluayB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgcmln aHQsIHNvbWUgbGVhdmVzIHdoaWNoIG5vdA0KaW50ZW5kZWQgdG8gcmVjZWl2ZSB0aGUgcGFja2V0 IHdpbGwgcmVjZWl2ZSB0aGUgcGFja2V0LiBtYXkgd2UgZnVydGhlcg0KY29uc2lkZXIgdGhlIHBy b2JsZW0gaW4gdGhlIGZ1dHVyZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMzY1ZjkxIGZhY2U9IkNvbWljIFNh bnMgTVMiPjxiPjxpPlt5dyZndDtdIEkgdGhpbmsNCml0IGlzIGltcG9ydGFudCB0byBjb25zaWRl ciB0aGUgaW1wbGljYXRpb25zIG9mIHRoaXMgYmVmb3JlIGFkdmFuY2luZyB0aGlzDQpwcm9wb3Nh bCwgYm90aCB0aGUgc2VjdXJpdHkgYW5kIGNvbmdlc3Rpb24gYXNwZWN0cyE8L2k+PC9iPjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIHF1ZXN0aW9uIDMsIGkgdGhpbmsgaWYgdGhlcmUg aXMgbm8gTFNQL1BXIGlkZW50aWZlciBUTFYgaW4gUkRJIHBhY2tldCwNCml0IGlzIG5lY2Vzc2Fy eSBmb3IgdGhlIHJvb3Qgbm9kZSB0byBiaW5kIFJESSBwYWNrZXQgdG8gYSBzcGVjaWFsIExTUCAs DQpmb3IgZXhtYXBsZSwgaXQgbWF5YmUgY29ycmVsYXRlIFJESTwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQogdG8gYSBzcGVjaWFsIHJldHVybiBwYXRoLiBzbyB0aGF0IHRoZSByb290IG5vZGUgY2FuIGtu b3cgd2hpY2ggd29ya2luZw0KcGF0aCBoYXMgdGhlIGZhaWx1cmUgYmFzZWQgb24gdGhlIHJldHVy biBwYXRoOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzM2NWY5MSBmYWNlPSJDb21p YyBTYW5zIE1TIj48Yj48aT5beXcmZ3Q7XSBUaGlzDQppcyB2ZXJ5IGNvbmZ1c2luZyCoQyBzaW5j ZSB0aGVyZSBpcyBubyAmcXVvdDtuYXR1cmFsJnF1b3Q7IHJldHVybiBwYXRoDQpmb3IgYSBwMm1w IHBhdGgsIHNpbmNlIGJ5IGRlZmluaXRpb24gdGhleSBhcmUgdW5pZGlyZWN0aW9uYWwgcGF0aHMg YW5kDQphbnkgcmV0dXJuIHBhdGggd291bGQgbmVlZCB0byBiZSBkZXBlbmRlbnQgb24gc29tZSBv dGhlciBmb3J3YXJkaW5nIG1ldGhvZCwNCmUuZy4gSVAgZm9yd2FyZGluZywgb3Igc29tZSBvdGhl ciBMU1AgdGhhdCBpcyBub3QgZGlyZWN0bHkgY29ycmVsYXRlZCB3aXRoDQphbGwgb2YgdGhlIHAy bXAgTFNQcyB0aGF0IGVtYW5hdGUgZnJvbSB0aGUgcm9vdCBub2RlLjwvaT48L2I+PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogcXVlc3Rpb24gNCw1LHRoaXMgaXMgZW5kIHRvIGVuZCBw cm90ZWN0aW9uIHNvbHV0aW9uLiBpZiB0aGUgZmFpbHVyZSBoYXBwZW5lZA0Kb24gb25lIG9mIHRo ZSBuIHdvcmtpbmcgcGF0aCwgdGhleSBtdXN0IG5vdGlmeSB0aGUgZmFpbHVyZSBtZXNzYWdlIHRv IHRoZQ0Kcm9vdCBvZiBwcm90ZWN0aW9uIHBhdGguIHNvIHRoZSByb290PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCndpbGwgc2VsZWN0IG9uZSBmYWlsdXJlIHdvcmtpbmcgcGF0aCB3aGljaCBpcyB0aGUg aGlnaGVzdCBwcmlvcml0eSB0byBiZQ0KcHJvdGVjZWQuIGl0IGRvbid0IHJlcXVpcmUgdGhlIG5v ZGUgb2Ygc2hhcmVkIHByb3RlY3Rpb24gc2VnbWVudCB0byBjb21wYXJlDQp0aGUgcHJpb3JpdHkg dG8gc2VsZWN0IG9uZSB3b3JraW5nIHBhdGggdG8gYmUgcHJvdGVjdGVkLiBzbyBpdCBpcyBkaWZm ZXJlbnQNCmZyb20gdGhlIHNoYXJlZCBtZXNoIHByb3RlY3Rpb24uPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzM2 NWY5MSBmYWNlPSJDb21pYyBTYW5zIE1TIj48Yj48aT5beXcmZ3Q7XSBTbyBhZ2Fpbg0KSSB0aGlu ayB0aGF0IGl0IGlzIHZlcnkgaW1wb3J0YW50IGZvciB5b3UgdG8gY2xlYXJseSBkZWZpbmUgd2hh dCB0aGUgcHJvdGVjdGlvbg0KZG9tYWluIGlzITwvaT48L2I+PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQp3aGF0IGkgc2FpZCBtYXkgbm90IGJlIHJpZ2h0PyB0aGFuayB5b3U8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KYmVzdCByZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KbGl1 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pg0KPHA+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCB3aWR0aD00OSU+DQo8dGQgd2lkdGg9NTAl PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4N CjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj5ZYWFjb3YgV2VpbmdhcnRlbiAm bHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzp3eWFhY292QGdtYWlsLmNvbT48Zm9udCBzaXpl PTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PGI+PHU+d3lhYWNvdkBnbWFpbC5jb208L3U+PC9i PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48Yj4mZ3Q7PC9iPg0KPC9mb250 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj46ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+ bXBscy1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4yMDEyLTAz LTE1IDIxOjM0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4N Cjx0ZCB3aWR0aD01OSU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTclPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkyJT48YSBocmVmPW1haWx0 bzptcGxzQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5t cGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4sDQo8 L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWxpdS1wd2UzLW1wbHMtdHAtcDJtcC1zaGFyZWQt cHJvdGVjdGlvbkB0b29scy5pZXRmLm9yZyI+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i QXJpYWwiPjx1PmRyYWZ0LWxpdS1wd2UzLW1wbHMtdHAtcDJtcC1zaGFyZWQtcHJvdGVjdGlvbkB0 b29scy5pZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwi PlttcGxzXSBDb21tZW50cy9RdWVzdGlvbnMgYWJvdXQgJnF1b3Q7cDJtcA0Kc2hhcmVkIHByb3Rl Y3Rpb24mcXVvdDsgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQo8YnI+DQpIaSwgYXV0aG9ycyAmbmJzcDs8YnI+DQo8YnI+DQpJIGhhdmUgcmVhZCB5b3Vy IGRyYWZ0IGFuZCBmaW5kIHRoYXQgSSBoYXZlIHF1aXRlIGEgZmV3IHF1ZXN0aW9ucyBhbmQgY29t bWVudHMNCmFib3V0IHRoZSBwcm9wb3NhbHMgaW4gdGhlIGRyYWZ0IGFuZCB0aGUgcHJlc2VudGF0 aW9uOiA8YnI+DQo8YnI+DQoxLiAmbmJzcDtZb3UgcHJlc2VudCB0d28gZGlmZmVyZW50IHNjZW5h cmlvcyBmb3IgcHJvdGVjdGlvbiBvZiBwMm1wIE1QTFMtVFANCnRyYWZmaWMsIGJ1dCB5b3UgZG8g bm90IHJlYWxseSBkZWZpbmUgd2hhdCB0aGUgYXJjaGl0ZWN0dXJlIG9mIHlvdXIgcHJvdGVjdGlv bg0KZG9tYWluIGlzLiA8YnI+DQpUYWtpbmcgdGhlIGZpcnN0IHNvbHV0aW9uLCB3aGVyZSB5b3Ug cHJvcG9zZSB1c2luZyBhIDE6biBwcm90ZWN0aW9uIHNjaGVtZQ0KLSBub3JtYWxseSwgYW5kIGFz IHByZXNlbnRlZCBpbiB0aGUgU3Vydml2YWJpbGl0eSBGcmFtZXdvcmsgYSAxOm4gcHJvdGVjdGlv bg0KZG9tYWluIGNvbnNpc3RzIG9mIHNldmVyYWwgd29ya2luZyBwYXRocyBhbmQgYSBzaW5nbGUg cHJvdGVjdGlvbiBwYXRoIHRoYXQNCmFsbCBoYXZlIHRoZSBzYW1lIHNldCBvZiByb290IGFuZCBs ZWF2ZXMuICZuYnNwO1lldCBpbiB5b3VyIGZpZ3VyZSAzIHlvdQ0Kc2hvdyBhIDE6MiBkb21haW4g dGhhdCB0aGUgd29ya2luZyBwYXRocyBoYXZlIGRpZmZlcmVudCByb290cyBhbmQgZGlmZmVyZW50 DQpzZXRzIG9mIGxlYWZzISAmbmJzcDtJdCB3b3VsZCBiZSBoZWxwZnVsLCBJTU8sIGlmIHlvdSBj b3VsZCBkZWZpbmUgd2hhdA0KcHJvdGVjdGlvbiBkb21haW4geW91IGFyZSByZWZlcmVuY2luZy4g PGJyPg0KPGJyPg0KMi4gSW4gdGhlIHNjZW5hcmlvIHRoYXQgeW91IHByZXNlbnQgaW4gZmlndXJl IDMsIHlvdXIgcHJvdGVjdGlvbiBwYXRoIHN0YXJ0cw0KYXQgYSBkaWZmZXJlbnQgcm9vdCB0aGFu IGVpdGhlciB3b3JraW5nIHBhdGggKGZvciB3aGljaCBJIGNvbW1lbnRlZCBhYm92ZSkNCmJ1dCB3 aGF0IHdvcnJpZXMgbWUgbW9yZSBpcyB0aGF0IGl0cyBkZXN0aW5hdGlvbiBsZWFmcyBzZWVtIHRv IGJlIHRoZSB1bmlvbg0Kb2YgdGhlIGxlYWZzIG9mIGFsbCBvZiB0aGUgd29ya2luZyBwYXRocy4g Jm5ic3A7RG9lc24ndCB0aGlzIHJhaXNlIHNvbWUNCnNlY3VyaXR5IGFuZCBjb25nZXN0aW9uIHBy b2JsZW1zPyAmbmJzcDtGb3IgZXhhbXBsZSwgbGV0J3MgdGFrZSB0aGUgc2ltcGxlDQpjYXNlIG9m IGEgc2luZ2xlIGZhaWx1cmUgb24gb25lIG9mIHRoZSB3b3JraW5nIHBhdGhzIC0gYnkgc3dpdGNo aW5nIG92ZXINCnRvIHRoZSBwcm90ZWN0aW9uIHBhdGggdGhlIHRyYWZmaWMgZnJvbSB0aGlzIHNl cnZpY2Ugd2lsbCBiZSBkZWxpdmVyZWQNCnRvIHNvbWUgZGVzdGluYXRpb25zIHRoYXQgaXQgd2Fz IG5vdCBpbnRlbmRlZCB0byByZWNlaXZlIHRoZSBwYWNrZXRzPyAmbmJzcDtJbg0KYWRkaXRpb24s IHRoZSBzZWN0aW9ucyB0byB0aGlzIGRlc3RpbmF0aW9uIGFyZSBzdWRkZW5seSBjYXJyeWluZyBw YWNrZXRzDQp0aGF0IGFyZSB1bm5lY2Vzc2FyeSBhbmQganVzdCBjYXVzaW5nIGFkZGl0aW9uYWwg dHJhZmZpYyBvbiB0aGUgbGlua3MhDQo8YnI+DQo8YnI+DQozLiBCb3RoIG9mIHlvdXIgc29sdXRp b25zIGFyZSBncmVhdGx5IGRlcGVuZGVudCB1cG9uIHRoZSBSREkgZnVuY3Rpb25hbGl0eSwNCmFu ZCB5b3Ugc3RhdGUgdGhhdCB0aGUgcm9vdCB3aWxsIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlIHJl bGV2YW50IHdvcmtpbmcNCnRyYW5zcG9ydCBwYXRoIGJhc2VkIG9uIHRoaXMgaW5mb3JtYXRpb24u ICZuYnNwO0hvd2V2ZXIsIHRoZSBSREkgZm9yIE1QTFMtVFANCmlzIGRlZmluZWQgYXMgcGFydCBv ZiB0aGUgRXh0ZW5zaW9uIHRvIEJGRCBhbmQgb25seSB3aXRoaW4gdGhlIENDIG1lc3NhZ2VzDQoo aXQgaXMgaWdub3JlZCBpbiB0aGUgQ1YgbWVzc2FnZSkgdGhhdCBkbyBub3QgaW5jbHVkZSBhIExT UC9QVyBpZGVudGlmaWVyDQpUTFYuICZuYnNwO0FuZCBjb25zaWRlcmluZyB0aGF0IHAybXAgcGF0 aHMgaW4gTVBMUy1UUCBhcmUgdW5pZGlyZWN0aW9uYWwsDQpJIHRoaW5rIHRoYXQgeW91IG5lZWQg dG8gY2xlYXJseSBleHBsYWluIGhvdyB0aGUgcm9vdCByZWNlaXZlcyB0aGUgUkRJDQphbmQgaG93 IGl0IGNvcnJlbGF0ZXMgdGhpcyBSREkgdG8gYSBwYXJ0aWN1bGFyIExTUC4gPGJyPg0KPGJyPg0K NC4gSW4geW91ciBzb2x1dGlvbiB0aGF0IGlzIGJhc2VkIG9uICgxOjEpXm4gcHJvdGVjdGlvbiAt IHlvdSBzdGF0ZSB0aGF0DQp0aGUgcm9vdCBtdXN0ICZxdW90O2NvbXBhcmUgdGhlIHByaW9yaXR5 IGFtb25nIHRoZXNlIHByb3RlY3Rpb24gcGF0aHMuLi4mcXVvdDsNCi0gYnV0IEkgdGhvdWdodCB0 aGF0IGluIHRoaXMgcHJvdGVjdGlvbiBzY2hlbWUgdGhlIHByb3RlY3Rpb24gc3dpdGNoIGlzDQpw ZXJmb3JtZWQgd2l0aGluIGEgc2luZ2xlIDE6MSBkb21haW4sIHNvIHRoZXJlIGlzIG5vdGhpbmcg Zm9yIHRoZSByb290DQp0byBjb21wYXJlIHRvISAmbmJzcDtXaGF0IEkgYmVsaWV2ZSB0aGF0IHlv dSBtZWFudCBpcyB0aGF0IGVhY2ggc2hhcmVkDQpzZWdtZW50IG1heSBuZWVkIChpbiB0aGUgY2Fz ZSBvZiBtdWx0aXBsZSBmYXVsdHMpIHRvIGNvbXBhcmUgdGhlIHByaW9yaXRpZXMNCm9mIHRoZSBk aWZmZXJlbnQgcmVxdWVzdHMgZm9yIHRoZSBzaGFyZWQgcmVzb3VyY2VzISA8YnI+DQo8YnI+DQo1 LiAmbmJzcDtDYW4geW91IGV4cGxhaW4gdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHlvdXIgcHJv cG9zYWxzIGFuZCB0aGUNCmRyYWZ0cyB0aGF0IGFyZSBhdmFpbGFibGUgZm9yIDE6biBwcm90ZWN0 aW9uIGFuZCBzaGFyZWQgbWVzaCBwcm90ZWN0aW9uDQooaW4gcGFydGljdWxhciBkcmFmdC1jaGV1 bmcgdGhhdCBpcyBhbHNvIGJhc2VkIG9uICgxOjEpXm4gcHJvdGVjdGlvbik/DQombmJzcDtDYW4g eW91IHVzZSB0aGUgc2FtZSBleHRlbnNpb25zIHRoYXQgYXJlIHByb3Bvc2VkIGluIHRob3NlIGRy YWZ0cz8NCjxicj4NCjxicj4NClRoYW5rIHlvdSwgPGJyPg0KWWFhY292IFdlaW5nYXJ0ZW5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFp bGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5tcGxzQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJy Pg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5a VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUNCmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uDQpUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZA0KdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMNCmNvbW11bmlj YXRpb24gdG8gb3RoZXJzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkDQp3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bA0Kb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluDQplcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkDQppbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz DQphbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+PHBy ZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNw O1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5i c3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5i c3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVu dHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8m bmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJz cDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMu DQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5z bWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7 YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNw O3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYm bmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJz cDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3Jp Z2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3 cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUm bmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4N ClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtm b3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7 QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00096E8B482579C8_=-- From gregory.mirsky@ericsson.com Tue Mar 20 19:22:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3153521E803C for ; Tue, 20 Mar 2012 19:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlrOVuDxcGCK for ; Tue, 20 Mar 2012 19:22:55 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9572521E801A for ; Tue, 20 Mar 2012 19:22:55 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2L2Mr9G031631; Tue, 20 Mar 2012 21:22:54 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 20 Mar 2012 22:22:52 -0400 From: Gregory Mirsky To: "vikashegde@juniper.net" , "csekar@juniper.net" , "mpls@ietf.org" Date: Tue, 20 Mar 2012 22:22:52 -0400 Thread-Topic: Comments to draft-chandra-hegde-mpoint-bfd-for-mpls-00 Thread-Index: Ac0HCYR8sFdBn98zSn6mhnhmjwQ11g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135502DE58AEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-chandra-hegde-mpoint-bfd-for-mpls-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 02:22:56 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135502DE58AEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, You've started very interesting work. Please consider my comments to Sectio= n 4.1: * "Applying the procedures of [RFC5884]to P2MP LSPs, periodic P2MP= LSP Ping echo request messages MUST be sent by the ingress LSR to the egre= ss LSR along the same data path as the P2MP LSP." RFC 5884 does not require use of LSP Ping for bootstrapping but explains, a= s you do in first para of Section 3, that bootstrapping is useful in networ= ks where PHP is allowed and used. I'd note that in MPLS-TP networks PHP is = disabled by default and thus use of LSP Ping to bootstrap BFD session shoul= d not be mandatory. Since your document addresses all of MPLS networks, I'd= propose to change from "MUST" to "MAY" or just "can". * "These echo messages SHOULD contain the local discriminator of the = Multipoint BFD session established by the ingress LSR for the P2MP LSP." RFC 5884 says that LSP Ping MUST carry local discriminator and I propose to= change from "SHOULD" to "MUST" in the sentense above. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF135502DE58AEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors,
You've started very interesting work. Please consider my comments to S= ection 4.1:
  •    "Applying the procedures of [RFC5884]to P2MP LSPs, pe= riodic P2MP LSP Ping echo request messages MUST be sent by the ingress LSR = to the egress LSR along the same data path as the P2MP LSP."
RFC 5884 does not require use of LSP Pi= ng for bootstrapping but explains, as you do in first para of Section 3, th= at bootstrapping is useful in networks where PHP is allowed and used. I'd n= ote that in MPLS-TP networks PHP is disabled by default and thus use of LSP Ping to bootstrap BFD session shoul= d not be mandatory. Since your document addresses all of MPLS networks, I'd= propose to change from "MUST" to "MAY" or just "c= an".
  • "These echo messages SHOULD contain the local discriminator of the= Multipoint BFD session established by the ingress LSR for the P2MP LSP.&qu= ot;
RFC 5884 says that LSP Ping MUST carry = local discriminator and I propose to change from "SHOULD" to &quo= t;MUST" in the sentense above.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF135502DE58AEUSAACMS0715e_-- From gregory.mirsky@ericsson.com Wed Mar 21 07:56:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68721F871E for ; Wed, 21 Mar 2012 07:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KuGXbidtEWk for ; Wed, 21 Mar 2012 07:56:19 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB021F8705 for ; Wed, 21 Mar 2012 07:56:19 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2LEu4Au009507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Mar 2012 09:56:07 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 21 Mar 2012 10:56:04 -0400 From: Gregory Mirsky To: "Huaimochen@huawei.com" , "Ning.So@verizonbusiness.com" , "femi@cisco.com" , "le-liu@kddilabs.jp" Date: Wed, 21 Mar 2012 10:56:02 -0400 Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 Thread-Index: Ac0HcrwrMeiuulkjRAO3D0kFTSjwhw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135502DE6DEEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:56:20 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135502DE6DEEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please find my questions to changes in the latest versions below. On draft-chen-mpls-p2mp-ingress-protection-05 * Introduction "The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair, which is an intermediate node between the ingress node and the egress node of the protected LSP." I think that your definition excludes ingress node as PLR by saying "potent= ial point of local repair, which is an intermediate node ...". In fact, any= node, except for egress LER of course, can be PLR if a detour LSP can be c= reated. * Section 4.1 "The time for switching the traffic after R1 fails is w= ithin tens of milliseconds." I don't see what supports this statement. I th= ink that switchover depends on LOC detection by Ra and internal processing.= The former, BFD interval and DetectMultiplier, i.e. operator selected conf= iguration parameters, would determine only part of switchover performance w= hereas second part is implementation specific and would likely depends on n= umber of streams Ra and R1 share. * Section 4.4 "In the GMPLS networks where the control plane and data plane are physically separated, the detection and localization of failures in the physical layer can be achieved by introducing the link management protocol (LMP) or assisting by performance monitoring devices." I assume you refer to MPLS-TP network in this paragraph. I think that it is= not clear: * on which links you recommend to run LMP or PM * what would constitute failure particularly in case of PM being used * how failure detection will trigger protection switchover * Section 5 "However, there is not any standard that locally protects the ingress of the P2MP LSP. The ingress local protection mechanism described above fills this gap." I think that the document describes redundancy, not ingress protection. On draft-chen-mpls-p2mp-eggress-protection-05: * Introduction "The receiver selects the egress or backup egrss node for receiving the traffic according to the route to the source through RPF. In a normal situation, it selects the egress node. When the egress node fails, it selects the backup egress for receiving the traffic since the route to the source through the egress node is gone and the route to the source through the backup egress node is active." I think that this clearly describes behavior of redundant connection to CE,= 1+1 redundancy. The proposed in the document is nevertheless is based on re= dundant connection of CE. * Same as for Section 4.1 * Same as for Section 4.4 * Same as for Section 5 Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF135502DE6DEEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please find my questions to changes in the latest versions below.
On draft-chen-mpls-p2mp-ingress-protection-05
  • Introduction
   "The first method is a one-to-one backup method, whe= re
   a detour backup P2P LSP for each protected P2P LSP is cre= ated at each
   potential point of local repair, which is an intermediate= node
   between the ingress node and the egress node of the prote= cted LSP."
I think that your definition excludes i= ngress node as PLR by saying "potential point of local repair, which i= s an intermediate node ...". In fact, any node, except for egress LER = of course, can be PLR if a detour LSP can be created.
  • Section 4.1 "The time for switching the traffic after R1 fails is = within tens of milliseconds." I don't see what supports this statement= . I think that switchover depends on LOC detection by Ra and internal proce= ssing. The former, BFD interval and DetectMultiplier, i.e. operator selected configuration parameters, would determine only part = of switchover performance whereas second part is implementation specific an= d would likely depends on number of streams Ra and R1 share.
  • Sectio= n 4.4
   "In the GMPLS networks where the control plane and d= ata plane are
   physically separated, the detection and localization of f= ailures in
   the physical layer can be achieved by introducing the lin= k management
   protocol (LMP) or assisting by performance monitoring dev= ices."
I assume you refer to MPLS-TP network i= n this paragraph. I think that it is not clear:
  • on which links you recommend to run LMP or PM
  • what would consti= tute failure particularly in case of PM being used
  • how failure dete= ction will trigger protection switchover
  • Section 5
   "However, there is not any standard that locally
   protects the ingress of the P2MP LSP.  The ingress l= ocal protection
   mechanism described above fills this gap."
I think that the document describes red= undancy, not ingress protection.
 
On draft-chen-mpls-p2mp-eggress-protection-05:
  • Introduction
   "The receiver selects the egress or backup egrss nod= e for receiving
   the traffic according to the route to the source through = RPF.  In a
   normal situation, it selects the egress node.  When = the egress node
   fails, it selects the backup egress for receiving the tra= ffic since
   the route to the source through the egress node is gone a= nd the route
   to the source through the backup egress node is active.&q= uot;
I think that this clearly describes beh= avior of redundant connection to CE,1+1 redundancy. The proposed in the= document is nevertheless is based on redundant connection of CE.
  • Same as for Section 4.1
  • Same as for Section 4.4
  • Same as= for Section 5
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF135502DE6DEEUSAACMS0715e_-- From vikashegde@juniper.net Wed Mar 21 09:33:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A422421F8532 for ; Wed, 21 Mar 2012 09:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJYn-OcY+2R9 for ; Wed, 21 Mar 2012 09:33:55 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id DD95721F851D for ; Wed, 21 Mar 2012 09:33:54 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT2oC8GavONm6ft0TPFFxTYinqw+SybOM@postini.com; Wed, 21 Mar 2012 09:33:54 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 09:33:50 -0700 Received: from p-emfe02-bng.jnpr.net (10.211.204.20) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 09:33:49 -0700 Received: from EMBX01-BNG.jnpr.net ([fe80::bc40:adfb:bf45:2697]) by p-emfe02-bng.jnpr.net ([::1]) with mapi; Wed, 21 Mar 2012 22:03:47 +0530 From: Vikas Hegde To: Gregory Mirsky , Chandrasekar R , "mpls@ietf.org" Date: Wed, 21 Mar 2012 22:03:46 +0530 Thread-Topic: Comments to draft-chandra-hegde-mpoint-bfd-for-mpls-00 Thread-Index: Ac0HCYR8sFdBn98zSn6mhnhmjwQ11gAdrGqw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments to draft-chandra-hegde-mpoint-bfd-for-mpls-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:33:55 -0000 Hi Gregory, Thanks for your comments! We will incorporate your feedback into the docume= nt. Regards, Vikas From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]=20 Sent: Wednesday, March 21, 2012 7:53 AM To: Vikas Hegde; Chandrasekar R; mpls@ietf.org Subject: Comments to draft-chandra-hegde-mpoint-bfd-for-mpls-00 Dear Authors, You've started very interesting work. Please consider my comments to Sectio= n 4.1: . =A0=A0 "Applying the procedures of [RFC5884]to P2MP LSPs, periodic P2MP L= SP Ping echo request messages MUST be sent by the ingress LSR to the egress= LSR along the same data path as the P2MP LSP." RFC 5884 does not require use of LSP Ping for bootstrapping but explains, a= s you do in first para of Section 3, that bootstrapping is useful in networ= ks where PHP is allowed and used. I'd note that in MPLS-TP networks PHP is = disabled by default and thus use of LSP Ping to bootstrap BFD session shoul= d not be mandatory. Since your document addresses all of MPLS networks, I'd= propose to change from "MUST" to "MAY" or just "can". . "These echo messages SHOULD contain the local discriminator of the Multip= oint BFD session established by the ingress LSR for the P2MP LSP." RFC 5884 says that LSP Ping MUST carry local discriminator and I propose to= change from "SHOULD" to "MUST" in the sentense above. =A0 =A0=A0=A0=A0=A0=A0=A0 Regards, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg =A0 From gregory.mirsky@ericsson.com Wed Mar 21 14:52:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1921E8083; Wed, 21 Mar 2012 14:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GK-MW5DMw2c; Wed, 21 Mar 2012 14:52:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AA86721E8098; Wed, 21 Mar 2012 14:52:04 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2LLpwFR022296; Wed, 21 Mar 2012 16:51:59 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 21 Mar 2012 17:51:53 -0400 From: Gregory Mirsky To: Shahram Davari , "amito@broadcom.com" , "Bhatia, Manav (Manav)" , "peter.roberts@alcatel-lucent.com" , "lmontini@cisco.com" , "'tictoc@ietf.org'" , "mpls@ietf.org" Date: Wed, 21 Mar 2012 17:51:51 -0400 Thread-Topic: Comments to draft-ietf-tictoc-1588overmpls-03 Thread-Index: Ac0HrNLOpEZ57nAmQwuHbG6o3AelSA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments to draft-ietf-tictoc-1588overmpls-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:52:08 -0000 --_004_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_ Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_" --_000_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please find my comments to version -03 (I'll attach it since it has not yet= been submitted) below: * Section 4, Figure 1 is overloaded as several applicable deployment = scenarios merged in one diagram. Perhaps split into several diagrams would = better illustrate possible scenarios. * Section 5 states that PTP LSP between Master Clock and Slave Clock = must be co-routed LSP. How co-routed requirement operationally can be match= ed if LDP or BGP used to signal LSP? * Section 5, last para. I'd note that BFD or any other OAM is not "co= ntrol plane traffic" as it characterized in the text but part of data plane= . Term "user plane traffic" seems ambiguous and perhaps can be replaced by = "data plane client payload" or just "client data". * Section 6 introduces notion of PTP PW. Why PE must be aware of char= acter of Ethernet payload? Shouldn't PW be agnostic of PTP? * Section 6.2 it is not clear why use of PW CW makes "detection of PT= P messages inside the MPLS packet" more robust if and when PW already is tu= nneled over PTP LSP. * Section 16.2 is ambiguous allowing LSR on PTP LSP to violate networ= k layers by concluding on processing decisions of a packet on PTP LSP not b= y terminating LSP but by performing DPI of LSP payload: "When the 1588-capable/aware LSR receives an MPLS packet, it performs a label lookup and if the label lookup indicates it is a PTP label then further parsing must be done to positively identify that the payload is 1588 and not OAM, BFD or control and management. Ruling out non-1588 messages can easily be done when parsing indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the UDP port number does not match one of the 1588 UDP port numbers. After a 1588 message is positively identified in a PTP LSP, the PTP message type indicates whether any timestamp processing is required. After 1588 processing the packet is forwarded as a normal MPLS packet to downstream node." * Section 19 doesn't list case when ingress LER performs Border Clock= function though the case is discussed in Section 4 and reflected, in my in= terpretation, in Figure 1. * Section 19. I think that bullet 3 is identical to bullet 5: "An LER receives MPLS encapsulated PTP messages and terminates them, while = performing the OC or BC functionality." "An LSR receives MPLS encapsulated PTP messages and terminates them, while = performing the OC or BC functionality." Thank you for your consideration. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please find my comments to version -03 (I'll attach it since it has no= t yet been submitted) below:
  • Section 4, Figure 1 is overloaded as several applicable deployment scen= arios merged in one diagram. Perhaps split into several diagrams would bett= er illustrate possible scenarios.
  • Section 5 states that PTP LSP bet= ween Master Clock and Slave Clock must be co-routed LSP. How co-routed requ= irement operationally can be matched if LDP or BGP used to signal LSP?
    • =
  • Section 5, last para. I'd note that BFD or any other OAM is not "c= ontrol plane traffic" as it characterized in the text but part of data= plane. Term "user plane traffic" seems ambiguous and perhaps can= be replaced by "data plane client payload" or just "client data".
  • Section 6 introduces notion of PTP PW. Why= PE must be aware of character of Ethernet payload? Shouldn't PW be agnosti= c of PTP?
  • Section 6.2 it is not clear why use of PW CW makes "= detection of PTP messages inside the MPLS packet" more robust if and w= hen PW already is tunneled over PTP LSP.
  • Section 16.2 is ambiguous = allowing LSR on PTP LSP to violate network layers by concluding on processi= ng decisions of a packet on PTP LSP not by terminating LSP but by performin= g DPI of LSP payload:
"When the 1588-capable/aware LSR r= eceives an MPLS packet,
it performs a label lookup and if the = label lookup indicates it is a PTP
label then further parsing must be don= e to positively identify that the
payload is 1588 and not OAM, BFD or co= ntrol and management.
 
Ruling out non-1588 messages can easil= y be done when parsing
indicates the presence of GAL, ACH or = VCCV (Type 1, 2, 3) or when the
UDP port number does not match one of = the 1588 UDP port numbers.
 
After a 1588 message is positively ide= ntified in a PTP LSP, the PTP
message type indicates whether any tim= estamp processing is required.
After 1588 processing the packet is fo= rwarded as a normal MPLS packet
to downstream node."
  • Section 19 doesn't list case when ingress LER performs Border Clock fun= ction though the case is discussed in Section 4 and reflected, in my interp= retation, in Figure 1.
  • Section 19. I think that bullet 3 is identic= al to bullet 5:
"An LER receives MPLS encapsulated= PTP messages and terminates them, while performing the OC or BC functional= ity."
"An LSR receives MPLS encapsulated= PTP messages and terminates them, while performing the OC or BC functional= ity."
 
Thank you for your consideration.
 
        Regards,
           &nbs= p;    Greg
 
 
 --_000_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_-- --_004_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_ Content-Type: text/plain; name="draft-ietf-tictoc-1588overmpls-03.txt" Content-Description: draft-ietf-tictoc-1588overmpls-03.txt Content-Disposition: attachment; filename="draft-ietf-tictoc-1588overmpls-03.txt"; size=50993; creation-date="Wed, 21 Mar 2012 19:33:32 GMT"; modification-date="Wed, 21 Mar 2012 19:33:35 GMT" Content-Transfer-Encoding: base64 DQoNCg0KVElDVE9DIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUy4gRGF2YXJpDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEuIE9yZW4NCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICBCcm9hZGNvbSBDb3JwLg0K RXhwaXJlczogU2VwdGVtYmVyIDEyLCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gQmhhdGlhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFAuIFJvYmVydHMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsLUx1Y2VudA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM LiBNb250aW5pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMTIsIDIwMTENCg0KDQogICAgICAg ICAgVHJhbnNwb3J0aW5nIFBUUCBtZXNzYWdlcyAoMTU4OCkgb3ZlciBNUExTIE5ldHdvcmtzDQog ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OG92ZXJtcGxzLTAzDQoNCkFi c3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbWV0aG9kIGZvciB0cmFuc3Bv cnRpbmcgUFRQIG1lc3NhZ2VzIChQRFVzKQ0KICAgb3ZlciBhbiBNUExTIG5ldHdvcmsuICBUaGUg bWV0aG9kIGFsbG93cyBmb3IgdGhlIGVhc3kgaWRlbnRpZmljYXRpb24NCiAgIG9mIHRoZXNlIFBE VXMgYXQgdGhlIHBvcnQgbGV2ZWwgdG8gYWxsb3cgZm9yIHBvcnQgbGV2ZWwgcHJvY2Vzc2luZyBv Zg0KICAgdGhlc2UgUERVcyBpbiBib3RoIExFUnMgYW5kIExTUnMuDQoNCiAgIFRoZSBiYXNpYyBp ZGVhIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgaW5zaWRlIGRlZGljYXRlZCBNUExTDQog ICBMU1BzLiAgVGhlc2UgTFNQcyBvbmx5IGNhcnJ5IFBUUCBtZXNzYWdlcyBhbmQgcG9zc2libHkg Q29udHJvbCBhbmQNCiAgIE1hbmFnZW1lbnQgcGFja2V0cywgYnV0IHRoZXkgZG8gbm90IGNhcnJ5 IGN1c3RvbWVyIHRyYWZmaWMuDQoNCiAgIFR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgMTU4 OCBvdmVyIE1QTFMgYXJlIGRlZmluZWQuICBUaGUgZmlyc3QNCiAgIG1ldGhvZCBpcyB0byB0cmFu c3BvcnQgUFRQIG1lc3NhZ2VzIGRpcmVjdGx5IG92ZXIgdGhlIGRlZGljYXRlZCBNUExTDQogICBM U1AgdmlhIFVEUC9JUCBlbmNhcHN1bGF0aW9uLCB3aGljaCBpcyBzdWl0YWJsZSBmb3IgSVAvTVBM UyBuZXR3b3Jrcy4NCiAgIFRoZSBzZWNvbmQgbWV0aG9kIGlzIHRvIHRyYW5zcG9ydCBQVFAgbWVz c2FnZXMgaW5zaWRlIGEgUFcgdmlhDQogICBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uLCB3aGljaCBp cyBtb3JlIHN1aXRhYmxlIGZvciBNUExTLVRQIG5ldHdvcmtzLg0KDQpTdGF0dXMgb2YgdGhpcyBN ZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIFNlcHQgMTIsIDIwMTIuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAx XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJp Z2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhl DQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBk b2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0K ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJp Y3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNClRhYmxl IG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KDQogICAyLiAgVGVybWlub2xvZ3kgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCg0KICAg My4gIFByb2JsZW0gU3RhdGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA4DQoNCiAgIDQuICAxNTg4IG92ZXIgTVBMUyBBcmNoaXRlY3R1cmUgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KDQogICA1LiAgRGVkaWNhdGVkIExTUHMg Zm9yIFBUUCBtZXNzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCg0KICAg Ni4gIDE1ODggb3ZlciBNUExTIEVuY2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDExDQogICAgIDYuMS4gIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNi4yLiAgMTU4OCBvdmVyIFBXIEVu Y2Fwc3VsYXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KDQogICA3LiAg MTU4OCBNZXNzYWdlIFRyYW5zcG9ydCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTQNCg0KICAgOC4gIFByb3RlY3Rpb24gYW5kIFJlZHVuZGFuY3kgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQoNCiAgIDkuICBFQ01QIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KDQogICAxMC4g T0FNLCBDb250cm9sIGFuZCBNYW5hZ2VtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCg0KICAgMTEuIFFvUyBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5DQoNCiAgIDEyLiBGQ1MgUmVjYWxjdWxhdGlvbiAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0KDQogICAxMy4g VURQIENoZWNrc3VtIENvcnJlY3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMjENCg0KICAgMTQuIFJvdXRpbmcgZXh0ZW5zaW9ucyBmb3IgMTU4OGF3YXJlIExTUnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQogICAgIDE0LjEuIDE1ODhhd2FyZSBMaW5rIENh cGFiaWxpdHkgZm9yIE9TUEYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMTQuMi4g MTU4OGF3YXJlIExpbmsgQ2FwYWJpbGl0eSBmb3IgSVMtSVMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyMw0KDQogICAxNS4gUlNWUC1URSBFeHRlbnNpb25zIGZvciBzdXBwb3J0IG9mIDE1ODggLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUNCg0KICAgMTYuIEJlaGF2aW9yIG9mIExFUi9MU1IgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQogICAgIDE2LjEuIEJl aGF2aW9yIG9mIDE1ODgtYXdhcmUgTEVSIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MjYNCiAgICAgMTYuMi4gQmVoYXZpb3Igb2YgMTU4OC1hd2FyZSBMU1IgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyNg0KICAgICAxNi4zLiBCZWhhdmlvciBvZiBub24tMTU4OC1hd2Fy ZSBMU1IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2DQoNCiAgIDE3LiBPdGhlciBjb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyOA0K DQogICAxOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjkNCg0KMTkuIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI5DQoNCiAgIDIwLiBBY2tub3dsZWRnZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMA0KDQog ICAyMS4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzENCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KICAgICAyMS4xLiBJQU5BIENvbnNpZGVyYXRpb25zIGZvciBPU1BGIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDMxDQogICAgIDIxLjIuIElBTkEgQ29uc2lkZXJhdGlvbnMgZm9yIElT LUlTICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzENCiAgICAgMjEuMy4gSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgUlNWUCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQ0KDQog ICAyMi4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzINCiAgICAgMjIuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMg0KICAgICAyMi4yLiBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMyDQoNCiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzNA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAg ICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoN Cg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAg ICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAg IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDMjExOSBb UkZDMjExOV0uDQoNCiAgIFdoZW4gdXNlZCBpbiBsb3dlciBjYXNlLCB0aGVzZSB3b3JkcyBjb252 ZXkgdGhlaXIgdHlwaWNhbCB1c2UgaW4NCiAgIGNvbW1vbiBsYW5ndWFnZSwgYW5kIGFyZSBub3Qg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQogICBSRkMyMTE5IFtSRkMyMTE5XS4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAg IEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMTINCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBvYmplY3RpdmUgb2Yg UHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgKFBUUCkgaXMgdG8gc3luY2hyb25pemUNCiAgIGluZGVw ZW5kZW50IGNsb2NrcyBydW5uaW5nIG9uIHNlcGFyYXRlIG5vZGVzIG9mIGEgZGlzdHJpYnV0ZWQg c3lzdGVtLg0KICAgW0lFRUVdIGRlZmluZXMgUFRQIG1lc3NhZ2VzIGZvciBjbG9jayBhbmQgdGlt ZSBzeW5jaHJvbml6YXRpb24uICBUaGUNCiAgIFBUUCBtZXNzYWdlcyBpbmNsdWRlIFBUUCBQRFVz IG92ZXIgVURQL0lQIChBbm5leCBEIGFuZCBFIG9mIFtJRUVFXSkNCiAgIGFuZCBQVFAgUERVcyBv dmVyIEV0aGVybmV0IChBbm5leCBGIG9mIFtJRUVFXSkuICBUaGlzIGRvY3VtZW50DQogICBkZWZp bmVzIG1hcHBpbmcgYW5kIHRyYW5zcG9ydCBvZiB0aGUgUFRQIG1lc3NhZ2VzIGRlZmluZWQgaW4g W0lFRUVdDQogICBvdmVyIE1QTFMgbmV0d29ya3MuDQoNCiAgIFBUUCBkZWZpbmVzIHNldmVyYWwg Y2xvY2sgdHlwZXM6IG9yZGluYXJ5IGNsb2NrcywgYm91bmRhcnkgY2xvY2tzLA0KICAgZW5kLXRv LWVuZCB0cmFuc3BhcmVudCBjbG9ja3MsIGFuZCBwZWVyLXRvLXBlZXIgdHJhbnNwYXJlbnQgY2xv Y2tzLg0KICAgT25lIGtleSBhdHRyaWJ1dGUgb2YgYWxsIG9mIHRoZXNlIGNsb2NrcyBpcyB0aGUg cmVjb21tZW5kYXRpb24gZm9yDQogICBQVFAgbWVzc2FnZXMgcHJvY2Vzc2luZyB0byBvY2N1ciBh cyBjbG9zZSBhcyBwb3NzaWJsZSB0byB0aGUgYWN0dWFsDQogICB0cmFuc21pc3Npb24gYW5kIHJl Y2VwdGlvbiBhdCB0aGUgcGh5c2ljYWwgcG9ydCBpbnRlcmZhY2UuICBUaGlzDQogICB0YXJnZXRz IG9wdGltYWwgdGltZSBhbmQvb3IgZnJlcXVlbmN5IHJlY292ZXJ5IGJ5IGF2b2lkaW5nIHZhcmlh YmxlDQogICBkZWxheSBpbnRyb2R1Y2VkIGJ5IHF1ZXVlcyBpbnRlcm5hbCB0byB0aGUgY2xvY2tz LiAgVG8gZmFjaWxpdGF0ZSB0aGUNCiAgIGZhc3QgYW5kIGVmZmljaWVudCByZWNvZ25pdGlvbiBv ZiBQVFAgbWVzc2FnZXMgYXQgdGhlIHBvcnQgbGV2ZWwgd2hlbg0KICAgdGhlIFBUUCBtZXNzYWdl cyBhcmUgY2FycmllZCBvdmVyIE1QTFMgTFNQcywgdGhpcyBkb2N1bWVudCBkZWZpbmVzDQogICB0 aGUgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbnMgdGhhdCBzaG91bGQgYmUgdXNlZC4gIEluIGFkZGl0 aW9uLCBpdCBjYW4NCiAgIGJlIGV4cGVjdGVkIHRoYXQgdGhlcmUgd2lsbCBleGlzdCBMU1IvTEVS cyB3aGVyZSBvbmx5IGEgc3Vic2V0IG9mIHRoZQ0KICAgcGh5c2ljYWwgcG9ydHMgd2lsbCBoYXZl IHRoZSBwb3J0IGJhc2VkIFBUUCBtZXNzYWdlIHByb2Nlc3NpbmcNCiAgIGNhcGFiaWxpdGllcy4g IEluIG9yZGVyIHRvIGVuc3VyZSB0aGF0IHRoZSBQVFAgY2FycnlpbmcgTFNQcyBhbHdheXMNCiAg IGVudGVyIGFuZCBleGl0IHBvcnRzIHdpdGggdGhpcyBjYXBhYmlsaXR5LCByb3V0aW5nIGV4dGVu c2lvbnMgYXJlDQogICBkZWZpbmVkIHRvIGFkdmVydGlzZSB0aGlzIGNhcGFiaWxpdHkgb24gYSBw b3J0IGJhc2lzIGFuZCB0byBhbGxvdyBmb3INCiAgIHRoZSBlc3RhYmxpc2htZW50IG9mIExTUHMg dGhhdCBvbmx5IHRyYW5zaXQgc3VjaCBwb3J0cy4gIFdoaWxlIHRoaXMNCiAgIHBhdGggZXN0YWJs aXNobWVudCByZXN0cmljdGlvbiBtYXkgYmUgYXBwbGllZCBvbmx5IGF0IHRoZSBMRVINCiAgIGlu Z3Jlc3MvZWdyZXNzIHBvcnRzLCBpdCBiZWNvbWVzIG1vcmUgaW1wb3J0YW50IHdoZW4gdXNpbmcN CiAgIHRyYW5zcGFyZW50IGNsb2NrIGNhcGFibGUgTFNScyBpbiB0aGUgcGF0aC4NCg0KICAgVGhl IHBvcnQgYmFzZWQgUFRQIG1lc3NhZ2UgcHJvY2Vzc2luZyBpbnZvbHZlcyBQVFAgZXZlbnQgbWVz c2FnZQ0KICAgcmVjb2duaXRpb24uICBPbmNlIHRoZSBQVFAgZXZlbnQgbWVzc2FnZXMgYXJlIHJl Y29nbml6ZWQgdGhleSBjYW4gYmUNCiAgIG1vZGlmaWVkIGJhc2VkIG9uIHRoZSByZWNlcHRpb24g b3IgdHJhbnNtaXNzaW9uIHRpbWVzdGFtcC4gIA0KDQogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IHR3byBtZXRob2RzIGZvciB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXINCiAgIE1QTFMu ICBPbmUgaXMgcHJpbmNpcGFsbHkgZm9jdXNlZCBvbiBhbiBJUC9NUExTIGVudmlyb25tZW50IGFu ZCB0aGUNCiAgIHNlY29uZCBpcyBmb2N1c2VkIG9uIHRoZSBNUExTLVRQIGVudmlyb25tZW50LiBU aGUgc29sdXRpb24gaW52b2x2ZXMgDQogIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMgb3ZlciBk ZWRpY2F0ZWQgTFNQcyBjYWxsZWQgUFRQIExTUHMuIFRoZXNlDQogIExTUHMgY2FycnkgUFRQIG1l c3NhZ2VzIGFuZCBNQVkgY2FycnkgTWFuYWdlbWVudCBhbmQgY29udHJvbCBtZXNzYWdlcywNCiAg YnV0IG5vdCB1c2VyIHRyYWZmaWMuIFBUUCBMU1BzIGNhbiBiZSBlc3RhYmxpc2hlZCBzdGF0aWNh bGx5IG9yIHZpYSANCiAgc2lnbmFsaW5nLiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGV4dGVuc2lv bnMgdG8gT1NQRiwgSVNJUyB0aGF0IGVuYWJsZSANCiAgcm91dGVycyB0byBkaXN0cmlidXRlIHRo ZWlyIDE1ODggb3ZlciBNUExTIGNhcGFiaWxpdHkgdG8gb3RoZXIgcm91dGVycy4gDQogIEl0IGFs c28gcHJvdmlkZXMgZXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGZvciBlc3RhYmxpc2hpbmcgUFRQIExT UHMuIA0KICBFeHRlbnNpb25zIGZvciBCR1AvTERQIFBXIHNpZ25hbGluZyBpcyBmb3IgZnV0dXJl IHN0dWR5IGFuZCBpcyAgDQogIHJlcXVpcmVkIG9ubHkgZm9yIGNhc2VzIHRoYXQgVHVubmVsIExh YmVsIGlzIG5vdCBhdmFpbGFibGUgKGUuZy4gUEhQKS4NCg0KICAgV2hpbGUgdGhlIHRlY2huaXF1 ZXMgaW5jbHVkZWQgaGVyZWluIGFsbG93IGZvciB0aGUgZXN0YWJsaXNobWVudCBvZg0KICAgcGF0 aHMgb3B0aW1pemVkIHRvIGluY2x1ZGUgUFRQIFRpbWUtc3RhbXBpbmcgY2FwYWJsZSBsaW5rcywg dGhlDQogICBwZXJmb3JtYW5jZSBvZiB0aGUgU2xhdmUgY2xvY2tzIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQoyLiAgVGVybWlub2xvZ3kNCg0KICAgMTU4ODogVGhlIHRpbWluZyBhbmQg c3luY2hyb25pemF0aW9uIGFzIGRlZmluZWQgYnkgSUVFRSAxNTg4LTIwMDgNCg0KICAgUFRQOiBU aGUgdGltaW5nIGFuZCBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2wgdXNlZCBieSAxNTg4IChzcGVj aWZpY2FsbHkgUFRQdjIpDQoNCiAgIE1hc3RlciBDbG9jazogVGhlIHNvdXJjZSBvZiAxNTg4IHRp bWluZyB0byBhIHNldCBvZiBzbGF2ZSBjbG9ja3MuDQoNCiAgIE1hc3RlciBQb3J0OiBBIHBvcnQg b24gYSBvcmRpbmFyeSBvciBib3VuZGFyeSBjbG9jayB0aGF0IGlzIGluIE1hc3Rlcg0KICAgc3Rh dGUuICBUaGlzIGlzIHRoZSBzb3VyY2Ugb2YgdGltaW5nIHRvd2FyZCBzbGF2ZSBwb3J0cy4NCg0K ICAgU2xhdmUgQ2xvY2s6IEEgcmVjZWl2ZXIgb2YgMTU4OCB0aW1pbmcgZnJvbSBhIG1hc3RlciBj bG9jay4NCg0KICAgU2xhdmUgUG9ydDogQSBwb3J0IG9uIGEgYm91bmRhcnkgY2xvY2sgb3Igb3Jk aW5hcnkgY2xvY2sgdGhhdCBpcw0KICAgcmVjZWl2aW5nIHRpbWluZyBmcm9tIGEgbWFzdGVyIGNs b2NrLg0KDQogICBPcmRpbmFyeSBDbG9jazogQSBkZXZpY2Ugd2l0aCBhIHNpbmdsZSBQVFAgcG9y dC4NCg0KICAgVHJhbnNwYXJlbnQgQ2xvY2s6ICBBIGRldmljZSB0aGF0IG1lYXN1cmVzIHRoZSB0 aW1lIHRha2VuIGZvciBhIFBUUA0KICAgZXZlbnQgbWVzc2FnZSB0byB0cmFuc2l0IHRoZSBkZXZp Y2UgYW5kIHRoZW4gZWl0aGVyIHVwZGF0ZXMgdGhlDQogICBjb3JyZWN0aW9uIEZpZWxkIG9mIHRo ZSBtZXNzYWdlIHdpdGggdGhpcyB0cmFuc2l0IHRpbWUgKDEtc3RlcCkgb3IgIA0KICAgZ2VuZXJh dGVzIGEgZm9sbG93IHVwIG1lc3NhZ2UgdGhhdCBjb250YWlucyB0aGUgdHJhbnNpdCBkZWxheSAo Mi1TdGVwKS4NCg0KICAgQm91bmRhcnkgQ2xvY2s6IEEgZGV2aWNlIHdpdGggbW9yZSB0aGFuIG9u ZSBQVFAgcG9ydC4gIEdlbmVyYWxseQ0KICAgYm91bmRhcnkgY2xvY2tzIHdpbGwgaGF2ZSBvbmUg cG9ydCBpbiBzbGF2ZSBzdGF0ZSB0byByZWNlaXZlIHRpbWluZw0KICAgYW5kIHRoZSBvdGhlciBw b3J0cyBpbiBtYXN0ZXIgc3RhdGUgdG8gcmUtZGlzdHJpYnV0ZSB0aGUgdGltaW5nLg0KDQogICBQ VFAgTFNQOiBBbiBMU1AgZGVkaWNhdGVkIHRvIGNhcnJ5IFBUUCBtZXNzYWdlcy4NCg0KICAgUFRQ IFBXOiBBIFBXIHdpdGhpbiBhIFBUUCBMU1AgdGhhdCBpcyBkZWRpY2F0ZWQgdG8gY2FycnkgUFRQ DQogICBtZXNzYWdlcy4NCg0KICAgQ1c6IFBzZXVkb3dpcmUgQ29udHJvbCBXb3JkDQoNCg0KICAg RUNNUDogRXF1YWwgQ29zdCBNdWx0aXBhdGgNCg0KICAgQ0Y6IENvcnJlY3Rpb24gRmllbGQsIGEg ZmllbGQgaW5zaWRlIGNlcnRhaW4gUFRQIG1lc3NhZ2VzIChtZXNzYWdlDQogICB0eXBlIDAtMyl0 aGF0IGhvbGRzIHRoZSBhY2N1bXVsYXRpdmUgdHJhbnNpdCB0aW1lIGluc2lkZSBpbnRlcm1lZGlh dGUNCiAgIHN3aXRjaGVzLg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAg ICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCg0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMy4gIFByb2JsZW0gU3RhdGVtZW50DQoNCiAgIElFRUUgMTU4 OC0yMDA4IGhhcyBkZWZpbmVkIG1ldGhvZHMgZm9yIHRyYW5zcG9ydGluZyBQVFAgbWVzc2FnZXMg b3ZlciANCiAgIEV0aGVybmV0IGFuZCBJUCBuZXR3b3Jrcy4gVGhlcmUgaXMgYSBuZWVkIHRvIHRy YW5zcG9ydCBQVFAgbWVzc2FnZXMgDQogICBvdmVyIGFuIE1QTFMgbmV0d29yayB3aGlsZSBzdXBw b3J0aW5nIHRoZSBUcmFuc3BhcmVudCBDbG9jayAoVEMpLCANCiAgIEJvdW5kYXJ5IENsb2NrIChC QykgYW5kIE9yZGluYXJ5IENsb2NrIChPQykgZnVuY3Rpb25hbGl0eSBpbiB0aGUgTEVSIA0KICAg YW5kIExTUnMgaW4gdGhlIE1QTFMgbmV0d29yay4gICANCg0KICAgVGhlcmUgYXJlIG11bHRpcGxl IHdheXMgb2YgdHJhbnNwb3J0aW5nIDE1ODggb3ZlciBNUExTLiBIb3dldmVyLCB0aGVyZQ0KICAg aXMgYSByZXF1aXJlbWVudCB0byBsaW1pdCB0aGUgcG9zc2libGUgZW5jYXBzdWxhdGlvbiBvcHRp b25zIHRvIHNpbXBsaWZ5DQogICB0aGUgUFRQIG1lc3NhZ2UgaWRlbnRpZmljYXRpb24gYW5kIHBy b2Nlc3NpbmcgcmVxdWlyZWQgYXQgdGhlIHBvcnQgbGV2ZWwuICANCg0KICAgVGhlcmUgaXMgYWxz byBhIHJlcXVpcmVtZW50IHRvIHRyYW5zcG9ydCBQVFAgbWVzc2FnZXMgYmVsb25naW5nIHRvIG1h bnkNCiAgIGRpZmZlcmVudCAxNTg4IGRvbWFpbnMgYWNyb3NzIGFuIE1QTFMgbmV0d29yayxzdWNo IGFzIHRoZSBjYXNlIGZvciB3aG9sZQ0KICAgc2FsZSAoY2Fycmllcj9zIGNhcnJpZXIgY2FzZSku DQoNCiAgIFdoZW4gMTU4OC1hd2FyZW5lc3MgaXMgbmVlZGVkLCBQVFAgbWVzc2FnZXMgc2hvdWxk IG5vdCBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBMU1BzIG9yIFBXcyB0aGF0IGFyZSBjYXJyeWlu ZyBjdXN0b21lciB0cmFmZmljIGJlY2F1c2UgTFNScw0KICAgcGVyZm9ybSBMYWJlbCBzd2l0Y2hp bmcgYmFzZWQgb24gdGhlIHRvcCBsYWJlbCBpbiB0aGUgc3RhY2suICBUbw0KICAgZGV0ZWN0IFBU UCBtZXNzYWdlcyBpbnNpZGUgc3VjaCBMU1BzIHJlcXVpcmUgc3BlY2lhbCBoYXJkd2FyZSB0byBk bw0KICAgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiBhdCBsaW5lIHJhdGUuICBFdmVuIGlmIHN1Y2gg aGFyZHdhcmUgZXhpc3RzLA0KICAgdGhlIHBheWxvYWQgY2FuJ3QgYmUgZGV0ZXJtaW5pc3RpY2Fs bHkgaWRlbnRpZmllZCBieSBMU1JzIGJlY2F1c2UgdGhlDQogICBwYXlsb2FkIHR5cGUgaXMgYSBj b250ZXh0IG9mIHRoZSBQVyBsYWJlbCwgYW5kIHRoZSBQVyBsYWJlbCBhbmQgaXRzDQogICBjb250 ZXh0IGFyZSBvbmx5IGtub3duIHRvIHRoZSBFZGdlIHJvdXRlcnMgKFBFcy9MRVJzKTsgTFNScyBk b24ndCBrbm93DQogICB3aGF0IGlzIGEgUFcncyBwYXlsb2FkIChFdGhlcm5ldCwgQVRNLCBGUiwg Q0VTLCBldGMpLiAgRXZlbiBpZiBvbmUNCiAgIHJlc3RyaWN0cyBhbiBMU1AgdG8gb25seSBjYXJy eSBFdGhlcm5ldCBQV3MsIHRoZSBMU1JzIGRvbid0IGhhdmUgdGhlIA0KICAga25vd2xlZGdlIG9m IHdoZXRoZXIgUFcgQ29udHJvbCBXb3JkIChDVykgaXMgcHJlc2VudCBvciBub3QgYW5kIHRoZXJl Zm9yZQ0KICAgY2FuJ3QgZGV0ZXJtaW5pc3RpY2FsbHkgaWRlbnRpZnkgdGhlIHBheWxvYWQuDQoN CiAgIFRoZXJlZm9yZSBhIGdlbmVyaWMgbWV0aG9kIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCB0aGF0IGRvZXMgbm90DQogICByZXF1aXJlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24gYXQgbGlu ZSByYXRlLCBhbmQgY2FuIGRldGVybWluaXN0aWNhbGx5DQogICBpZGVudGlmeSBQVFAgbWVzc2Fn ZXMuICBUaGUgZGVmaW5lZCBtZXRob2QgaXMgYXBwbGljYWJsZSB0byBib3RoIE1QTFMNCiAgIGFu ZCBNUExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K RGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVy IE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjQuICAxNTg4IG92ZXIgTVBM UyBBcmNoaXRlY3R1cmUNCg0KICAgMTU4OCBjb21tdW5pY2F0aW9uIGZsb3dzIG1hcCBvbnRvIE1Q TFMgbm9kZXMgYXMgZm9sbG93czogMTU4OA0KICAgbWVzc2FnZXMgYXJlIGV4Y2hhbmdlIGJldHdl ZW4gUFRQIHBvcnRzIG9uIG9yZGluYXJ5IGFuZCBib3VuZGFyeQ0KICAgY2xvY2tzLiAgVHJhbnNw YXJlbnQgY2xvY2tzIGRvIG5vdCB0ZXJtaW5hdGUgdGhlIFBUUCBtZXNzYWdlcyBidXQNCiAgIHRo ZXkgZG8gbW9kaWZ5IHRoZSBjb250ZW50cyBvZiB0aGUgUFRQIG1lc3NhZ2VzIGFzIHRoZXkgdHJh bnNpdA0KICAgYWNyb3NzIHRoZSB0cmFuc3BhcmVudCBjbG9jay4gIFNvIG9yZGluYXJ5IGFuZCBi b3VuZGFyeSBjbG9ja3Mgd291bGQNCiAgIGV4aXN0IHdpdGhpbiBMRVJzIGFzIHRoZXkgYXJlIHRo ZSB0ZXJtaW5hdGlvbiBwb2ludHMgZm9yIHRoZSBQVFANCiAgIG1lc3NhZ2VzIGNhcnJpZWQgaW4g TVBMUy4gIFRyYW5zcGFyZW50IGNsb2NrcyAob3IgYWx0ZXJuYXRpdmUgdGVjaG5pcXVlKSANCiAg IHdvdWxkIGV4aXN0IHdpdGhpbiBMU1JzIGFzIHRoZXkgZG8gbm90IHRlcm1pbmF0ZSB0aGUgUFRQ IG1lc3NhZ2UgZXhjaGFuZ2UuIA0KICAgVGhlIDE1OCBvdmVyIE1QTFMgQXJjaGl0ZWN0dXJlIGlz IHNob3duIGluIEZpZ3VyZSAxLg0KDQoNCg0KDQorLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAg Ky0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKw0KfCBNYXN0ZXJ8ICAgICB8ICAg ICAgIHwgICAgIHwgICAgICAgfCAgICAgfCAgICAgICB8ICAgICB8IFNsYXZlIHwNCnwgQ2xvY2sg fC0tLS0tfCAgTEVSICB8LS0tLS18ICBMU1IgIHwtLS0tLXwgIExFUiAgfC0tLS0tfCBDbG9jayB8 DQp8ICBPQyAgIHwgICAgIHwgIEJDICAgfCAgICAgfCAgVEMgICB8ICAgICB8ICBCQyAgIHwgICAg IHwgIE9DICAgfA0KKy0tLS0tLS0rICAgICArLS0tLS0tLSsgICAgICstLS0tLS0tKyAgICAgKy0t LS0tLS0rICAgICArLS0tLS0tLSsNCiAgICAgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcDQorLS0tLS0tLSsgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFwgICAgICstLS0tLS0tKw0KfCAgTEVSICB8ICAgIC8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXCAgICB8ICBMRVIgIHwNCnwgTWFzdGVyfC0tLS8gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcLS0tfCBTbGF2ZSB8DQp8IENsb2NrIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgQ2xvY2sgfA0K Ky0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLSsNCg0KRmlndXJlIDEgLSBEZXBsb3ltZW50IGV4YW1wbGVzIG9mIDE1ODggb3ZlciBN UExTIG5ldHdvcmsNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODgg b3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQo1LiAgRGVkaWNhdGVk IExTUHMgZm9yIFBUUCBtZXNzYWdlcw0KDQogICBNYW55IG1ldGhvZHMgd2VyZSBjb25zaWRlcmVk IGZvciBpZGVudGlmeWluZyB0aGUgMTU4OCBtZXNzYWdlcyB3aGVuDQogICB0aGV5IGFyZSBlbmNh cHN1bGF0ZWQgaW4gTVBMUyBzdWNoIGFzIGJ5IHVzaW5nIEdBTC9BQ0ggb3IgYSBuZXcNCiAgIHJl c2VydmVkIGxhYmVsLiAgVGhlc2UgbWV0aG9kcyB3ZXJlIG5vdCBhdHRyYWN0aXZlIHNpbmNlIHRo ZXkgZWl0aGVyDQogICByZXF1aXJlZCBkZWVwIHBhY2tldCBpbnNwZWN0aW9uIGFuZCBzbm9vcGlu ZyBhdCBsaW5lIHJhdGUgb3IgdGhleQ0KICAgcmVxdWlyZWQgdXNlIG9mIGEgc2NhcmNlIG5ldyBy ZXNlcnZlZCBsYWJlbC4gIEFsc28gb25lIG9mIHRoZSBnb2Fscw0KICAgd2FzIHRvIHJldXNlIGV4 aXN0aW5nIE9BTSBhbmQgcHJvdGVjdGlvbiBtZWNoYW5pc21zLg0KDQogICBUaGUgbWV0aG9kIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gYmUgdXNlZCBieSBMRVIvTFNScyB0bw0KICAgaWRl bnRpZnkgUFRQIG1lc3NhZ2VzIGluIE1QTFMgdHVubmVscyBieSB1c2luZyBkZWRpY2F0ZWQgTFNQ cyB0bw0KICAgY2FycnkgUFRQIG1lc3NhZ2VzLg0KDQogICBDb21wbGlhbnQgaW1wbGVtZW50YXRp b25zIE1VU1QgdXNlIGRlZGljYXRlZCBMU1BzIHRvIGNhcnJ5IFBUUA0KICAgbWVzc2FnZXMgb3Zl ciBNUExTLiAgVGhlc2UgTFNQcyBhcmUgaGVyZWluIHJlZmVycmVkIHRvIGFzICJQVFAgTFNQcyIN CiAgIGFuZCB0aGUgbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCB0aGVzZSBMU1BzIGFzICJQVFAgbGFi ZWxzIi4gVGhlIFBUUCBMU1ANCiAgIGJldHdlZW4gYSBNYXN0ZXIgQ2xvY2sgYW5kIGEgU2xhdmUg Q2xvY2sgYW5kIHRoZSBQVFAgTFNQIGJldHdlZW4gdGhlDQogICBzYW1lIFNsYXZlIENsb2NrIGFu ZCBNYXN0ZXIgQ2xvY2sgTVVTVCBiZSBjby1yb3V0ZWQuICBBbHRlcm5hdGl2ZWx5LA0KICAgYSBz aW5nbGUgYmlkaXJlY3Rpb25hbCBjby1yb3V0ZWQgTFNQIGNhbiBiZSB1c2VkLiAgVGhlIFBUUCBM U1AgTUFZIGJlDQogICBNUExTIExTUCBvciBNUExTLVRQIExTUC4gIFRoaXMgY28tcm91dGluZyBp cyByZXF1aXJlZCB0byBsaW1pdA0KICAgZGlmZmVyZW5jZXMgaW4gdGhlIGRlbGF5cyBpbiB0aGUg TWFzdGVyIGNsb2NrIHRvIFNsYXZlIGNsb2NrDQogICBkaXJlY3Rpb24gY29tcGFyZWQgdG8gdGhl IFNsYXZlIGNsb2NrIHRvIE1hc3RlciBjbG9jayBkaXJlY3Rpb24uDQoNCiAgIFRoZSBQVFAgTFNQ cyBjb3VsZCBiZSBjb25maWd1cmVkIG9yIHNpZ25hbGVkIHZpYSBSU1ZQLVRFL0dNUExTLiAgTmV3 DQogICBSU1ZQLVRFL0dNUExTIFRMVnMgYW5kIG9iamVjdHMgYXJlIGRlZmluZWQgaW4gdGhpcyBk b2N1bWVudCB0bw0KICAgaW5kaWNhdGUgdGhhdCB0aGVzZSBMU1BzIGFyZSBQVFAgTFNQcy4NCg0K ICAgVGhlIFBUUCBMU1BzIE1BWSBjYXJyeSBlc3NlbnRpYWwgTVBMUy9NUExTLVRQIGNvbnRyb2wg cGxhbmUgdHJhZmZpYw0KICAgc3VjaCBhcyBCRkQgYW5kIExTUCBQaW5nIGJ1dCB0aGUgTFNQIHVz ZXIgcGxhbmUgdHJhZmZpYyBNVVNUIGJlIFBUUA0KICAgb25seS4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAxMg0KDQoNCjYuICAxNTg4IG92ZXIgTVBMUyBFbmNhcHN1bGF0aW9uDQoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyB0d28gbWV0aG9kcyBmb3IgY2FycnlpbmcgUFRQIG1lc3NhZ2VzIG92ZXIN CiAgIE1QTFMuICBUaGUgZmlyc3QgbWV0aG9kIGlzIGNhcnJ5aW5nIElQIGVuY2Fwc3VsYXRlZCBQ VFAgbWVzc2FnZXMgb3Zlcg0KICAgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBJUC9N UExTIG5ldHdvcmtzIGFuZCB0aGUgc2Vjb25kIG1ldGhvZCwgDQogICBpcyBjYXJyeWluZyBQVFAg bWVzc2FnZXMgb3ZlciBkZWRpY2F0ZWQgRXRoZXJuZXQgUFdzIChjYWxsZWQgUFRQIFBXcykgDQog ICBpbnNpZGUgUFRQIExTUHMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBNUExTIGFuZCBNUExTLVRQ IG5ldHdvcmtzLg0KDQo2LjEuICAxNTg4IG92ZXIgTFNQIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IHNpbXBsZXN0IG1ldGhvZCBvZiB0cmFuc3BvcnRpbmcgUFRQIG1lc3NhZ2VzIG92ZXIgTVBMUyBp cyB0bw0KICAgZW5jYXBzdWxhdGUgUFRQIFBEVXMgaW4gVURQL0lQIGFuZCB0aGVuIGVuY2Fwc3Vs YXRlIHRoZW0gaW4gUFRQIExTUC4NCiAgIFRoZSAxNTg4IG92ZXIgTFNQIGZvcm1hdCBpcyBzaG93 biBpbiBGaWd1cmUgMi4NCg0KDQoNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICB8ICAgUFRQIFR1bm5lbCBMYWJlbCAgIHwNCiAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICBJUHY0LzYgICAgICAgIHwNCiAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICAgVURQICAg ICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICB8 ICAgICAgICBQVFAgUERVICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCg0KICAgRmlndXJlICgyKSAtIDE1ODggb3ZlciBMU1AgRW5jYXBzdWxhdGlvbg0KDQogICBU aGlzIGVuY2Fwc3VsYXRpb24gaXMgdmVyeSBzaW1wbGUgYW5kIGlzIHVzZWZ1bCB3aGVuIHRoZSBu ZXR3b3Jrcw0KICAgYmV0d2VlbiAxNTg4IE1hc3RlciBDbG9jayBhbmQgU2xhdmUgQ2xvY2sgYXJl IElQL01QTFMgbmV0d29ya3MuDQoNCiAgIEluIG9yZGVyIGZvciBhbiBMU1IgdG8gcHJvY2VzcyBQ VFAgbWVzc2FnZXMsIHRoZSBQVFAgTGFiZWwgbXVzdCBiZQ0KICAgdGhlIHRvcCBsYWJlbCBvZiB0 aGUgbGFiZWwgc3RhY2suDQoNCiAgIFRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVT VCBmb2xsb3cgQW5uZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCjYuMi4gIDE1ODggb3ZlciBQVyBF bmNhcHN1bGF0aW9uDQoNCiAgIEFub3RoZXIgbWV0aG9kIG9mIHRyYW5zcG9ydGluZyAxNTg4IG92 ZXIgTVBMUyBuZXR3b3JrcyBpcyBieQ0KICAgZW5jYXBzdWxhdGluZyBQVFAgUERVcyBpbiBFdGhl cm5ldCBhbmQgdGhlbiB0cmFuc3BvcnRpbmcgdGhlbSBvdmVyDQogICBFdGhlcm5ldCBQVyAoUFRQ IFBXKSBhcyBkZWZpbmVkIGluIFtSRkM0NDQ4XSwgd2hpY2ggaW4gdHVybiBpcw0KICAgdHJhbnNw b3J0ZWQgb3ZlciBQVFAgTFNQcy4gIEFsdGVybmF0aXZlbHkgUFRQIFBEVXMgTUFZIGJlDQogICBl bmNhcHN1bGF0ZWQgaW4gVURQL0lQL0V0aGVybmV0IGFuZCB0aGVuIHRyYW5zcG9ydGVkIG92ZXIg RXRoZXJuZXQNCiAgIFBXLg0KDQogICBCb3RoIFJhdyBhbmQgVGFnZ2VkIG1vZGVzIGZvciBFdGhl cm5ldCBQVyBhcmUgcGVybWl0dGVkLiAgVGhlIDE1ODgNCiAgIG92ZXIgUFcgZm9ybWF0IGlzIHNo b3duIGluIEZpZ3VyZSAzLg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNo IDIwMTINCg0KDQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAg ICAgICAgICAgICAgICB8UFRQIFR1bm5lbCBMYWJlbHwNCiAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgIHwgICAgUFcgTGFiZWwgICAgfA0K ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAg ICAgfCAgQ29udHJvbCBXb3JkICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIEV0aGVybmV0ICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgfCAgICAgSGVhZGVyICAgICB8DQogICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICBWTEFOcyAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIElQVjQvVjYgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgICAgVURQICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgfCAgIChvcHRpb25hbCkgICB8DQogICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICB8ICAgIFBU UCBQRFUgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgIEZpZ3VyZSAzIC0gMTU4OCBvdmVyIFBXIEVuY2Fwc3VsYXRpb24NCg0KICAgVGhl IENvbnRyb2wgV29yZCAoQ1cpIGFzIHNwZWNpZmllZCBpbiBbUkZDNDQ0OF0gU0hPVUxEIGJlIHVz ZWQgdG8NCiAgIGVuc3VyZSBhIG1vcmUgcm9idXN0IGRldGVjdGlvbiBvZiBQVFAgbWVzc2FnZXMg aW5zaWRlIHRoZSBNUExTDQogICBwYWNrZXQuICBJZiBDVyBpcyB1c2VkLCB0aGUgdXNlIG9mIFNl cXVlbmNlIE51bWJlciBpcyBvcHRpb25hbC4NCg0KICAgVGhlIHVzZSBvZiBWTEFOIGFuZCBVRFAv SVAgYXJlIG9wdGlvbmFsLiAgTm90ZSB0aGF0IDEgb3IgMiBWTEFOcyBNQVkNCiAgIGV4aXN0IGlu IHRoZSBQVyBwYXlsb2FkLg0KDQogICBJbiBvcmRlciBmb3IgYW4gTFNSIHRvIHByb2Nlc3MgUFRQ IG1lc3NhZ2VzLCB0aGUgdG9wIGxhYmVsIG9mIHRoZQ0KICAgbGFiZWwgc3RhY2sgKHRoZSBUdW5u ZWwgTGFiZWwpIE1VU1QgYmUgYSBQVFAgbGFiZWwuICBIb3dldmVyDQogICBpbiBzb21lIGFwcGxp Y2F0aW9ucyB0aGUgUFcgbGFiZWwgbWF5IGJlIHRoZSB0b3AgbGFiZWwgaW4gdGhlIHN0YWNrLA0K ICAgc3VjaCBhcyBjYXNlcyB3aGVyZSB0aGVyZSBpcyBvbmx5IG9uZS1ob3AgYmV0d2VlbiBQRXMg b3IgaW4gY2FzZSBvZg0KICAgUEhQLiAgSW4gc3VjaCBjYXNlcywgdGhlIFBXIGxhYmVsIFNIT1VM RCBiZSBhIFBUUCBMYWJlbC4NCg0KICAgSW4gb3JkZXIgdG8gZW5zdXJlIGNvbmdydWVuY3kgYmV0 d2VlbiB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgUFRQDQogICBtZXNzYWdlIGZsb3csIEVDTVAgU0hP VUxEIGJlIGF2b2lkZWQgZm9yIHRoZSBQVFAgVHVubmVscy9MU1BzLiAgDQogICBUaGVyZWZvcmUs IEVudHJvcHkgbGFiZWwgW0ktRC5pZXRmLXB3ZTMtZmF0LXB3XSBpcyBub3QgbmVjZXNzYXJ5IA0K ICAgYW5kIGl0IFNIT1VMRCBOT1QgYmUgcHJlc2VudCBpbiB0aGUgc3RhY2suDQoNCiAgIFRoZSBF dGhlcm5ldCBlbmNhcHN1bGF0aW9uIG9mIFBUUCBNVVNUIGZvbGxvdyBBbm5leCBGIG9mIFtJRUVF XSBhbmQNCiAgIHRoZSBVRFAvSVAgZW5jYXBzdWxhdGlvbiBvZiBQVFAgTVVTVCBmb2xsb3cgQW5u ZXggRCBhbmQgRSBvZiBbSUVFRV0uDQoNCiAgIEZvciAxNTg4IG92ZXIgTVBMUyBlbmNhcHN1bGF0 aW9ucyB0aGF0IGFyZSBQVyBiYXNlZCwgdGhlcmUgYXJlIHNvbWUNCiAgIGNhc2VzIGluIHdoaWNo IHRoZSBQVFAgTFNQIGxhYmVsIG1heSBub3QgYmUgcHJlc2VudDoNCg0KDQoNCkRhdmFyaSwgZXQg YWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdl IDEyXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIG8gIFdoZW4gUEhQIGlzIGFwcGxpZWQg dG8gdGhlIFBUUCBMU1AsIHRoZSBmcmFtZSBpcyByZWNlaXZlZA0KICAgICAgYXQgUFcgdGVybWlu YXRpb24gcG9pbnQgd2l0aG91dCBQVFAgTFNQIGxhYmVsOw0KDQogICBvICBXaGVuIHRoZSBQVyBp cyBlc3RhYmxpc2hlZCBiZXR3ZWVuIHR3byByb3V0ZXJzIGRpcmVjdGx5IGNvbm5lY3RlZA0KICAg ICAgdG8gZWFjaCBvdGhlciB0aGUgUFRQIExTUCBpcyBub3QgbmVlZGVkLg0KDQogICBJbiBzdWNo IGNhc2VzIGl0IGlzIHJlcXVpcmVkIGZvciBhIHJvdXRlciB0byBpZGVudGlmeSB0aGVzZSBNUExT IGZyYW1lcyANCiAgIGFzIFBUUCBtZXNzYWdlcy4gIFRoaXMgd291bGQgcmVxdWlyZSB0aGUgUFcg bGFiZWwgdG8gYmUgYSBQVFAgbGFiZWwuDQoNCiAgIFNpbmNlIGJvdGggdGhlIFR1bm5lbCBMYWJl bCBhbmQgUFcgTGFiZWwgbWF5IG5lZWQgdG8gYmUgUFRQIGxhYmVscywgDQogICB0aGVyZSBpcyBh IG5lZWQgdG8gYWRkIGV4dGVuc2lvbiB0byBSU1ZQLVRFIFR1bm5lbCBMYWJlbCBkaXN0cmlidXRp b24sIA0KICAgYXMgd2VsbCBhcyBMRFAvQkdQIFBXIGxhYmVsIGRpc3RyaWJ1dGlvbiBwcm90b2Nv bCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0KICAgVHVubmVsIExhYmVsIGFuZCBQVyBsYWJlbCBhcmUg UFRQIExhYmVscyByZXNwZWN0aXZlbHkuDQoNCiAgIFRoZSBQVyBtZXRob2Qgb2YgdHJhbnNwb3J0 aW5nIFBUUCBvdmVyIE1QTFMgaXMgYXBwbGljYWJsZSB0byBib3RoIElQL01QTFMNCiAgIGFuZCBN UExTLVRQIG5ldHdvcmtzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4 cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1h cmNoIDIwMTINCg0KDQo3LiAgMTU4OCBNZXNzYWdlIFRyYW5zcG9ydA0KDQogICAxNTg4IHByb3Rv Y29sIGNvbXByaXNlcyBvZiB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgdHlwZXM6DQoNCiAgIG8gIEFu bm91bmNlDQoNCiAgIG8gIFNZTkMNCg0KICAgbyAgRk9MTE9XIFVQDQoNCiAgIG8gIERFTEFZX1JF USAoRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgREVMQVlfUkVTUCAoRGVsYXkgUmVzcG9uc2UpDQoN CiAgIG8gIFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JF U1AgKFBlZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIG8gIFBERUxBWV9SRVNQX0ZPTExPV19VUCAo UGVlciBEZWxheSBSZXNwb25zZSBGb2xsb3cgdXApDQoNCiAgIG8gIE1hbmFnZW1lbnQNCg0KICAg byAgU2lnbmFsaW5nDQoNCiAgIEEgc3Vic2V0IG9mIFBUUCBtZXNzYWdlIHR5cGVzIHRoYXQgcmVx dWlyZSB0aW1lc3RhbXAgcHJvY2Vzc2luZyBhcmUNCiAgIGNhbGxlZCBFdmVudCBtZXNzYWdlczoN Cg0KICAgbyAgU1lOQw0KDQogICBvICBERUxBWV9SRVEgKERlbGF5IFJlcXVlc3QpDQoNCiAgIG8g IFBERUxBWV9SRVEgKFBlZXIgRGVsYXkgUmVxdWVzdCkNCg0KICAgbyAgUERFTEFZX1JFU1AgKFBl ZXIgRGVsYXkgUmVzcG9uc2UpDQoNCiAgIFNZTkMgYW5kIERFTEFZX1JFUSBhcmUgZXhjaGFuZ2Vk IGJldHdlZW4gTWFzdGVyIENsb2NrIGFuZCBTbGF2ZSBDbG9jaw0KICAgYW5kIE1VU1QgYmUgdHJh bnNwb3J0ZWQgb3ZlciBQVFAgTFNQcy4gIFBERUxBWV9SRVEgYW5kIFBERUxBWV9SRVNQDQogICBh cmUgZXhjaGFuZ2VkIGJldHdlZW4gYWRqYWNlbnQgUFRQIGNsb2NrcyAoaS5lLiAgb3JkaW5hcnkg aW4gTWFzdGVyIG9yIA0KICAgU2xhdmUgc3RhdGUsIGJvdW5kYXJ5LCBvciB0cmFuc3BhcmVudCBj bG9jaykgYW5kIE1BWSBiZSB0cmFuc3BvcnRlZA0KICAgb3ZlciBzaW5nbGUgaG9wIFBUUCBMU1Bz LiAgDQoNCiAgIEZvciBhIGdpdmVuIGluc3RhbmNlIG9mIDE1ODggcHJvdG9jb2wsIFNZTkMgYW5k IERFTEFZX1JFUSBNVVNUIGJlDQogICB0cmFuc3BvcnRlZCBvdmVyIHR3byBQVFAgTFNQcyB0aGF0 IGFyZSBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zLiAgVGhlc2UNCiAgIFBUUCBMU1BzLCB3aGljaCBh cmUgaW4gb3Bwb3NpdGUgZGlyZWN0aW9ucyBNVVNUIGJlIGNvbmdydWVudCBhbmQgY28tDQogICBy b3V0ZWQuICBBbHRlcm5hdGl2ZWx5LCBhIHNpbmdsZSBiaWRpcmVjdGlvbmFsIGNvLXJvdXRlZCBM U1AgY2FuIGJlDQogICB1c2VkLg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAg ICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCg0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KICBOb24tRXZlbnQgUFRQIG1lc3NhZ2UgdHlwZXMgZG9uJ3QgbmVl ZCB0byBiZSBwcm9jZXNzZWQgYnkgaW50ZXJtZWRpYXRlDQogIHJvdXRlcnMuSG93ZXZlciwgdGhl c2UgbWVzc2FnZSB0eXBlcyBNQVkgYmUgY2FycmllZCBpbiBQVFAgVHVubmVsIExTUHMuDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAg ICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNV0N CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAg ICAgICAgTWFyY2ggMjAxMg0KDQoNCjguICBQcm90ZWN0aW9uIGFuZCBSZWR1bmRhbmN5DQoNCiAg IEluIG9yZGVyIHRvIGVuc3VyZSBjb250aW51b3VzIHVuaW50ZXJydXB0ZWQgb3BlcmF0aW9uIG9m IHNsYXZlIGNsb2NrcywNCiAgIHVzdWFsbHkgYXMgYSBnZW5lcmFsIHByYWN0aWNlLCBzbGF2ZSBj bG9ja3MgKG9yIHBvcnRzKSB0cmFjayByZWR1bmRhbnQgDQogICBtYXN0ZXIgY2xvY2tzLg0KCQ0K ICAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHRvIGVu c3VyZQ0KICAgdGhhdCBwaHlzaWNhbGx5IGRpc2pvaW50IFBUUCB0dW5uZWxzIGFyZSBlc3RhYmxp c2hlZCBiZXR3ZWVuIGEgc2xhdmUgDQogICBjbG9jayBvciBwb3J0IGFuZCByZWR1bmRhbnQgbWFz dGVycyBjbG9ja3Mgb3IgcG9ydHMuDQoNCiAgIFdoZW4gYSBzbGF2ZSBjbG9jayhvciBwb3J0KSBs aXN0ZW4gdG8gcmVkdW5kYW50IG1hc3RlciBjbG9ja3Mgb3IgcG9ydHMsIA0KICAgYW55IHByb2xv bmdlZCBQVFAgTFNQIG9yIFBUUCBQVyBvdXRhZ2Ugd2lsbCB0cmlnZ2VyIHRoZSBzbGF2ZSBjbG9j ayBvcg0KICAgcG9ydCB0byBzd2l0Y2ggdG8gYSByZWR1bmRhbnQgbWFzdGVyIGNsb2NrIG9yIHBv cnQuICBIb3dldmVyIExTUC9QVyANCiAgIHByb3RlY3Rpb24gc3VjaCBhcyBMaW5lYXIgcHJvdGVj dGlvbiBTd2l0Y2hpbmcgKDE6MSwxKzEpLCBSaW5nIA0KICAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcg b3IgTVBMUyBGYXN0IFJlcm91dGUgKEZSUikgU0hPVUxEIHN0aWxsIGJlIHVzZWQNCiAgIHRvIHBy b3ZpZGUgcmVzaWxpZW5jeSB0byBpbmRpdmlkdWFsIG5ldHdvcmsgc2VnbWVudCBmYWlsdXJlcy4N Cg0KICAgTm90ZSB0aGF0IGFueSBwcm90ZWN0aW9uIG9yIHJlcm91dGUgbWVjaGFuaXNtIHRoYXQg YWRkcyBhZGRpdGlvbmFsDQogICBsYWJlbCB0byB0aGUgbGFiZWwgc3RhY2ssIHN1Y2ggYXMgRmFj aWxpdHkgQmFja3VwIEZhc3QgUmVyb3V0ZSwgTVVTVA0KICAgZW5zdXJlIHRoYXQgdGhlIHB1c2hl ZCBsYWJlbCBpcyBhIFBUUCBMYWJlbCB0byBlbnN1cmUgcmVjb2duaXRpb24gb2YNCiAgIHRoZSBN UExTIGZyYW1lIGFzIGNvbnRhaW5pbmcgUFRQIG1lc3NhZ2VzIGFzIGl0IHRyYW5zaXRzIHRoZSBi YWNrdXANCiAgIHBhdGguDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2Vw dCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoN Cg0KOS4gIEVDTVANCg0KICAgVG8gZW5zdXJlIHRoZSBvcHRpbWFsIG9wZXJhdGlvbiBvZiBzbGF2 ZSBjbG9ja3MgYW5kIGF2b2lkIGVycm9ycw0KICAgaW50cm9kdWNlZCBieSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGggZGVsYXkgYXN5bW1ldHJ5LCB0aGUgcGh5c2ljYWwNCiAgIHBhdGggZm9yIFBU UCBtZXNzYWdlcyBmcm9tIG1hc3RlciBjbG9jayB0byBzbGF2ZSBDbG9jayBhbmQgdmljZSB2ZXJz YQ0KICAgbXVzdCBiZSB0aGUgc2FtZSBmb3IgYWxsIFBUUCBtZXNzYWdlcyBsaXN0ZWQgaW4gc2Vj dGlvbiA3IGFuZCBtdXN0DQogICBub3QgY2hhbmdlIGV2ZW4gaW4gdGhlIHByZXNlbmNlIG9mIEVD TVAgaW4gdGhlIE1QTFMgbmV0d29yay4NCg0KICAgVG8gZW5zdXJlIHRoZSBmb3J3YXJkIGFuZCBy ZXZlcnNlIHBhdGhzIGFyZSB0aGUgc2FtZSBQVFAgTFNQcyBhbmQgUFdzDQogICBTSE9VTEQgTk9U IGJlIHN1YmplY3QgdG8gRUNNUC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwg ZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQ YWdlIDE3XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxMC4gIE9BTSwgQ29udHJvbCBhbmQgTWFu YWdlbWVudA0KDQogICBJbiBvcmRlciB0byBtYW5hZ2UgUFRQIExTUHMgYW5kIFBUUCBQV3MsIHRo ZXkgTUFZIGNhcnJ5IE9BTSwgQ29udHJvbA0KICAgYW5kIG1hbmFnZW1lbnQgbWVzc2FnZXMuICBU aGVzZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50IG1lc3NhZ2VzIGNhbg0KICAgYmUgZGlmZmVyZW50 aWF0ZWQgZnJvbSBQVFAgbWVzc2FnZXMgdmlhIGFscmVhZHkgZGVmaW5lZCBJRVRGIG1ldGhvZHMu DQoNCiAgIEluIHBhcnRpY3VsYXIgQkZEIFtSRkM1ODgwXSwgW1JGQzU4ODRdIGFuZCBMU1AtUGlu ZyBbUkZDNDM4OV0gTUFZIHJ1bg0KICAgb3ZlciBQVFAgTFNQcyB2aWEgVURQL0lQIGVuY2Fwc3Vs YXRpb24gb3IgdmlhIEdBTC9HLUFDSC4gIFRoZXNlDQogICBNYW5hZ2VtZW50IHByb3RvY29scyBh cmUgZWFzaWx5IGlkZW50aWZpZWQgYnkgdGhlIFVEUCBEZXN0aW5hdGlvbg0KICAgUG9ydCBudW1i ZXIgb3IgYnkgR0FML0FDSCByZXNwZWN0aXZlbHkuDQoNCiAgIEFsc28gQkZELCBMU1AtUGluZyBh bmQgb3RoZXIgbWFuYWdlbWVudCBtZXNzYWdlcyBNQVkgcnVuIG92ZXIgUFRQIFBXDQogICB2aWEg b25lIG9mIHRoZSBkZWZpbmVkIFZDQ1ZzIChUeXBlIDEsIDIgb3IgMykgW1JGQzUwODVdLiAgSW4g dGhpcw0KICAgY2FzZSBHLUFDSCwgUm91dGVyIEFsZXJ0IExhYmVsIChSQUwpLCBvciBQVyBsYWJl bCAoVFRMPTEpIGFyZSB1c2VkIHRvDQogICBpZGVudGlmeSBzdWNoIG1hbmFnZW1lbnQgbWVzc2Fn ZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBT ZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQoxMS4gIFFvUyBDb25zaWRlcmF0aW9ucw0KDQogICBJbiBuZXR3b3JrIGRlcGxveW1lbnRz IHdoZXJlIG5vdCBldmVyeSBMU1IvTEVSIGlzIFBUUC1hd2FyZSwgdGhlbiBpdA0KICAgaXMgaW1w b3J0YW50IHRvIHJlZHVjZSB0aGUgaW1wYWN0IG9mIHRoZSBub24tUFRQLWF3YXJlIExTUi9MRVJz IG9uDQogICB0aGUgdGltaW5nIHJlY292ZXJ5IGluIHRoZSBzbGF2ZSBjbG9jay4gIFRoZSBQVFAg bWVzc2FnZXMgYXJlIHRpbWUNCiAgIGNyaXRpY2FsIGFuZCBtdXN0IGJlIHRyZWF0ZWQgd2l0aCB0 aGUgaGlnaGVzdCBwcmlvcml0eS4gIFRoZXJlZm9yZQ0KICAgMTU4OCBvdmVyIE1QTFMgbWVzc2Fn ZXMgbXVzdCBiZSB0cmVhdGVkIHdpdGggdGhlIGhpZ2hlc3QgcHJpb3JpdHkgaW4NCiAgIHRoZSBy b3V0ZXJzLiAgVGhpcyBjYW4gYmUgYWNoaWV2ZWQgYnkgcHJvcGVyIHNldHVwIG9mIFBUUCB0dW5u ZWxzLg0KICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgUFRQIExTUHMgYXJlIHNldHVwIGFu ZCBtYXJrZWQgcHJvcGVybHkgdG8NCiAgIGluZGljYXRlIEVGLVBIQiBbUkZDMzI0Nl1mb3IgdGhl IENvUyBhbmQgR3JlZW4gW1JGQzI2OTddIGZvciBkcm9wIA0KICAgZWxpZ2liaWxpdHkuDQoNCiAg IEluIG5ldHdvcmsgZGVwbG95bWVudHMgd2hlcmUgZXZlcnkgTFNSL0xFUiBzdXBwb3J0cyBQVFAg TFNQcywgdGhlbiBpdA0KICAgTUFZIE5PVCBiZSByZXF1aXJlZCB0byBhcHBseSB0aGUgc2FtZSBs ZXZlbCBvZiBwcmlvcml0aXphdGlvbiBhcw0KICAgc3BlY2lmaWVkIGFib3ZlLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEyLiAgRkNT IFJlY2FsY3VsYXRpb24NCg0KICAgRXRoZXJuZXQgRkNTIG9mIHRoZSBvdXRlciBlbmNhcHN1bGF0 aW9uIE1VU1QgYmUgcmVjYWxjdWxhdGVkIGF0IGV2ZXJ5DQogICBMU1IgdGhhdCBwZXJmb3JtcyB0 aGUgdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZyBhbmQgRkNTIHJldGVudGlvbg0KICAgZm9y IHRoZSBwYXlsb2FkIEV0aGVybmV0IGRlc2NyaWJlZCBpbiBbUkZDNDcyMF0gTVVTVCBOT1QgYmUg dXNlZC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy MF0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjEzLiAgVURQIENoZWNrc3VtIENvcnJlY3Rpb24N Cg0KICAgRm9yIFVEUC9JUCBlbmNhcHN1bGF0aW9uIG1vZGUgb2YgMTU4OCBvdmVyIE1QTFMsIHRo ZSBVRFAgY2hlY2tzdW0gaXMNCiAgIG9wdGlvbmFsIHdoZW4gdXNlZCBmb3IgSVB2NCBlbmNhcHN1 bGF0aW9uIGFuZCBtYW5kYXRvcnkgaW4gY2FzZSBvZg0KICAgSVB2Ni4gIFdoZW4gSVB2NHY2IFVE UCBjaGVja3N1bSBpcyB1c2VkLCBlYWNoIDE1ODgtYXdhcmUgTFNSIG11c3QNCiAgIGVpdGhlciBp bmNyZW1lbnRhbGx5IHVwZGF0ZSB0aGUgVURQIGNoZWNrc3VtIGFmdGVyIHRoZSBDRiB1cGRhdGUg b3INCiAgIHZlcmlmeSB0aGUgVURQIGNoZWNrc3VtIG9uIHJlY2VwdGlvbiBmcm9tIHVwc3RyZWFt IGFuZA0KICAgcmVjYWxjdWxhdGUgdGhlIGNoZWNrc3VtIGNvbXBsZXRlbHkgb24gdHJhbnNtaXNz aW9uIGFmdGVyIENGIHVwZGF0ZQ0KICAgdG8gZG93bnN0cmVhbSBub2RlLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAx MiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAyMV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoN CjE0LiAgUm91dGluZyBleHRlbnNpb25zIGZvciAxNTg4LWF3YXJlIExTUnMNCg0KICAgTVBMUy1U RSByb3V0aW5nIHJlbGllcyBvbiBleHRlbnNpb25zIHRvIE9TUEYgW1JGQzIzMjhdIFtSRkM1MzQw XSBhbmQNCiAgIElTLUlTIFtJU09dIFtSRkMxMTk1XSBpbiBvcmRlciB0byBhZHZlcnRpc2UgVHJh ZmZpYyBFbmdpbmVlcmluZyAoVEUpDQogICBsaW5rIGluZm9ybWF0aW9uIHVzZWQgZm9yIGNvbnN0 cmFpbnQtYmFzZWQgcm91dGluZy4NCg0KICAgSW5kZWVkLCBpdCBpcyB1c2VmdWwgdG8gYWR2ZXJ0 aXNlIGRhdGEgcGxhbmUgVEUgcm91dGVyIGxpbmsNCiAgIGNhcGFiaWxpdGllcywgc3VjaCBhcyB0 aGUgY2FwYWJpbGl0eSBmb3IgYSByb3V0ZXIgdG8gYmUgMTU4OC1hd2FyZS4NCiAgIFRoaXMgY2Fw YWJpbGl0eSBNVVNUIHRoZW4gYmUgdGFrZW4gaW50byBhY2NvdW50IGR1cmluZyBwYXRoDQogICBj b21wdXRhdGlvbiB0byBwcmVmZXIgb3IgZXZlbiByZXF1aXJlIGxpbmtzIHRoYXQgYWR2ZXJ0aXNl IHRoZW1zZWx2ZXMNCiAgIGFzIDE1ODgtYXdhcmUuICBJbiB0aGlzIHdheSB0aGUgcGF0aCBjYW4g ZW5zdXJlIHRoZSBlbnRyeSBhbmQgZXhpdA0KICAgcG9pbnRzIGludG8gdGhlIExFUnMgYW5kLCBp ZiBkZXNpcmVkLCB0aGUgbGlua3MgaW50byB0aGUgTFNScyBhcmUNCiAgIGFibGUgdG8gcGVyZm9y bSBwb3J0IGJhc2VkIHRpbWVzLXRhbXBpbmcgdGh1cyBtaW5pbWl6aW5nIHRoZWlyIGltcGFjdA0K ICAgb24gdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBzbGF2ZSBjbG9jay4NCg0KICAgRm9yIHRoaXMg cHVycG9zZSwgdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBzcGVjaWZ5IGV4dGVuc2lvbnMgdG8gT1NQ Rg0KICAgYW5kIElTLUlTIGluIG9yZGVyIHRvIGFkdmVydGlzZSAxNTg4IGF3YXJlIGNhcGFiaWxp dGllcyBvZiBhIGxpbmsuDQoNCjE0LjEuICAxNTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBP U1BGDQoNCiAgIE9TUEYgdXNlcyB0aGUgTGluayBUTFYgKFR5cGUgMikgdGhhdCBpcyBpdHNlbGYg Y2FycmllZCB3aXRoaW4gZWl0aGVyDQogICB0aGUgVHJhZmZpYyBFbmdpbmVlcmluZyBMU0Egc3Bl Y2lmaWVkIGluIFtSRkMzNjMwXSBvciB0aGUgT1NQRnYzDQogICBJbnRyYS1BcmVhLVRFIExTQSAo ZnVuY3Rpb24gY29kZSAxMCkgZGVmaW5lZCBpbiBbUkZDNTMyOV0gdG8NCiAgIGFkdmVydGlzZSB0 aGUgVEUgcmVsYXRlZCBpbmZvcm1hdGlvbiBmb3IgdGhlIGxvY2FsbHkgYXR0YWNoZWQgcm91dGVy DQogICBsaW5rcy4gIEZvciBhbiBMU0EgVHlwZSAxMCwgb25lIExTQSBjYW4gY29udGFpbiBvbmUg TGluayBUTFYNCiAgIGluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsaW5rLiAgVGhpcyBleHRlbnNp b24gZGVmaW5lcyBhIG5ldyAxNTg4LQ0KICAgYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIHRoYXQg Y2FuIGJlIGNhcnJpZWQgYXMgcGFydCBvZiB0aGUgTGluayBUTFYuDQoNCiAgIFRoZSAxNTg4LWF3 YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBPUFRJT05BTCBhbmQgTVVTVCBOT1QgYXBwZWFyDQog ICBtb3JlIHRoYW4gb25jZSB3aXRoaW4gdGhlIExpbmsgVExWLiAgSWYgYSBzZWNvbmQgaW5zdGFu Y2Ugb2YgdGhlDQogICAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLVRMViBpcyBwcmVzZW50LCB0 aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUDQogICBvbmx5IHByb2Nlc3MgdGhlIGZpcnN0IGluc3Rh bmNlIG9mIHRoZSBzdWItVExWLiAgSXQgaXMgZGVmaW5lZCBhcw0KICAgZm9sbG93czoNCg0KICAg ICAgMCAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgIHwgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAgIEZsYWdzICAgICB8DQogICAgICArLSstKy0rLSst Ky0rLSstKw0KDQogICAgICAgICAgICAgICAgRmlndXJlIDM6IDE1ODgtYXdhcmUgQ2FwYWJpbGl0 eSBUTFYNCg0KDQogICBXaGVyZToNCg0KICAgVHlwZSwgMTYgYml0czogMTU4OC1hd2FyZSBDYXBh YmlsaXR5IFRMViB3aGVyZSB0aGUgdmFsdWUgaXMgVEJEDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwu ICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDIy XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAg ICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KICAgTGVuZ3RoLCAxNiBiaXRzOiBHaXZlcyB0aGUg bGVuZ3RoIG9mIHRoZSBmbGFncyBmaWVsZCBpbiBvY3RldHMsIGFuZA0KICAgaXMgY3VycmVudGx5 IHNldCB0byAxDQoNCiAgIEZsYWdzLCA4IGJpdHM6IFRoZSBiaXRzIGFyZSBkZWZpbmVkIGxlYXN0 LXNpZ25pZmljYW50LWJpdCAoTFNCKQ0KICAgZmlyc3QsIHNvIGJpdCA3IGlzIHRoZSBsZWFzdCBz aWduaWZpY2FudCBiaXQgb2YgdGhlIGZsYWdzIG9jdGV0Lg0KDQoNCiAgICAgICAwIDEgMiAzIDQg NSA2IDcNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgUmVzZXJ2ZWQgIHxDfA0K ICAgICAgKy0rLSstKy0rLSstKy0rLSsNCg0KICAgICBGaWd1cmUgNDogRmxhZ3MgRm9ybWF0DQoN Cg0KICAgQ29ycmVjdGlvbiAoQykgZmllbGQgVXBkYXRlIGZpZWxkLCAxIGJpdDogU2V0dGluZyB0 aGUgQyBiaXQgdG8gMQ0KICAgaW5kaWNhdGVzIHRoYXQgdGhlIGxpbmsgaXMgY2FwYWJsZSBvZiBy ZWNvZ25pemluZyB0aGUgUFRQIGV2ZW50DQogICBwYWNrZXRzIGFuZCBjYW4gY29tcGVuc2F0ZSBm b3IgcmVzaWRlbmNlIHRpbWUgYnkgdXBkYXRpbmcgdGhlIFBUUA0KICAgcGFja2V0IENvcnJlY3Rp b24gRmllbGQuICBXaGVuIHRoaXMgaXMgc2V0IHRvIDAsIGl0IG1lYW5zIHRoYXQgdGhpcw0KICAg bGluayBjYW5ub3QgcGVyZm9ybSB0aGUgcmVzaWRlbmNlIHRpbWUgY29ycmVjdGlvbiBidXQgaXMg Y2FwYWJsZSBvZg0KICAgcGVyZm9ybWluZyBNUExTIGZyYW1lIGZvcndhcmRpbmcgb2YgdGhlIGZy YW1lcyB3aXRoIFBUUCBsYWJlbHMgdXNpbmcNCiAgIGEgbWV0aG9kIHRoYXQgc3VwcG9ydCB0aGUg ZW5kIHRvIGVuZCBkZWxpdmVyeSBvZiBhY2N1cmF0ZSB0aW1pbmcuDQogICBUaGUgZXhhY3QgbWV0 aG9kIGlzIG5vdCBkZWZpbmVkIGhlcmVpbi4NCg0KICAgUmVzZXJ2ZWQsIDcgYml0czogUmVzZXJ2 ZWQgZm9yIGZ1dHVyZSB1c2UuICBUaGUgcmVzZXJ2ZWQgYml0cyBtdXN0IGJlDQogICBpZ25vcmVk IGJ5IHRoZSByZWNlaXZlci4NCg0KICAgVGhlIDE1ODgtYXdhcmUgQ2FwYWJpbGl0eSBzdWItVExW IGlzIGFwcGxpY2FibGUgdG8gYm90aCBPU1BGdjIgYW5kDQogICBPU1BGdjMuDQoNCjE0LjIuICAx NTg4YXdhcmUgTGluayBDYXBhYmlsaXR5IGZvciBJUy1JUw0KDQogICBUaGUgSVMtSVMgVHJhZmZp YyBFbmdpbmVlcmluZyBbUkZDMzc4NF0gZGVmaW5lcyB0aGUgaW50cmEtYXJlYQ0KICAgdHJhZmZp YyBlbmdpbmVlcmluZyBlbmhhbmNlbWVudHMgYW5kIHVzZXMgdGhlIEV4dGVuZGVkIElTDQogICBS ZWFjaGFiaWxpdHkgVExWIChUeXBlIDIyKSBbUkZDNTMwNV0gdG8gY2FycnkgdGhlIHBlciBsaW5r IFRFLXJlbGF0ZWQNCiAgIGluZm9ybWF0aW9uLiAgVGhpcyBleHRlbnNpb24gZGVmaW5lcyBhIG5l dyAxNTg4LWF3YXJlIGNhcGFiaWxpdHkgc3ViLQ0KICAgVExWIHRoYXQgY2FuIGJlIGNhcnJpZWQg YXMgcGFydCBvZiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5IFRMVi4NCg0KICAgVGhlIDE1 ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGlzIE9QVElPTkFMIGFuZCBNVVNUIE5PVCBhcHBl YXINCiAgIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiB0aGUgRXh0ZW5kZWQgSVMgUmVhY2hhYmlsaXR5 IFRMViBvciB0aGUgTXVsdGktDQogICBUb3BvbG9neSAoTVQpIEludGVybWVkaWF0ZSBTeXN0ZW1z IFRMViAodHlwZSAyMjIpIHNwZWNpZmllZCBpbg0KICAgW1JGQzUxMjBdLiAgSWYgYSBzZWNvbmQg aW5zdGFuY2Ugb2YgdGhlIDE1ODgtYXdhcmUgY2FwYWJpbGl0eSBzdWItVExWDQogICBpcyBwcmVz ZW50LCB0aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNUIG9ubHkgcHJvY2VzcyB0aGUgZmlyc3QgaW5z dGFuY2UNCiAgIG9mIHRoZSBzdWItVExWLg0KDQogICBUaGUgZm9ybWF0IG9mIHRoZSBJUy1JUyAx NTg4LWF3YXJlIHN1Yi1UTFYgaXMgaWRlbnRpY2FsIHRvIHRoZSBUTFYNCiAgIGZvcm1hdCB1c2Vk IGJ5IHRoZSBUcmFmZmljIEVuZ2luZWVyaW5nIEV4dGVuc2lvbnMgdG8gSVMtSVMgW1JGQzM3ODRd Lg0KICAgVGhhdCBpcywgdGhlIFRMViBpcyBjb21wcmlzZWQgb2YgMSBvY3RldCBmb3IgdGhlIHR5 cGUsIDEgb2N0ZXQNCg0KDQoNCg0KRGF2YXJpLCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNl cHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTIN Cg0KDQogICBzcGVjaWZ5aW5nIHRoZSBUTFYgbGVuZ3RoLCBhbmQgYSB2YWx1ZSBmaWVsZC4gIFRo ZSBMZW5ndGggZmllbGQNCiAgIGRlZmluZXMgdGhlIGxlbmd0aCBvZiB0aGUgdmFsdWUgcG9ydGlv biBpbiBvY3RldHMuDQoNCiAgICAgIDAgICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICAgICAgMg0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICB8ICAgICBUeXBlICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgRmxhZ3Mg ICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQoNCiAgICAgICAgICAgICBGaWd1cmUgNTogMTU4OC1hd2FyZSBDYXBhYmlsaXR5IHN1 Yi1UTFYNCg0KICAgV2hlcmU6DQoNCiAgIFR5cGUsIDggYml0czogMTU4OC1hd2FyZSBDYXBhYmls aXR5IHN1Yi1UTFYgd2hlcmUgdGhlIHZhbHVlIGlzIFRCRA0KDQogICBMZW5ndGgsIDggYml0czog R2l2ZXMgdGhlIGxlbmd0aCBvZiB0aGUgZmxhZ3MgZmllbGQgaW4gb2N0ZXRzLCBhbmQgaXMNCiAg IGN1cnJlbnRseSBzZXQgdG8gMQ0KDQogICBGbGFncywgOCBiaXRzOiBUaGUgYml0cyBhcmUgZGVm aW5lZCBsZWFzdC1zaWduaWZpY2FudC1iaXQgKExTQikNCiAgIGZpcnN0LCBzbyBiaXQgNyBpcyB0 aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0IG9mIHRoZSBmbGFncyBvY3RldC4NCg0KDQogICAgICAg MCAxIDIgMyA0IDUgNiA3DQogICAgICArLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgIFJlc2Vy dmVkICB8Q3wNCiAgICAgICstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgRmlndXJlIDY6IEZsYWdz IEZvcm1hdA0KDQogICBDb3JyZWN0aW9uIChDKSBmaWVsZCBVcGRhdGUgZmllbGQsIDEgYml0OiBT ZXR0aW5nIHRoZSBDIGJpdCB0byAxDQogICBpbmRpY2F0ZXMgdGhhdCB0aGUgbGluayBpcyBjYXBh YmxlIG9mIHJlY29nbml6aW5nIHRoZSBQVFAgZXZlbnQNCiAgIHBhY2tldHMgYW5kIGNhbiBjb21w ZW5zYXRlIGZvciByZXNpZGVuY2UgdGltZSBieSB1cGRhdGluZyB0aGUgUFRQDQogICBwYWNrZXQg Q29ycmVjdGlvbiBGaWVsZC4gIFdoZW4gdGhpcyBpcyBzZXQgdG8gMCwgaXQgbWVhbnMgdGhhdCB0 aGlzDQogICBsaW5rIGNhbm5vdCBwZXJmb3JtIHRoZSByZXNpZGVuY2UgdGltZSBjb3JyZWN0aW9u IGJ1dCBpcyBjYXBhYmxlIG9mDQogICBwZXJmb3JtaW5nIE1QTFMgZnJhbWUgZm9yd2FyZGluZyBv ZiB0aGUgZnJhbWVzIHdpdGggUFRQIGxhYmVscyB1c2luZw0KICAgYSBtZXRob2QgdGhhdCBzdXBw b3J0IHRoZSBlbmQgdG8gZW5kIGRlbGl2ZXJ5IG9mIGFjY3VyYXRlIHRpbWluZy4NCiAgIFRoZSBl eGFjdCBtZXRob2QgaXMgbm90IGRlZmluZWQgaGVyZWluLg0KDQogICBSZXNlcnZlZCwgNyBiaXRz OiBSZXNlcnZlZCBmb3IgZnV0dXJlIHVzZS4gIFRoZSByZXNlcnZlZCBiaXRzIG11c3QgYmUNCiAg IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGF2YXJp LCBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAg W1BhZ2UgMjRdDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMg ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQoxNS4gIFJTVlAtVEUgRXh0ZW5zaW9u cyBmb3Igc3VwcG9ydCBvZiAxNTg4DQoNCiAgIFJTVlAtVEUgc2lnbmFsaW5nIE1BWSBiZSB1c2Vk IHRvIHNldHVwIHRoZSBQVFAgTFNQcy4gIEEgbmV3IFJTVlANCiAgIG9iamVjdCBpcyBkZWZpbmVk IHRvIHNpZ25hbCB0aGF0IHRoaXMgaXMgYSBQVFAgTFNQLiAgVGhlIE9GRlNFVCB0bw0KICAgdGhl IHN0YXJ0IG9mIHRoZSBQVFAgbWVzc2FnZSBoZWFkZXIgTUFZIGFsc28gYmUgc2lnbmFsZWQuDQog ICBJbXBsZW1lbnRhdGlvbnMgY2FuIHRyaXZpYWxseSBsb2NhdGUgdGhlIENvcnJlY3Rpb24gRmll bGQgKENGKQ0KICAgbG9jYXRpb24gZ2l2ZW4gdGhpcyBpbmZvcm1hdGlvbi4gIFRoZSBPRkZTRVQg cG9pbnRzIHRvIHRoZSBzdGFydCBvZg0KICAgdGhlIFBUUCBoZWFkZXIgYXMgYSBub2RlIG1heSB3 YW50IHRvIGNoZWNrIHRoZSBQVFAgbWVzc2FnZSBUeXBlIGJlZm9yZQ0KICAgaXQgdG91Y2hlcyB0 aGUgY29ycmVjdGlvbiBGaWVsZCAoQ0YpLiAgVGhlIE9GRlNFVCBpcyBjb3VudGVkIGZyb20gYm90 dG9tDQogICBvZiBsYWJlbCBzdGFjay4NCg0KICAgVGhlIExTUnMgdGhhdCByZWNlaXZlIGFuZCBw cm9jZXNzIHRoZSBSU1ZQLVRFL0dNUExTIG1lc3NhZ2VzIE1BWSB1c2UNCiAgIHRoZSBPRkZTRVQg dG8gbG9jYXRlIHRoZSBzdGFydCBvZiB0aGUgUFRQIG1lc3NhZ2UgaGVhZGVyLg0KDQogICBOb3Rl IHRoYXQgdGhlIG5ldyBvYmplY3QvVExWIE1VU1QgYmUgaWdub3JlZCBieSBMU1JzIHRoYXQgYXJl IG5vdA0KICAgY29tcGxpYW50IHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KICAgVGhlIG5ldyBS U1ZQIDE1ODhfUFRQX0xTUCBvYmplY3Qgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHNpZ25hbGluZyBQ VFANCiAgIExTUHMgYW5kIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCg0KICAgICAgICAgICAgICAg ICAgIDAgICAgICAgICAgICAgMSAgICAgICAgICAgICAyICAgICAgICAgICAgIDMNCiAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgfCAgICAgICBMZW5ndGggKGJ5dGVzKSAgICAgIHwgIENsYXNzLU51 bSAgfCAgIEMtVHlwZSAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgIHwgT2Zmc2V0IHRv IGxvY2F0ZSB0aGUgc3RhcnQgb2YgdGhlIFBUUCBtZXNzYWdlIGhlYWRlciAgfA0KICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0rDQoNCiAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA3OiBSU1ZQIDE1ODhfUFRQX0xTUCBv YmplY3QNCg0KDQogICBUaGUgaW5ncmVzcyBMU1IgTVVTVCBpbmNsdWRlIHRoaXMgb2JqZWN0IGlu IHRoZSBSU1ZQIFBBVEggTWVzc2FnZS4NCiAgIEl0IGlzIGp1c3QgYSBub3JtYWwgUlNWUCBwYXRo IHRoYXQgaXMgZXhjbHVzaXZlbHkgc2V0IHVwIGZvciBQVFANCiAgIG1lc3NhZ2VzLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAg ICBNYXJjaCAyMDEyDQoNCg0KMTYuICBCZWhhdmlvciBvZiBMRVIvTFNSDQoNCjE2LjEuIEJlaGF2 aW9yIG9mIDE1ODgtY2FwYWJsZS9hd2FyZSBMRVINCg0KICAgQSAxNTg4LWNhcGFibGUvYXdhcmUg TEVSIGFkdmVydGlzZXMgaXQncyAxNTg4LWNhcGFiaWxpdHkgdmlhIHRoZSBPU1BGIA0KICAgb3Ig SVMtSVMgcHJvY2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gIA0KICAgVGhlIDE1ODgtY2FiYWxlL2F3YXJlIExFUiB0aGVuIHNpZ25hbHMg UFRQIExTUHMgYnkgaW5jbHVkaW5nIHRoZSANCiAgIDE1ODhfUFRQX0xTUCBvYmplY3QgaW4gdGhl IFJTVlAtVEUgc2lnbmFsaW5nLg0KDQogICBXaGVuIGEgMTU4OCBtZXNzYWdlIGlzIHJlY2VpdmVk IGZyb20gYSBub24tTVBMUyBpbnRlcmZhY2UsIHRoZSBMRVINCiAgIE1VU1QgcmVkaXJlY3QgdGhl bSB0byBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgUFRQIExTUC4gIFdoZW4gYSAxNTg4DQogICBv dmVyIE1QTFMgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGFuIE1QTFMgaW50ZXJmYWNlLCB0aGUg cHJvY2Vzc2luZw0KICAgaXMgc2ltaWxhciB0byAxNTg4LWF3YXJlIExTUiBwcm9jZXNzaW5nLg0K DQoxNi4yLiBCZWhhdmlvciBvZiAxNTg4LWNhcGFibGUvYXdhcmUgTFNSDQoNCiAgIDE1ODgtY2Fw YWJsZS9hd2FyZSBMU1JzIGFyZSBMU1JzIHRoYXQgdW5kZXJzdGFuZCB0aGUgMTU4OF9QVFBfTFNQ IFJTVlANCiAgIG9iamVjdCBhbmQgY2FuIHBlcmZvcm0gMTU4OCBwcm9jZXNzaW5nIChlLmcudHJh bnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZykuDQoNCiAgIEEgMTU4OC1jYXBhYmxlIExTUiBhZHZl cnRpc2VzIGl0J3MgMTU4OC1jYXBhYmlsaXR5IHZpYSB0aGUgT1NQRiBvciBJUy1JUw0KICAgcHJv Y2VkdXJlIGV4cGxhaW5lZCBpbiBlYXJsaWVyIHNlY3Rpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4NCg0KICAgV2hlbiBhIDE1ODgtY2FwYWJsZS9hd2FyZSBMU1IgZGlzdHJpYnV0ZXMgYSBsYWJl bCBmb3IgUFRQIExTUCwgaXQgbWFpbnRhaW5zDQogICB0aGlzIGluZm9ybWF0aW9uLiAgV2hlbiB0 aGUgMTU4OC1jYXBhYmxlL2F3YXJlIExTUiByZWNlaXZlcyBhbiBNUExTIHBhY2tldCwNCiAgIGl0 IHBlcmZvcm1zIGEgbGFiZWwgbG9va3VwIGFuZCBpZiB0aGUgbGFiZWwgbG9va3VwIGluZGljYXRl cyBpdCBpcyBhIFBUUCANCiAgIGxhYmVsIHRoZW4gZnVydGhlciBwYXJzaW5nIG11c3QgYmUgZG9u ZSB0byBwb3NpdGl2ZWx5IGlkZW50aWZ5IHRoYXQgdGhlIA0KICAgIHBheWxvYWQgaXMgMTU4OCBh bmQgbm90IE9BTSwgQkZEIG9yIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQuDQoNCiAgIFJ1bGluZyBv dXQgbm9uLTE1ODggbWVzc2FnZXMgY2FuIGVhc2lseSBiZSBkb25lIHdoZW4gcGFyc2luZw0KICAg aW5kaWNhdGVzIHRoZSBwcmVzZW5jZSBvZiBHQUwsIEFDSCBvciBWQ0NWIChUeXBlIDEsIDIsIDMp IG9yIHdoZW4gdGhlDQogICBVRFAgcG9ydCBudW1iZXIgZG9lcyBub3QgbWF0Y2ggb25lIG9mIHRo ZSAxNTg4IFVEUCBwb3J0IG51bWJlcnMuDQoNCiAgIEFmdGVyIGEgMTU4OCBtZXNzYWdlIGlzIHBv c2l0aXZlbHkgaWRlbnRpZmllZCBpbiBhIFBUUCBMU1AsIHRoZSBQVFANCiAgIG1lc3NhZ2UgdHlw ZSBpbmRpY2F0ZXMgd2hldGhlciBhbnkgdGltZXN0YW1wIHByb2Nlc3NpbmcgaXMgcmVxdWlyZWQu DQogICBBZnRlciAxNTg4IHByb2Nlc3NpbmcgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgYXMgYSBu b3JtYWwgTVBMUyBwYWNrZXQNCiAgIHRvIGRvd25zdHJlYW0gbm9kZS4NCg0KMTYuMy4gQmVoYXZp b3Igb2Ygbm9uLTE1ODgtY2FwYWJsZS9hd2FyZSBMU1INCg0KICAgVGhlcmUgYXJlIHR3byB0eXBl cyBvZiBMU1JzIHRoYXQgY2FuP3QgcGFydGljaXBhdGUgaW4gcHJvY2Vzc2luZyBQVFAgDQogICBt ZXNzYWdlcyBpbiBhbiBSU1ZQLVRFIHNpZ25hbGVkIFBUUCBMU1A6DQoNCiAgIDEpIExTUnMgdGhh dCBkb24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb2Nlc3MgMTU4OCBwYWNrZXRzIChlLmcuIA0K ICAgICAgcGVyZm9ybSB0cmFuc3BhcmVudCBjbG9jayBwcm9jZXNzaW5nKS4gVGhlc2UgTFNScyBh cmUgY2FsbGVkIA0KICAgICAgbm9uLTE1ODgtY2FwYWJsZSBMU1JzLg0KDQogICAyKSBMU1JzIHRo YXQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBwcm9jZXNzIDE1ODggcGFja2V0cyAoZS5nLiANCiAg ICAgIHBlcmZvcm0gdHJhbnNwYXJlbnQgY2xvY2sgcHJvY2Vzc2luZywgYnV0IGRvbid0IHVuZGVy c3RhbmQgICAgICAgdGhlIDE1ODhfUFRQX0xTUCBSU1ZQIG9iamVjdC4gVGhlc2UgTFNScyBhcmUg Y2FsbGVkIA0KICAgICAgbm9uLTE1ODgtYXdhcmUgTFNScy4NCiAgIA0KDQpEYXZhcmksIGV0IGFs LiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAy Nl0NCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMTINCg0KDQpJdCBpcyBtb3N0IGJlbmVmaWNpYWwgdGhhdCBhbGwg TFNScyBpbiB0aGUgcGF0aCBvZiBhIFBUUCBMU1AgYmUgMTU4OC0NCiAgIENhcGFibGUgYW5kIGF3 YXJlIExTUnMuICBUaGlzIHdvdWxkIGVuc3VyZSB0aGUgaGlnaGVzdCBxdWFsaXR5IHRpbWUgDQog ICBhbmQgY2xvY2sgc3luY2hyb25pemF0aW9uIGJ5IDE1ODggU2xhdmUgQ2xvY2tzLiBIb3dldmVy LCB0aGlzIA0KICAgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIHRoYXQgYWxsIExTUnMg aW4gcGF0aCBvZiBhIFBUUCBMU1AgDQogICBiZSAxNTg4LWNhcGFibGUgYW5kIGF3YXJlLg0KDQoN CiAgIE5vbi0xNTg4LWNhYmFibGUgYW5kIG5vbi0xNTg4LWF3YXJlIExTUnMgaWdub3JlIHRoZSBS U1ZQIA0KICAgMTU4OF9QVFBfTFNQIG9iamVjdCBhbmQganVzdCBzd2l0Y2ggdGhlIE1QTFMgcGFj a2V0cyBjYXJyeWluZyAxNTg4IA0KICAgbWVzc2FnZXMgYXMgZGF0YSBwYWNrZXRzIGFuZCBkb24n dCBwZXJmb3JtIGFueSB0aW1lc3RhbXAgcmVsYXRlZCANCiAgIHByb2Nlc3NpbmcuICBIb3dldmVy IGFzIGV4cGxhaW5lZCBpbiBRb1Mgc2VjdGlvbiB0aGUgMTU4OCBvdmVyIE1QTFMgDQogICBwYWNr ZXRzIE1VU1QgYmUgc3RpbGwgYmUgdHJlYXRlZCB3aXRoIHRoZSBoaWdoZXN0IHByaW9yaXR5Lg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJl cyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDEyDQoNCg0KMTcuICBPdGhlciBjb25zaWRlcmF0aW9ucw0KDQogICBUaGUgdXNlIG9mIEV4cGxp Y2l0IE51bGwgKExhYmVsPSAwIG9yIDIpIGlzIGFjY2VwdGFibGUgYXMgbG9uZyBhcw0KICAgZWl0 aGVyIHRoZSBFeHBsaWNpdCBOdWxsIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFiZWwN CiAgIChhcHBsaWNhYmxlIG9ubHkgdG8gVURQL0lQIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBsYWJl bCBiZWxvdyB0aGUNCiAgIEV4cGxpY2l0IE51bGwgbGFiZWwgaXMgYSBQVFAgbGFiZWwuDQoNCiAg IFRoZSB1c2Ugb2YgUGVudWx0aW1hdGUgSG9wIFBvcCAoUEhQKSBpcyBhY2NlcHRhYmxlIGFzIGxv bmcgYXMgZWl0aGVyDQogICB0aGUgUEhQIGxhYmVsIGlzIHRoZSBib3R0b20gb2Ygc3RhY2sgbGFi ZWwgKGFwcGxpY2FibGUgb25seSB0byBVRFAvSVANCiAgIGVuY2Fwc3VsYXRpb24pIG9yIHRoZSBs YWJlbCBiZWxvdyB0aGUgUEhQIGxhYmVsIGlzIGEgUFRQIGxhYmVsLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEy ICAgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg IDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDEyDQoNCg0KMTguICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBNUExTIFBXIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGluIGdlbmVyYWwgYXJlIGRpc2N1c3NlZCBpbiBbUkZDMzk4NV0NCiAgIGFuZCBbUkZDNDQ0 N10sYW5kIHRob3NlIGNvbnNpZGVyYXRpb25zIGFsc28gYXBwbHkgdG8gdGhpcyBkb2N1bWVudC4N Cg0KICAgQW4gZXhwZXJpbWVudGFsIHNlY3VyaXR5IHByb3RvY29sIGlzIGRlZmluZWQgaW4gW0lF RUVdLiAgVGhlIFBUUA0KICAgc2VjdXJpdHkgZXh0ZW5zaW9uIGFuZCBwcm90b2NvbCBwcm92aWRl cyBncm91cCBzb3VyY2UgYXV0aGVudGljYXRpb24sDQogICBtZXNzYWdlIGludGVncml0eSwgYW5k IHJlcGxheSBhdHRhY2sgcHJvdGVjdGlvbiBmb3IgUFRQIG1lc3NhZ2VzLg0KDQoNCjE5LiAgQXBw bGljYWJpbGl0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIDE1ODggb3ZlciBNUExTIHRyYW5zcG9ydCBt ZXRob2RzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgYXBwbGllcyB0byB0aGUgZm9s bG93aW5nIG5ldHdvcmsgRWxlbWVudHM6DQoNCiAgLSBBbiBMRVIgcmVjZWl2ZXMgSVAgb3IgRXRo ZXJuZXQgRW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGEgDQogICAgbm9uLU1QTFMgaW50 ZXJmYWNlIGFuZCBmb3J3YXJkcyB0aGVtIG92ZXIgTFNQL1BXIGJ5LCB3aGlsZSBwZXJmb3JtaW5n DQogICAgVEMgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExFUiByZWNlaXZlcyBNUExTIGVuY2Fwc3Vs YXRlZCBQVFAgbWVzc2FnZXMgYW5kIGZvcndhcmRzIHRoZW0NCiAgICBhcyBJUCBvciBFdGhlcm5l dCBFbmNhcHN1bGF0ZWQgUFRQIG1lc3NhZ2VzIHRvIGEgbm9uLSAgICBNUExTIGludGVyZmFjZSwg d2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgZnVuY3Rpb25hbGl0eS0gQW4gTEVSIA0KICAgIHJlY2Vp dmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBhbmQgdGVybWluYXRlcyB0aGVtLCB3 aGlsZSANCiAgICBwZXJmb3JtaW5nIHRoZSBPQyBvciBCQyBmdW5jdGlvbmFsaXR5DQogIC0gQW4g TFNSIHJlY2VpdmVzIE1QTFMgZW5jYXBzdWxhdGVkIFBUUCBtZXNzYWdlcyBmcm9tIGFuIE1QTFMg aW50ZXJmYWNlDQogICAgYW5kIGZvcndhcmRzIHRoZW0gdG8gYW5vdGhlciBNUExTIGludGVyZmFj ZSwgd2hpbGUgcGVyZm9ybWluZyB0aGUgVEMgDQogICAgZnVuY3Rpb25hbGl0eQ0KICAtIEFuIExT UiByZWNlaXZlcyBNUExTIGVuY2Fwc3VsYXRlZCBQVFAgbWVzc2FnZXMgYW5kIHRlcm1pbmF0ZXMg dGhlbSwgDQogICAgd2hpbGUgcGVyZm9ybWluZyB0aGUgT0Mgb3IgQkMgZnVuY3Rpb25hbGl0eQ0K DQogICBUaGlzIGRvY3VtZW50IGFsc28gc3VwcG9ydHMgdGhlIGNhc2Ugd2hlcmUgbm90IGFsbCBM U1JzL0xFUnMgYXJlIDE1ODgNCiAgIG92ZXIgTVBMUyBjYXBhYmxlLiBJdCBhbHNvIHN1cHBvcnRz IHRoZSBjYXNlIHdoZXJlIG5vdCBhbGwgTEVSL0xTUiANCiAgIGludGVyZmFjZXMgYXJlIDE1ODgg b3ZlciBNUExTIGNhcGFibGUuDQoNCg0KDQogICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpEYXZhcmksIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgU2VwdCAxMiwgMjAxMiAg ICAgICAgICAgICAgICBbUGFnZSAyOV0NCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAx NTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCjIwLiAgQWNr bm93bGVkZ2VtZW50cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEx1Y2Eg TWFydGluaSwgUm9uIENvaGVuLCBZYWFrb3YNCiAgIFN0ZWluLCBUYWwgTWl6cmFoaSwgU3RlZmFu byBSdWZmaW5pLCBMdWNhIE1vbml0aSBhbmQgb3RoZXIgbWVtYmVycyANCiAgIG9mIElFVEYgZm9y IHJldmlld2luZyAgYW5kIHByb3ZpZGluZyBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0Lg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMwXQ0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAxMg0KDQoNCjIxLiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQoyMS4xLiAgSUFOQSBDb25z aWRlcmF0aW9ucyBmb3IgT1NQRg0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJlZ2lzdHJ5 IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiBhbiBPU1BGDQogICBURSBMaW5rIFRMViAodHlw ZSAyKS4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBzdWItVExWDQogICBjb2Rl cG9pbnQgZm9yIHRoZSAxNTg4YXdhcmUgY2FwYWJpbGl0eSBzdWItVExWIGNhcnJpZWQgd2l0aGlu IHRoZQ0KICAgUm91dGVyIExpbmsgVExWLg0KDQogICAgICBWYWx1ZSAgICAgICAgICAgIFN1Yi1U TFYgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlcw0KICAgICAgLS0tLS0gICAgIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gICAgICAgICAgIC0tLS0tLS0tLS0NCiAgICAgICBUQkQgICAgICAgMTU4 OGF3YXJlIG5vZGUgc3ViLVRMViAgICAgICAgKHRoaXMgZG9jdW1lbnQpDQoNCjIxLjIuICBJQU5B IENvbnNpZGVyYXRpb25zIGZvciBJUy1JUw0KDQogICBJQU5BIGhhcyBkZWZpbmVkIGEgc3ViLXJl Z2lzdHJ5IGZvciB0aGUgc3ViLVRMVnMgY2FycmllZCBpbiB0aGUgSVMtSVMNCiAgIEV4dGVuZGVk IElTIFJlYWNhYmlsaXR5IFRMVi4gIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFzc2lnbiBhIG5ldyBz dWItDQogICBUTFYgY29kZS1wb2ludCBmb3IgdGhlIDE1ODhhd2FyZSBjYXBhYmlsaXR5IHN1Yi1U TFYgY2FycmllZCB3aXRoaW4NCiAgIHRoZSBFeHRlbmRlZCBJUyBSZWFjYWJpbGl0eSBUTFYuDQoN Cg0KICAgICAgVmFsdWUgICAgICAgICAgICBTdWItVExWICAgICAgICAgICAgICAgICAgIFJlZmVy ZW5jZXMNCiAgICAgIC0tLS0tICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAt LS0tLS0tLS0tDQogICAgICAgVEJEICAgICAgIDE1ODhhd2FyZSBub2RlIHN1Yi1UTFYgICAgICAg ICh0aGlzIGRvY3VtZW50KQ0KDQoyMS4zLiAgSUFOQSBDb25zaWRlcmF0aW9ucyBmb3IgUlNWUA0K DQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhc3NpZ24gYSBuZXcgQ2xhc3MgTnVtYmVyIGZvciAx NTg4IFBUUCBMU1ANCiAgIG9iamVjdCB0aGF0IGlzIHVzZWQgdG8gc2lnbmFsIFBUUCBMU1BzLg0K DQogICAxNTg4IFBUUCBMU1AgT2JqZWN0DQoNCiAgIENsYXNzLU51bSBvZiB0eXBlIDExYmJiYmJi DQoNCiAgIFN1Z2dlc3RlZCB2YWx1ZSBUQkQNCg0KICAgRGVmaW5lZCBDVHlwZTogMSAoMTU4OCBQ VFAgTFNQKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIDE1ODggb3ZlciBNUExTICAgICAgICAgICAgICAg ICAgICBNYXJjaCAyMDEyDQoNCg0KMjIuICBSZWZlcmVuY2VzDQoNCjIyLjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcw0KDQogICBbSUVFRV0gICAgIElFRUUgMTU4OC0yMDA4LCAiSUVFRSBTdGFuZGFy ZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sNCiAgICAgICAgICAgICAgU3luY2hyb25pemF0aW9uIFBy b3RvY29sIGZvciBOZXR3b3JrZWQgTWVhc3VyZW1lbnQgYW5kDQogICAgICAgICAgICAgIENvbnRy b2wgU3lzdGVtcyIuDQoNCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAgIFtSRkMzOTg1XSAgQnJ5YW50 LCBTLiBhbmQgUC4gUGF0ZSwgIlBzZXVkbyBXaXJlIEVtdWxhdGlvbiBFZGdlLXRvLQ0KICAgICAg ICAgICAgICBFZGdlIChQV0UzKSBBcmNoaXRlY3R1cmUiLCBSRkMgMzk4NSwgTWFyY2ggMjAwNS4N Cg0KICAgW1JGQzQzODldICBUaGFsZXIsIEQuLCBUYWx3YXIsIE0uLCBhbmQgQy4gUGF0ZWwsICJO ZWlnaGJvciBEaXNjb3ZlcnkNCiAgICAgICAgICAgICAgUHJveGllcyAoTkQgUHJveHkpIiwgUkZD IDQzODksIEFwcmlsIDIwMDYuDQoNCiAgIFtSRkM0NDQ3XSAgTWFydGluaSwgTC4sIFJvc2VuLCBF LiwgRWwtQWF3YXIsIE4uLCBTbWl0aCwgVC4sIGFuZCBHLg0KICAgICAgICAgICAgICBIZXJvbiwg IlBzZXVkb3dpcmUgU2V0dXAgYW5kIE1haW50ZW5hbmNlIFVzaW5nIHRoZSBMYWJlbA0KICAgICAg ICAgICAgICBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExEUCkiLCBSRkMgNDQ0NywgQXByaWwgMjAw Ni4NCg0KICAgW1JGQzQ0NDhdICBNYXJ0aW5pLCBMLiwgUm9zZW4sIEUuLCBFbC1BYXdhciwgTi4s IGFuZCBHLiBIZXJvbiwNCiAgICAgICAgICAgICAgIkVuY2Fwc3VsYXRpb24gTWV0aG9kcyBmb3Ig VHJhbnNwb3J0IG9mIEV0aGVybmV0IG92ZXIgTVBMUw0KICAgICAgICAgICAgICBOZXR3b3JrcyIs IFJGQyA0NDQ4LCBBcHJpbCAyMDA2Lg0KDQogICBbUkZDNDcyMF0gIE1hbGlzLCBBLiwgQWxsYW4s IEQuLCBhbmQgTi4gRGVsIFJlZ25vLCAiUHNldWRvd2lyZQ0KICAgICAgICAgICAgICBFbXVsYXRp b24gRWRnZS10by1FZGdlIChQV0UzKSBGcmFtZSBDaGVjayBTZXF1ZW5jZQ0KICAgICAgICAgICAg ICBSZXRlbnRpb24iLCBSRkMgNDcyMCwgTm92ZW1iZXIgMjAwNi4NCg0KICAgW1JGQzUwODVdICBO YWRlYXUsIFQuIGFuZCBDLiBQaWduYXRhcm8sICJQc2V1ZG93aXJlIFZpcnR1YWwgQ2lyY3VpdA0K ICAgICAgICAgICAgICBDb25uZWN0aXZpdHkgVmVyaWZpY2F0aW9uIChWQ0NWKTogQSBDb250cm9s IENoYW5uZWwgZm9yDQogICAgICAgICAgICAgIFBzZXVkb3dpcmVzIiwgUkZDIDUwODUsIERlY2Vt YmVyIDIwMDcuDQoNCiAgIFtSRkM1ODgwXSAgS2F0eiwgRC4gYW5kIEQuIFdhcmQsICJCaWRpcmVj dGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uDQogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4 ODAsIEp1bmUgMjAxMC4NCg0KICAgW1JGQzU4ODRdICBBZ2dhcndhbCwgUi4sIEtvbXBlbGxhLCBL LiwgTmFkZWF1LCBULiwgYW5kIEcuIFN3YWxsb3csDQogICAgICAgICAgICAgICJCaWRpcmVjdGlv bmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGZvciBNUExTIExhYmVsDQogICAgICAgICAg ICAgIFN3aXRjaGVkIFBhdGhzIChMU1BzKSIsIFJGQyA1ODg0LCBKdW5lIDIwMTAuDQoNCjIyLjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJLUQuaWV0Zi1wd2UzLWZhdC1wd10NCiAg ICAgICAgICAgICAgQnJ5YW50LCBTLiwgRmlsc2ZpbHMsIEMuLCBEcmFmeiwgVS4sIEtvbXBlbGxh LCBWLiwgUmVnYW4sDQogICAgICAgICAgICAgIEouLCBhbmQgUy4gQW1hbnRlLCAiRmxvdyBBd2Fy ZSBUcmFuc3BvcnQgb2YgUHNldWRvd2lyZXMNCiAgICAgICAgICAgICAgb3ZlciBhbiBNUExTIFBh Y2tldCBTd2l0Y2hlZCBOZXR3b3JrIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1wd2UzLWZh dC1wdy0wNyAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAxMS4NCg0KDQoNCg0KRGF2YXJpLCBl dCBhbC4gICAgICAgICAgICBFeHBpcmVzIFNlcHQgMTIsIDIwMTIgICAgICAgICAgICAgICAgW1Bh Z2UgMzJdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAxNTg4IG92ZXIgTVBMUyAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxMg0KDQoNCiAgIFtJU09dICAgICAgSVNPL0lFQyAx MDU4OToxOTkyLCAiSW50ZXJtZWRpYXRlIHN5c3RlbSB0byBJbnRlcm1lZGlhdGUNCiAgICAgICAg ICAgICAgc3lzdGVtIHJvdXRlaW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHByb3RvY29sIGZvciB1 c2UgaW4NCiAgICAgICAgICAgICAgY29uanVuY3Rpb24gd2l0aCB0aGUgUHJvdG9jb2wgZm9yIHBy b3ZpZGluZyB0aGUNCiAgICAgICAgICAgICAgQ29ubmVjdGlvbmxlc3MtbW9kZSBOZXR3b3JrIFNl cnZpY2UgKElTTyA4NDczKSIuDQoNCiAgIFtSRkMxMTk1XSAgQ2FsbG9uLCBSLiwgIlVzZSBvZiBP U0kgSVMtSVMgZm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZA0KICAgICAgICAgICAgICBkdWFsIGVu dmlyb25tZW50cyIsIFJGQyAxMTk1LCBEZWNlbWJlciAxOTkwLg0KDQogICBbUkZDMjMyOF0gIE1v eSwgSi4sICJPU1BGIFZlcnNpb24gMiIsIFNURCA1NCwgUkZDIDIzMjgsIEFwcmlsIDE5OTguDQoN CiAgIFtSRkMzNjMwXSAgS2F0eiwgRC4sIEtvbXBlbGxhLCBLLiwgYW5kIEQuIFlldW5nLCAiVHJh ZmZpYyBFbmdpbmVlcmluZw0KICAgICAgICAgICAgICAoVEUpIEV4dGVuc2lvbnMgdG8gT1NQRiBW ZXJzaW9uIDIiLCBSRkMgMzYzMCwNCiAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDMuDQoNCiAg IFtSRkMzNzg0XSAgU21pdCwgSC4gYW5kIFQuIExpLCAiSW50ZXJtZWRpYXRlIFN5c3RlbSB0byBJ bnRlcm1lZGlhdGUNCiAgICAgICAgICAgICAgU3lzdGVtIChJUy1JUykgRXh0ZW5zaW9ucyBmb3Ig VHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIiwNCiAgICAgICAgICAgICAgUkZDIDM3ODQsIEp1bmUg MjAwNC4NCg0KICAgW1JGQzQ5NzBdICBMaW5kZW0sIEEuLCBTaGVuLCBOLiwgVmFzc2V1ciwgSlAu LCBBZ2dhcndhbCwgUi4sIGFuZCBTLg0KICAgICAgICAgICAgICBTaGFmZmVyLCAiRXh0ZW5zaW9u cyB0byBPU1BGIGZvciBBZHZlcnRpc2luZyBPcHRpb25hbA0KICAgICAgICAgICAgICBSb3V0ZXIg Q2FwYWJpbGl0aWVzIiwgUkZDIDQ5NzAsIEp1bHkgMjAwNy4NCg0KICAgW1JGQzQ5NzFdICBWYXNz ZXVyLCBKUC4sIFNoZW4sIE4uLCBhbmQgUi4gQWdnYXJ3YWwsICJJbnRlcm1lZGlhdGUNCiAgICAg ICAgICAgICAgU3lzdGVtIHRvIEludGVybWVkaWF0ZSBTeXN0ZW0gKElTLUlTKSBFeHRlbnNpb25z IGZvcg0KICAgICAgICAgICAgICBBZHZlcnRpc2luZyBSb3V0ZXIgSW5mb3JtYXRpb24iLCBSRkMg NDk3MSwgSnVseSAyMDA3Lg0KDQogICBbUkZDNTEyMF0gIFByenlnaWVuZGEsIFQuLCBTaGVuLCBO LiwgYW5kIE4uIFNoZXRoLCAiTS1JU0lTOiBNdWx0aQ0KICAgICAgICAgICAgICBUb3BvbG9neSAo TVQpIFJvdXRpbmcgaW4gSW50ZXJtZWRpYXRlIFN5c3RlbSB0bw0KICAgICAgICAgICAgICBJbnRl cm1lZGlhdGUgU3lzdGVtcyAoSVMtSVNzKSIsIFJGQyA1MTIwLCBGZWJydWFyeSAyMDA4Lg0KDQog ICBbUkZDNTMwNV0gIExpLCBULiBhbmQgSC4gU21pdCwgIklTLUlTIEV4dGVuc2lvbnMgZm9yIFRy YWZmaWMNCiAgICAgICAgICAgICAgRW5naW5lZXJpbmciLCBSRkMgNTMwNSwgT2N0b2JlciAyMDA4 Lg0KDQogICBbUkZDNTMyOV0gIElzaGlndXJvLCBLLiwgTWFucmFsLCBWLiwgRGF2ZXksIEEuLCBh bmQgQS4gTGluZGVtLA0KICAgICAgICAgICAgICAiVHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNp b25zIHRvIE9TUEYgVmVyc2lvbiAzIiwNCiAgICAgICAgICAgICAgUkZDIDUzMjksIFNlcHRlbWJl ciAyMDA4Lg0KDQogICBbUkZDNTM0MF0gIENvbHR1biwgUi4sIEZlcmd1c29uLCBELiwgTW95LCBK LiwgYW5kIEEuIExpbmRlbSwgIk9TUEYNCiAgICAgICAgICAgICAgZm9yIElQdjYiLCBSRkMgNTM0 MCwgSnVseSAyMDA4Lg0KDQogICBbUkZDMzI0Nl0gRGF2aWUsIGV0LiBhbC4sID9BbiBFeHBlZGl0 ZWQgRm9yd2FyZGluZyBQSEIgKFBlci1Ib3AgQmVoYXZpb3IpDQogICAgICAgICAgICAgUkZDIDMy NDYsIE1hcmNoIDIwMDINCg0KICAgW1JGQzI2OTddIEouIEhlaW5hbmVuIEouLCBHdWVyaW4sIFIu ICJBIFNpbmdsZSBSYXRlIFRocmVlIENvbG9yIE1hcmtlciwgDQogICAgICAgICAgICAgUkZDIDI2 OTcsIFNlcHRlbWJlciAxOTk5LiANCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAg ICAgRXhwaXJlcyBTZXB0IDEyLCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDMzXQ0KDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgMTU4OCBvdmVyIE1QTFMgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMTINCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KICAgU2hhaHJhbSBEYXZh cmkNCiAgIEJyb2FkY29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0K ICAgRW1haWw6IGRhdmFyaUBicm9hZGNvbS5jb20NCg0KDQogICBBbWl0IE9yZW4NCiAgIEJyb2Fk Y29tIENvcnAuDQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0DQogICBVU0ENCg0KICAgRW1haWw6IGFt aXRvQGJyb2FkY29tLmNvbQ0KDQoNCiAgIE1hbmF2IEJoYXRpYQ0KICAgQWxjYXRlbC1MdWNlbnQN CiAgIEJhbmdhbG9yZSwNCiAgIEluZGlhDQoNCiAgIEVtYWlsOiBtYW5hdi5iaGF0aWFAYWxjYXRl bC1sdWNlbnQuY29tDQoNCg0KICAgUGV0ZXIgUm9iZXJ0cw0KICAgQWxjYXRlbC1MdWNlbnQNCiAg IEthbmF0YSwNCiAgIENhbmFkYQ0KDQogICBFbWFpbDogcGV0ZXIucm9iZXJ0c0BhbGNhdGVsLWx1 Y2VudC5jb20NCg0KDQogICBMYXVyZW50IE1vbnRpbmkNCiAgIENpc2NvIFN5c3RlbXMNCiAgIFNh biBKb3NlIENBDQogICBVU0ENCg0KICAgRW1haWw6IGxtb250aW5pQGNpc2NvLmNvbQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkRhdmFyaSwgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBTZXB0IDEy LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDQo= --_004_FE60A4E52763E84B935532D7D9294FF1355033A22EEUSAACMS0715e_-- From gregimirsky@gmail.com Wed Mar 21 16:03:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A2621E800C; Wed, 21 Mar 2012 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkoYmn6v6sTM; Wed, 21 Mar 2012 16:03:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB02521E8026; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1568498ghb.31 for ; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m3HW88J8pssPkslubGJrpqRR/bREWK0Xe7ijmn43/qo=; b=KUU+bT+NBuUqVt2LpHAs2w1WL3la10spatwDuF7yN/ZPz+2tz7zAQmYOLV2IvB9ElM uCPAx6gjC0xj1bnvih4q0OpPIP3AYo7ON8uW49F16sMeEMm4zzmBKdl6wzIark5rcyIB BfcpuB8IhdJjqTEDq7c5I394L/5vpX0PFlUeJXCA+X69gne9DuuZbHEACh6g5iaLbI6u 38QgV1G+oACW9FPYfDxE55TkHRc6wQhLLSv9TeffpeUCYXFTO9W4LoDGCa14Om11z5JA 7Nu797MxZ5CTGwVrsixCAaCSkP15EhwYTIiY9vKtfQfYW+Cq9l/UCubTlTgx53AO7nOx A5hw== MIME-Version: 1.0 Received: by 10.182.86.200 with SMTP id r8mr7149519obz.20.1332371003453; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) Received: by 10.182.114.98 with HTTP; Wed, 21 Mar 2012 16:03:23 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 21 Mar 2012 16:03:23 -0700 Message-ID: From: Greg Mirsky To: Shahram Davari Content-Type: multipart/alternative; boundary=f46d0444e9a35eb1ec04bbc8cc8f Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:03:24 -0000 --f46d0444e9a35eb1ec04bbc8cc8f Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, noticed that both TICTOC and MPLS agendas refer to -02 version of the document. Would you be presenting -02 or -03? Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari wrote: > Hi,**** > > ** ** > > Please find attached the latest 1588 over MPLS draft (03). Since cut-off > date was yesterday, we will upload this after the Paris meeting.**** > > Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some > aspects from each of these groups are used in this draft. **** > > ** ** > > We will present this draft in the relevant WGs in Paris.**** > > ** ** > > Regards,**** > > Shahram Davari**** > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --f46d0444e9a35eb1ec04bbc8cc8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Shahram,
noticed that both TICTOC and MPLS agendas refer to -02 versi= on of the document. Would you be presenting -02 or -03?

Regards,
= Greg

On Mon, Mar 12, 2012 at 5:16 PM, Sha= hram Davari <da= vari@broadcom.com> wrote:

Hi,

=A0

Please find attached the latest 1588 over MPLS draft= (03). Since cut-off date was yesterday, we will upload this after the Pari= s meeting.

Review is required from = TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these gro= ups are used in this draft.

=A0

We will = present this draft in the relevant WGs in Paris.

=A0

Regards,<= u>

Shahram Davari


____= ___________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3


--f46d0444e9a35eb1ec04bbc8cc8f-- From davari@broadcom.com Wed Mar 21 16:52:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAB21F859F; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLty1QzlZIAw; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4663D21F859A; Wed, 21 Mar 2012 16:52:29 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 21 Mar 2012 17:02:13 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 21 Mar 2012 16:52:17 -0700 From: "Shahram Davari" To: "Greg Mirsky" Date: Wed, 21 Mar 2012 16:52:13 -0700 Thread-Topic: [PWE3] Updated 1588 over MPLS draf-03 Thread-Index: Ac0Httfx7urInSjNTNy4dIZ1z14e0AABqypQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD6BBDEDF4308@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6374B38F4GW7718409-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Cc: "mpls@ietf.org" , CCAMP , "pwe3@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [PWE3] Updated 1588 over MPLS draf-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:52:30 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, I will present ver-02, since ver-03 was not completed in time. But we like = to hear all feddbacks. Thanks Shahram From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: Wednesday, March 21, 2012 4:03 PM To: Shahram Davari Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP Subject: Re: [PWE3] Updated 1588 over MPLS draf-03 Hi Shahram, noticed that both TICTOC and MPLS agendas refer to -02 version of the docum= ent. Would you be presenting -02 or -03? Regards, Greg On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari > wrote: Hi, Please find attached the latest 1588 over MPLS draft (03). Since cut-off da= te was yesterday, we will upload this after the Paris meeting. Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspect= s from each of these groups are used in this draft. We will present this draft in the relevant WGs in Paris. Regards, Shahram Davari _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I will present ver-02, since ver-03 was not comple= ted in time. But we like to hear all feddbacks.

 

Thanks

Shahram

 

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
= Sent: Wednesday, March 21, 2012 4:03 PM
To: Shahram Davari=
Cc: tictoc@ietf.org; mpls@ietf.org; pwe3@ietf.org; CCAMP
S= ubject: Re: [PWE3] Updated 1588 over MPLS draf-03

=

 

Hi Shahram,
noticed that both TICTOC and MPLS = agendas refer to -02 version of the document. Would you be presenting -02 o= r -03?

Regards,
Greg

On M= on, Mar 12, 2012 at 5:16 PM, Shahram Davari <davari@broadcom.com> wrote:

Hi,

 

Please find attache= d the latest 1588 over MPLS draft (03). Since cut-off date was yesterday, w= e will upload this after the Paris meeting.

Review is = required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from eac= h of these groups are used in this draft.

 =

We will present this draft in the relevant WGs in Paris.

 

Regards,

Shahram Davari


_______________________________________________pwe3 mailing list
pwe3@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/pwe3

 

= --_000_2C2F1EBA8050E74EA81502D5740B4BD6BBDF024D71SJEXCHCCR02co_-- From martin.vigoureux@alcatel-lucent.com Thu Mar 22 02:37:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A194321F8620 for ; Thu, 22 Mar 2012 02:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.017 X-Spam-Level: X-Spam-Status: No, score=-109.017 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq-VgndpSotI for ; Thu, 22 Mar 2012 02:37:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E625421F861E for ; Thu, 22 Mar 2012 02:37:53 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2M9bFoV021659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 22 Mar 2012 10:37:50 +0100 Received: from [135.244.178.155] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 10:37:45 +0100 Message-ID: <4F6AF2E1.5040403@alcatel-lucent.com> Date: Thu, 22 Mar 2012 10:37:37 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [mpls] IETF83 - MPLS Sessions - Agenda updated X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:37:54 -0000 Hi, the agenda has been slightly updated http://www.ietf.org/proceedings/83/agenda/agenda-83-mpls.txt Please check it. martin From martin.vigoureux@alcatel-lucent.com Thu Mar 22 02:40:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4321F8646 for ; Thu, 22 Mar 2012 02:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.263 X-Spam-Level: X-Spam-Status: No, score=-107.263 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmQKGQv7vYSd for ; Thu, 22 Mar 2012 02:40:47 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7C9F21F8624 for ; Thu, 22 Mar 2012 02:40:46 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2M9eIZ7019530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 22 Mar 2012 10:40:44 +0100 Received: from [135.244.178.155] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 10:40:22 +0100 Message-ID: <4F6AF379.8000009@alcatel-lucent.com> Date: Thu, 22 Mar 2012 10:40:09 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [mpls] IETF 83 - MPLS Sessions - Time to send slides X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:40:48 -0000 All, the agenda is available here: http://www.ietf.org/proceedings/83/agenda/agenda-83-mpls.txt Please have a look at it. It is now time for the speakers to send me the slides. To those who have a slot, * on Tuesday: please send me the slides, no later than Sunday, 7pm, Paris time * on Friday: please send me the slides, no later than Wednesday, 7pm, Paris time Failure to provide me with the slides in time, will most likely lead to the move of your slot at the end of the agenda. Also, I do remind you that the indicated slot duration is for both your presentation and the Q&As after. Thank you Martin From ping@pingpan.org Thu Mar 22 16:37:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20EF21F852A for ; Thu, 22 Mar 2012 16:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6B804eAQNIE for ; Thu, 22 Mar 2012 16:37:35 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with SMTP id 1BCC421F8527 for ; Thu, 22 Mar 2012 16:37:35 -0700 (PDT) Received: from mail-iy0-f170.google.com ([209.85.210.170]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT2u3vv+yJk6TABuzruP08MI3E1bG5DOQ@postini.com; Thu, 22 Mar 2012 16:37:35 PDT Received: by mail-iy0-f170.google.com with SMTP id h11so4318092iae.29 for ; Thu, 22 Mar 2012 16:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ZqinXoQQDOTzkIQHmJ4h/LVFU/9kw0J82QNjBhqD0ec=; b=JnTyhJPiIR0nBvsxxdVMCV6milqmzMn8x2kmtM/x+iR70SF5Pp4bBNeX5Yf9KG6Grc ftju/8FY59gwlxgaQUX/hcLVBKrVMw5JAqUirz4AYyOLMHUlzPaBbUSH3Z/qFmj9c+8U P4pjv/8kAEImSEpVI1Q/PJvXw2/cELaSHbd2CNU2d29Zjp4OiSJHDijmlqXr6foWeZZJ WlWzqc0P/85mNux3emiWttWk6WhQzpC1ZzRjd+nD/YmUSzfJW5TbTbTyGTY/X1rin9or jNWaKTLmbKvUe1BHcQgNsreUJjp4ZQ/41BjNcxV/3NNs91UrklupPINnPIEUtKQ8bJqT neig== Received: by 10.42.203.148 with SMTP id fi20mr6072725icb.10.1332459454300; Thu, 22 Mar 2012 16:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.134.72 with HTTP; Thu, 22 Mar 2012 16:36:54 -0700 (PDT) In-Reply-To: <30B1E58F6DAB464CA57DBBD13E9DEC08@etri.info> References: <30B1E58F6DAB464CA57DBBD13E9DEC08@etri.info> From: Ping Pan Date: Thu, 22 Mar 2012 16:36:54 -0700 Message-ID: To: "Ryoo, Jeong-dong" Content-Type: multipart/alternative; boundary=20cf303bfecc73831e04bbdd6456 X-Gm-Message-State: ALoCoQm7Lmn363SJqn3thaavBGgLGQCxWgFWK2gjYHL9fqe9pbbs9EHaKXL/Xlopbqll2wjCTjn+ Cc: mpls@ietf.org Subject: Re: [mpls] Note on draft-cheung-mpls-tp-mesh-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:37:36 -0000 --20cf303bfecc73831e04bbdd6456 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jeong-dong and Taesik, After reading your draft, I am a bit confused. Could you please explain the operation in this network using your scheme? ----- B ------- C ---- / \ / \ A D \ / \ / =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D / \ / \ H K \ / \ / ----- I ------- J ---- Link E-F and F-G are shared links to protect failure from headend nodes A, H, D, K and other nodes in the network. In case of failure that has been detected by A, how does A sends the notification to E, F and G. In your draft, you have mentioned to transmit messages real fast three times to reach to the desired nodes. But do you imply there is a control LSP for each node E, F and G? I think this is the key difference between your proposal and ours ( http://www.ietf.org/id/draft-pan-shared-mesh-protection-04.txt). We always initiate activation messages from headends over the entire protecting LSP's. Given its simplicity, we can always get the switch-over completed within a short interval. In your proposal, there seems to be a few underlying assumptions: 1. By re-transmitting critical protection messages three times in packet networks, you assume they would be delivered reliably. Don't think this is how the packet networks work. 2. There is always a special LSP to deliver control messages between the headend to the protection nodes, even if the protection nodes are transit LSR's. In one network, we see the network diameter being 16 hops, with a few hundred edge nodes. In this type of meshy network, don't think you can setup thousands of LSP's between headend nodes to the transit nodes just for the protection messages. Please confirm if my understand is wrong. Regards, Ping On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong wrote: > Greg, > > You are right. > > Indeed, there exists a case that just a node cannot be viewed as being > shared. > > Thanks for the sofisticated consideration. > > Jeong-dong and Taesik > > > > > -----Original Message----- > *From:* "Gregory Mirsky" > *From Date:* 2012-03-15 AM 10:01:26 > *To:* "cts@etri.re.kr" , "ryoo@etri.re.kr" < > ryoo@etri.re.kr>, "wyaacov@gmail.com" , " > nurit.sprecher@nsn.com" , "daniel@olddog.co.uk" < > daniel@olddog.co.uk>, "mpls@ietf.org" > *Cc:* > *Subject:* Note on draft-cheung-mpls-tp-mesh-protection-05 > > Dear Authors, et al., > I have a single note to the draft-cheung-mpls-tp-mesh-protection-05: > > - Section 2.2 "The shared protection resource may be a node, =E2=80=A6= " I > think that a node by itself can not be viewed as shared resource. Only= if > BW of a link, physical or logical, is being shared, only then terminat= ing > nodes can be viewed as shared resource. > > > Regards, > Greg > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --20cf303bfecc73831e04bbdd6456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0Jeong-dong a= nd Taesik,

After reading your draft, I am= a bit confused. Could you please explain the operation in this network usi= ng your scheme?

           ----- B ------- C ----
          /                      \
         /                        \
        A                          D
         \                        /
          \                      /
           =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D
          /                      \
         /                        \
        H                          K
         \                        /
          \                      /
           ----- I ------- J ----

L= ink E-F and F-G are shared links to protect failure from headend nodes A, H= , D, K and other nodes in the network.=C2=A0

In cas= e of failure that has been detected by A, how does A sends the notification= to E, F and G. In your draft, you have mentioned to transmit messages real= fast three times to reach to the desired nodes. But do you imply there is = a control LSP for each node E, F and G?

I thin= k this is the key difference between your proposal and ours (http://= www.ietf.org/id/draft-pan-shared-mesh-protection-04.txt). We always ini= tiate activation messages from headends over the entire protecting LSP'= s. Given its simplicity, we can always get the switch-over completed within= a short interval.

In your proposal, there seems to be a few underlying as= sumptions:

1. By re-transmitting=C2=A0critical pro= tection messages three times in packet networks, you assume they would be d= elivered=C2=A0reliably. Don't think this is how the packet networks wor= k.

2. There is always a special LSP to deliver control mes= sages between the headend to the protection nodes, even if the protection n= odes are transit LSR's. In one network, we see the network diameter bei= ng 16 hops, with a few hundred edge nodes. In this type of meshy network, d= on't think you can setup thousands of LSP's between headend nodes t= o the transit nodes just for the protection messages.

Please confirm if my understand is wrong.
Regards,

Ping


On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:
Greg,
=C2=A0
You are right.
=C2=A0
Indeed,=C2=A0there exists a case that just a node cannot be viewed as = being shared.
=C2=A0
Thanks for the sofisticated consideration.
=C2=A0
Jeong-dong and Taesik
=C2=A0

=C2=A0

-----Original Message-----
From: "Gregory Mirsky&qu= ot; <gr= egory.mirsky@ericsson.com>
From Date: 2012-03-15 AM 10:01:= 26
To: "cts@et= ri.re.kr" <= cts@etri.re.kr>, "ryoo@etri.re.kr" <ryoo@etri.re.kr>, "wyaacov@gmail.com" <wyaacov@gmail.com>, "nurit.sprecher@nsn= .com" <nurit.sprecher@nsn.com>, "daniel@olddog.co.uk" <daniel@olddog.co.uk>, "= mpls@ietf.org" = <mpls@ietf.org>= ;
Cc:
Subject: Note on draft-cheung-mpls-tp-mesh-protection= -05

Dear Authors, et al.,
I have a single note to the draft-cheung-mpls-tp-mesh-protection-05:
  • Section 2.2 "The shared protection resource may be a node, =E2=80= =A6" I think that a node by itself can not be viewed as shared resourc= e. Only if BW of a link, physical or logical, is being shared, only then te= rminating nodes can be viewed as shared resource.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Greg
=C2=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--20cf303bfecc73831e04bbdd6456-- From wyaacov@gmail.com Thu Mar 22 21:59:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B53421E803C for ; Thu, 22 Mar 2012 21:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE7AsgX8JliI for ; Thu, 22 Mar 2012 21:59:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F347A21F84AE for ; Thu, 22 Mar 2012 21:59:18 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2032554qcs.31 for ; Thu, 22 Mar 2012 21:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u33aw5QIdnsRFI7iyziDsj1E8IYBP0Wdnh7zOVQCplU=; b=pQbSvi1A86ANrnl+MdiXF/tPpvwdwZMWpYm5ypZtpPINMNZTUXnOz4sS54TB13ySNa Qs5mOLpPVu6LDm7dpIOjbxn7ywW6nKIoaV4kgvnHWMmOdAK7ebbyXURF8PdpzS3eMG+u DM/0nb8WLFv07eyEFAcZiibwUFOmxhN4N7j8onOlttg6ne8woGAMcdNF3IN46VPbyqOM aBD2q6SHsRx87NrZdMx9zWsaTaKOB1NQqXYOXlyCpNx3rsVlbSwWO0ETjBBzK0yWs6tZ Sfv1Sd3DP0me0Lz/mmhkYalShLGiUGHW2tvBMgEgwN/lWYG7SgC8X/G7SdhQApQy8F63 w6iQ== MIME-Version: 1.0 Received: by 10.224.117.6 with SMTP id o6mr6595012qaq.18.1332478758369; Thu, 22 Mar 2012 21:59:18 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 22 Mar 2012 21:59:18 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 22 Mar 2012 21:59:18 -0700 (PDT) In-Reply-To: References: <30B1E58F6DAB464CA57DBBD13E9DEC08@etri.info> Date: Fri, 23 Mar 2012 06:59:18 +0200 Message-ID: From: Yaacov Weingarten To: Ping Pan Content-Type: multipart/alternative; boundary=20cf3074d7fe1039b104bbe1e36c Cc: mpls@ietf.org Subject: Re: [mpls] Note on draft-cheung-mpls-tp-mesh-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 04:59:20 -0000 --20cf3074d7fe1039b104bbe1e36c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ping, hi In your scenario - 1. We consider E-F-G as a segment rather than as a collection of links. This is one of the advantages of MPLS - that we do not need to consider each link separately but rather "talk" to the signalled LSP or segment. 2. Therefore, A & H need only to communicate with E, K & D need only communicate with G and E needs to communicate with G. F being an intermediate node on a pre-reserved segment is transparent to this communication and the allocation of the resources are immediate as supported by the MPLS framework. 3. As to whether this is true for all packet switched networks - it may not be completely true for Ethernet but this is one of the justifications for defining MPLS, by my understanding, i.e. not to have to address each link along a path! Hope this clarifies a little, yaacov On Mar 23, 2012 1:37 AM, "Ping Pan" wrote: > Hi, Jeong-dong and Taesik, > > After reading your draft, I am a bit confused. Could you please explain > the operation in this network using your scheme? > > ----- B ------- C ---- > / \ > / \ > A D > \ / > \ / > =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D > / \ > / \ > H K > \ / > \ / > ----- I ------- J ---- > > > Link E-F and F-G are shared links to protect failure from headend nodes A= , > H, D, K and other nodes in the network. > > In case of failure that has been detected by A, how does A sends the > notification to E, F and G. In your draft, you have mentioned to transmit > messages real fast three times to reach to the desired nodes. But do you > imply there is a control LSP for each node E, F and G? > > I think this is the key difference between your proposal and ours ( > http://www.ietf.org/id/draft-pan-shared-mesh-protection-04.txt). We > always initiate activation messages from headends over the entire > protecting LSP's. Given its simplicity, we can always get the switch-over > completed within a short interval. > > In your proposal, there seems to be a few underlying assumptions: > > 1. By re-transmitting critical protection messages three times in packet > networks, you assume they would be delivered reliably. Don't think this i= s > how the packet networks work. > > 2. There is always a special LSP to deliver control messages between the > headend to the protection nodes, even if the protection nodes are transit > LSR's. In one network, we see the network diameter being 16 hops, with a > few hundred edge nodes. In this type of meshy network, don't think you ca= n > setup thousands of LSP's between headend nodes to the transit nodes just > for the protection messages. > > Please confirm if my understand is wrong. > > Regards, > > Ping > > > On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong wrote= : > >> Greg, >> >> You are right. >> >> Indeed, there exists a case that just a node cannot be viewed as being >> shared. >> >> Thanks for the sofisticated consideration. >> >> Jeong-dong and Taesik >> >> >> >> >> -----Original Message----- >> *From:* "Gregory Mirsky" >> *From Date:* 2012-03-15 AM 10:01:26 >> *To:* "cts@etri.re.kr" , "ryoo@etri.re.kr" < >> ryoo@etri.re.kr>, "wyaacov@gmail.com" , " >> nurit.sprecher@nsn.com" , "daniel@olddog.co.uk" = < >> daniel@olddog.co.uk>, "mpls@ietf.org" >> *Cc:* >> *Subject:* Note on draft-cheung-mpls-tp-mesh-protection-05 >> >> Dear Authors, et al., >> I have a single note to the draft-cheung-mpls-tp-mesh-protection-05: >> >> - Section 2.2 "The shared protection resource may be a node, =85" I >> think that a node by itself can not be viewed as shared resource. Onl= y if >> BW of a link, physical or logical, is being shared, only then termina= ting >> nodes can be viewed as shared resource. >> >> >> Regards, >> Greg >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> > --20cf3074d7fe1039b104bbe1e36c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Ping, hi

In your scenario -
1. We consider E-F-G as a segment rather than as a collection of links.=A0 = This is one of the advantages of MPLS - that we do not need to consider eac= h link separately but rather "talk" to the signalled LSP or segme= nt.
2. Therefore, A & H need only to communicate with E, K & D need onl= y communicate with G and E needs to communicate with G.=A0 F being an inter= mediate node on a pre-reserved segment is transparent to this communication= and the allocation of the resources are immediate as supported by the MPLS= framework.
3. As to whether this is true for all packet switched networks - it may not= be completely true for Ethernet but this is one of the justifications for = defining MPLS, by my understanding, i.e. not to have to address each link a= long a path!

Hope this clarifies a little,
yaacov

On Mar 23, 2012 1:37 AM, "Ping Pan" &l= t;ping@pingpan.org> wrote:
Hi,=A0Jeong-dong and = Taesik,
<= br>
After reading your draft, I am a = bit confused. Could you please explain the operation in this network using = your scheme?

           ----- B ------- C ----
          /                      \
         /                        \
        A                          D
         \                        /
          \                      /
           =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D
          /                      \
         /                        \
        H                          K
         \                        /
          \                      /
           ----- I ------- J ----

L= ink E-F and F-G are shared links to protect failure from headend nodes A, H= , D, K and other nodes in the network.=A0

In cas= e of failure that has been detected by A, how does A sends the notification= to E, F and G. In your draft, you have mentioned to transmit messages real= fast three times to reach to the desired nodes. But do you imply there is = a control LSP for each node E, F and G?


In your proposal, there seems to be a few underlying as= sumptions:

1. By re-transmitting=A0critical protec= tion messages three times in packet networks, you assume they would be deli= vered=A0reliably. Don't think this is how the packet networks work.

2. There is always a special LSP to deliver control mes= sages between the headend to the protection nodes, even if the protection n= odes are transit LSR's. In one network, we see the network diameter bei= ng 16 hops, with a few hundred edge nodes. In this type of meshy network, d= on't think you can setup thousands of LSP's between headend nodes t= o the transit nodes just for the protection messages.

Please confirm if my understand is wrong.
Regards,

Ping


On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:
Greg,
=A0
You are right.
=A0
Indeed,=A0there exists a case that just a node cannot be viewed as bei= ng shared.
=A0
Thanks for the sofisticated consideration.
=A0
Jeong-dong and Taesik
=A0

=A0

-----Original Message-----
From: "Gregory Mirsky&qu= ot; <gr= egory.mirsky@ericsson.com>
From Date: 2012-03-15 AM 10:01:= 26
To: "cts@et= ri.re.kr" <= cts@etri.re.kr>, "ryoo@etri.re.kr" <ryoo@etri.re.kr>, "wyaacov@gmail.com" <wyaacov@gmail.com>, "nurit.sprecher@nsn= .com" <nurit.sprecher@nsn.com>, "daniel@olddog.co.uk" <daniel@olddog.co.uk>, "= mpls@ietf.org" = <mpls@ietf.org>= ;
Cc:
Subject: Note on draft-cheung-mpls-tp-mesh-protection= -05

Dear Authors, et al.,
I have a single note to the draft-cheung-mpls-tp-mesh-protection-05:
  • Section 2.2 "The shared protection resource may be a node, =85&quo= t; I think that a node by itself can not be viewed as shared resource. Only= if BW of a link, physical or logical, is being shared, only then terminati= ng nodes can be viewed as shared resource.
=A0
=A0=A0=A0=A0=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
=A0
=
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--20cf3074d7fe1039b104bbe1e36c-- From ping@pingpan.org Thu Mar 22 22:20:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBF521F844E for ; Thu, 22 Mar 2012 22:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em4eRjZPu1wL for ; Thu, 22 Mar 2012 22:20:34 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with SMTP id 764EF21F844D for ; Thu, 22 Mar 2012 22:20:34 -0700 (PDT) Received: from mail-iy0-f174.google.com ([209.85.210.174]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT2wIH8aAM4O/yv2G6nsrWcmiqICSheiF@postini.com; Thu, 22 Mar 2012 22:20:34 PDT Received: by mail-iy0-f174.google.com with SMTP id z16so4142803iag.19 for ; Thu, 22 Mar 2012 22:20:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-gm-message-state:content-type; bh=izyt75KIdJXIDFiyoyaWGB0C4dl8FZf/tPUA0DBvyGM=; b=MB7H3kgIHyePW49OJARJf3XLqmY4pxcqn4uAg+4Dd/pyHksH2i5bC7lSW2OnfZyvpO Oms1Ldu+GRlzxYdwMKFNQJtxdcwgexozOEyGy1u3I1HzfP2feTPRU2kX90aPdXfpoqk7 Q3qi51auv86QB25PyHrqwfbyT0iZoaAYy+BcdTLSzu8kF4oHJcHE2V3VOCfYJ/MUHRSj uZvtJVdgfCYySrH2PpoPzA5ENWGHHgkoRBoL69/XoKAvcW1Lrhq+8WvYFwevPPDOh20d rewrYSB6skTI15Xooac5NbCvGDZEaIrTn0S16BYGkfLxK8yVs6OfxRjdQ6+ivmfgSmzg z+Gg== Received: by 10.50.158.227 with SMTP id wx3mr994379igb.31.1332480031708; Thu, 22 Mar 2012 22:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.134.72 with HTTP; Thu, 22 Mar 2012 22:19:51 -0700 (PDT) In-Reply-To: References: <30B1E58F6DAB464CA57DBBD13E9DEC08@etri.info> From: Ping Pan Date: Thu, 22 Mar 2012 22:19:51 -0700 Message-ID: To: Yaacov Weingarten X-Gm-Message-State: ALoCoQmE+jQlBDJj5YwDud7+SbufxR0l8Zuu3ebiy5tKWnGwW2cjkPeAcxHtsBiMVepVIrb7ftI9 Content-Type: multipart/alternative; boundary=14dae9340b7ff5d45304bbe22eca Cc: mpls@ietf.org Subject: Re: [mpls] Note on draft-cheung-mpls-tp-mesh-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:20:36 -0000 --14dae9340b7ff5d45304bbe22eca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2012 at 9:59 PM, Yaacov Weingarten wrote= : > Ping, hi > > In your scenario - > 1. We consider E-F-G as a segment rather than as a collection of links. > This is one of the advantages of MPLS - that we do not need to consider > each link separately but rather "talk" to the signalled LSP or segment. > 2. Therefore, A & H need only to communicate with E, K & D need only > communicate with G and E needs to communicate with G. F being an > intermediate node on a pre-reserved segment is transparent to this > communication and the allocation of the resources are immediate as > supported by the MPLS framework. > But, here is one of the original problems that we are confused about: how does A & H "talk" to E, and K&D "talk" to G? In the context of TP network, the messages are not routed. But unless there exists a special LSP or channel established ahead of time, the nodes cannot communicate, no? 3. As to whether this is true for all packet switched networks - it may not > be completely true for Ethernet but this is one of the justifications for > defining MPLS, by my understanding, i.e. not to have to address each link > along a path! > Not sure I understand this fully. But regardless of MPLS or Ethernet networks, the nodes need to talk to each other. In the draft, it seems that it is to establish a special LSP between the headends and all other intermediate nodes that may participate in the protection. For large networks, that could be a lot of control-only LSP's. In fact, that's an entire new control-plane by itself. Not sure if this is manageable. Regards, Ping Hope this clarifies a little, > yaacov > On Mar 23, 2012 1:37 AM, "Ping Pan" wrote: > >> Hi, Jeong-dong and Taesik, >> >> After reading your draft, I am a bit confused. Could you please explain >> the operation in this network using your scheme? >> >> ----- B ------- C ---- >> / \ >> / \ >> A D >> \ / >> \ / >> =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D >> / \ >> / \ >> H K >> \ / >> \ / >> ----- I ------- J ---- >> >> >> Link E-F and F-G are shared links to protect failure from headend nodes >> A, H, D, K and other nodes in the network. >> >> In case of failure that has been detected by A, how does A sends the >> notification to E, F and G. In your draft, you have mentioned to transmi= t >> messages real fast three times to reach to the desired nodes. But do you >> imply there is a control LSP for each node E, F and G? >> >> I think this is the key difference between your proposal and ours ( >> http://www.ietf.org/id/draft-pan-shared-mesh-protection-04.txt). We >> always initiate activation messages from headends over the entire >> protecting LSP's. Given its simplicity, we can always get the switch-ove= r >> completed within a short interval. >> >> In your proposal, there seems to be a few underlying assumptions: >> >> 1. By re-transmitting critical protection messages three times in packet >> networks, you assume they would be delivered reliably. Don't think this = is >> how the packet networks work. >> >> 2. There is always a special LSP to deliver control messages between the >> headend to the protection nodes, even if the protection nodes are transi= t >> LSR's. In one network, we see the network diameter being 16 hops, with a >> few hundred edge nodes. In this type of meshy network, don't think you c= an >> setup thousands of LSP's between headend nodes to the transit nodes just >> for the protection messages. >> >> Please confirm if my understand is wrong. >> >> Regards, >> >> Ping >> >> >> On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong wrote= : >> >>> Greg, >>> >>> You are right. >>> >>> Indeed, there exists a case that just a node cannot be viewed as being >>> shared. >>> >>> Thanks for the sofisticated consideration. >>> >>> Jeong-dong and Taesik >>> >>> >>> >>> >>> -----Original Message----- >>> *From:* "Gregory Mirsky" >>> *From Date:* 2012-03-15 AM 10:01:26 >>> *To:* "cts@etri.re.kr" , "ryoo@etri.re.kr" < >>> ryoo@etri.re.kr>, "wyaacov@gmail.com" , " >>> nurit.sprecher@nsn.com" , "daniel@olddog.co.uk" >>> , "mpls@ietf.org" >>> *Cc:* >>> *Subject:* Note on draft-cheung-mpls-tp-mesh-protection-05 >>> >>> Dear Authors, et al., >>> I have a single note to the draft-cheung-mpls-tp-mesh-protection-05: >>> >>> - Section 2.2 "The shared protection resource may be a node, =E2=80= =A6" I >>> think that a node by itself can not be viewed as shared resource. On= ly if >>> BW of a link, physical or logical, is being shared, only then termin= ating >>> nodes can be viewed as shared resource. >>> >>> >>> Regards, >>> Greg >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >> --14dae9340b7ff5d45304bbe22eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2012 at 9:59 PM, Yaacov Weingart= en <wyaacov@gmail= .com> wrote:

Ping, hi

In your scenario -
1. We consider E-F-G as a segment rather than as a collection of links.=C2= =A0 This is one of the advantages of MPLS - that we do not need to consider= each link separately but rather "talk" to the signalled LSP or s= egment.
2. Therefore, A & H need only to communicate with E, K & D need onl= y communicate with G and E needs to communicate with G.=C2=A0 F being an in= termediate node on a pre-reserved segment is transparent to this communicat= ion and the allocation of the resources are immediate as supported by the M= PLS framework.


But, here is one of the original probl= ems that we are confused about:=C2=A0how does A & H "talk" to= E, and K&D "talk" to G? In the context of TP network, the me= ssages are not routed. But unless there exists a special LSP or channel est= ablished ahead of time, the nodes cannot communicate, no?

3. As to whether this is true for all packet switched networks - it may not= be completely true for Ethernet but this is one of the justifications for = defining MPLS, by my understanding, i.e. not to have to address each link a= long a path!


Not sure I understand this fully. But rega= rdless of MPLS or Ethernet networks, the nodes need to talk to each other. = In the draft, it seems that it is to establish a special LSP between the he= adends and all other intermediate nodes that may=C2=A0participate=C2=A0in t= he protection. For large networks, that could be a lot of control-only LSP&= #39;s. In fact, that's an entire new control-plane by itself. Not sure = if this is manageable.

Regards,

Ping

Hope this clarifies a little,
yaacov

On Mar 23, 2012 1:37 AM, "Ping Pan" &l= t;ping@pingpan.org> wrote:
Hi,=C2=A0Jeong-dong a= nd Taesik,

After reading your draft, I am= a bit confused. Could you please explain the operation in this network usi= ng your scheme?

           ----- B ------- C ----
          /                      \
         /                        \
        A                          D
         \                        /
          \                      /
           =3D=3D=3D=3D E =3D=3D=3D F =3D=3D=3D G =3D=3D=3D
          /                      \
         /                        \
        H                          K
         \                        /
          \                      /
           ----- I ------- J ----

L= ink E-F and F-G are shared links to protect failure from headend nodes A, H= , D, K and other nodes in the network.=C2=A0

In cas= e of failure that has been detected by A, how does A sends the notification= to E, F and G. In your draft, you have mentioned to transmit messages real= fast three times to reach to the desired nodes. But do you imply there is = a control LSP for each node E, F and G?

In your proposal, there seems to be a few underlying as= sumptions:

1. By re-transmitting=C2=A0critical pro= tection messages three times in packet networks, you assume they would be d= elivered=C2=A0reliably. Don't think this is how the packet networks wor= k.

2. There is always a special LSP to deliver control mes= sages between the headend to the protection nodes, even if the protection n= odes are transit LSR's. In one network, we see the network diameter bei= ng 16 hops, with a few hundred edge nodes. In this type of meshy network, d= on't think you can setup thousands of LSP's between headend nodes t= o the transit nodes just for the protection messages.

Please confirm if my understand is wrong.
Regards,

Ping


On Thu, Mar 15, 2012 at 7:31 PM, Ryoo, Jeong-dong <ryoo@etri.re.kr> wrote:
Greg,
=C2=A0
You are right.
=C2=A0
Indeed,=C2=A0there exists a case that just a node cannot be viewed as = being shared.
=C2=A0
Thanks for the sofisticated consideration.
=C2=A0
Jeong-dong and Taesik
=C2=A0

=C2=A0

-----Original Message-----
From: "Gregory Mirsky&qu= ot; <gr= egory.mirsky@ericsson.com>
From Date: 2012-03-15 AM 10:01:= 26
To: "cts@et= ri.re.kr" <= cts@etri.re.kr>, "ryoo@etri.re.kr" <ryoo@etri.re.kr>, "wyaacov@gmail.com" <wyaacov@gmail.com>, "nurit.sprecher@nsn= .com" <nurit.sprecher@nsn.com>, "daniel@olddog.co.uk" <daniel@olddog.co.uk>, "= mpls@ietf.org" = <mpls@ietf.org>= ;
Cc:
Subject: Note on draft-cheung-mpls-tp-mesh-protection= -05

Dear Authors, et al.,
I have a single note to the draft-cheung-mpls-tp-mesh-protection-05:
  • Section 2.2 "The shared protection resource may be a node, =E2=80= =A6" I think that a node by itself can not be viewed as shared resourc= e. Only if BW of a link, physical or logical, is being shared, only then te= rminating nodes can be viewed as shared resource.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Greg
=C2=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--14dae9340b7ff5d45304bbe22eca-- From huaimo.chen@huawei.com Fri Mar 23 09:13:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15E621F8518 for ; Fri, 23 Mar 2012 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRwGtqOG7s-z for ; Fri, 23 Mar 2012 09:13:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2721F84D8 for ; Fri, 23 Mar 2012 09:13:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ27347; Fri, 23 Mar 2012 12:13:57 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 09:11:31 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 09:11:10 -0700 From: Huaimo Chen To: Gregory Mirsky , "Ning.So@verizonbusiness.com" , "femi@cisco.com" , "le-liu@kddilabs.jp" Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 Thread-Index: Ac0HcrwrMeiuulkjRAO3D0kFTSjwhwBk64zA Date: Fri, 23 Mar 2012 16:11:32 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F25D0@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.214] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F25D0dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 16:13:59 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F25D0dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See my answers inline below. Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, March 21, 2012 10:56 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-c= hen-mpls-p2mp-eggress-protection-05 Dear Authors, et al., Please find my questions to changes in the latest versions below. On draft-chen-mpls-p2mp-ingress-protection-05 * Introduction "The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair, which is an intermediate node between the ingress node and the egress node of the protected LSP." I think that your definition excludes ingress node as PLR by saying "potent= ial point of local repair, which is an intermediate node ...". In fact, any= node, except for egress LER of course, can be PLR if a detour LSP can be c= reated. [[Chen,Huaimo]] Will be rephrased. * Section 4.1 "The time for switching the traffic after= R1 fails is within tens of milliseconds." I don't see what supports this s= tatement. I think that switchover depends on LOC detection by Ra and intern= al processing. The former, BFD interval and DetectMultiplier, i.e. operator= selected configuration parameters, would determine only part of switchover= performance whereas second part is implementation specific and would likel= y depends on number of streams Ra and R1 share. [[Chen,Huaimo]] This is a local protection. Backup ingress node Ra detects = failures in primary ingress node R1 through using the same technical such a= s BFD as an intermediate node as a PLR detects failures in its next hop nod= e for FRR. If an intermediate node can switch the traffic within tens of mi= lliseconds after its next hop node fails, why not backup ingress Ra? * Section 4.4 "In the GMPLS networks where the control plane and data plane are physically separated, the detection and localization of failures in the physical layer can be achieved by introducing the link management protocol (LMP) or assisting by performance monitoring devices." I assume you refer to MPLS-TP network in this paragraph. I think that it is= not clear: * on which links you recommend to run LMP or PM * what would constitute failure particularly in case of PM being use= d * how failure detection will trigger protection switchover [[Chen,Huaimo]] Some details may be added. * Section 5 "However, there is not any standard that locally protects the ingress of the P2MP LSP. The ingress local protection mechanism described above fills this gap." I think that the document describes redundancy, not ingress protection. [[Chen,Huaimo]] What are your definitions of redundancy and protection? On draft-chen-mpls-p2mp-eggress-protection-05: * Introduction "The receiver selects the egress or backup egrss node for receiving the traffic according to the route to the source through RPF. In a normal situation, it selects the egress node. When the egress node fails, it selects the backup egress for receiving the traffic since the route to the source through the egress node is gone and the route to the source through the backup egress node is active." I think that this clearly describes behavior of redundant connection to CE,= 1+1 redundancy. The proposed in the document is nevertheless is based on re= dundant connection of CE. * Same as for Section 4.1 * Same as for Section 4.4 * Same as for Section 5 [[Chen,Huaimo]] Same as or similar to the answers above. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D4325F25D0dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See my answ= ers inline below.

 =

Regards,

Huaimo=

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 21, 2= 012 10:56 AM
To: Huaimo Chen; Ning.So@ver= izonbusiness.com; femi@cisco.com; le-liu@kddilabs.jp
Cc: mpls@ietf.org
Subject: Comments to draft-c= hen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protec= tion-05

 

Dear Authors, et al.,

Please find my questions to changes in the latest= versions below.

On draft-chen-mpls-p2mp-ingress-protection-05

·       =             &nb= sp; Introdu= ction

   "The first method is a one-to-o= ne backup method, where

   a detour backup P2P LSP for each pro= tected P2P LSP is created at each

   potential point of local repair, whi= ch is an intermediate node

   between the ingress node and the egr= ess node of the protected LSP."

I think that your definition excludes ingress nod= e as PLR by saying "potential point of local repair, which is an inter= mediate node ...". In fact, any node, except for egress LER of course, can be PLR if a detour LSP can = be created.

[[Chen,Huaimo]] Will be rephrased.

·       =             &nb= sp; Section= 4.1 "The time for switching the traffic after R1 fails is within tens= of milliseconds." I don't see what supports this statement. I think that switchover depends on LOC detection by Ra and= internal processing. The former, BFD interval and DetectMultiplier, i.e. o= perator selected configuration parameters, would determine only part of swi= tchover performance whereas second part is implementation specific and would likely depends on number of stre= ams Ra and R1 share.

[[Chen,Hua= imo]] This is a local protection. Backup ingress node Ra detects failures in primary = ingress node R1 through using the same technical such as BFD as an intermed= iate node as a PLR detects failures in its next hop node for FRR. If an int= ermediate node can switch the traffic within tens of milliseconds after its next hop node fails, why not backup = ingress Ra?

·       =             &nb= sp; Section= 4.4

   "In the GMPLS networks where th= e control plane and data plane are

   physically separated, the detection = and localization of failures in

   the physical layer can be achieved b= y introducing the link management

   protocol (LMP) or assisting by perfo= rmance monitoring devices."

I assume you refer to MPLS-TP network in this par= agraph. I think that it is not clear:

·        on whic= h links you recommend to run LMP or PM

·        what wo= uld constitute failure particularly in case of PM being used

·        how fai= lure detection will trigger protection switchover<= /p>

[[Chen,Hua= imo]] Some details may be added.

·       =             &nb= sp; Section= 5

   "However, there is not any stan= dard that locally

   protects the ingress of the P2MP LSP= .  The ingress local protection

   mechanism described above fills this= gap."

I think that the document describes redundancy, n= ot ingress protection.

[[Chen,Huaimo]] What are your definitions of redundancy = and protection?

 

On draft-chen-mpls-p2mp-eggress-protection-05:

·       =             &nb= sp; Introdu= ction

   "The receiver selects the egres= s or backup egrss node for receiving

   the traffic according to the route t= o the source through RPF.  In a

   normal situation, it selects the egr= ess node.  When the egress node

   fails, it selects the backup egress = for receiving the traffic since

   the route to the source through the = egress node is gone and the route

   to the source through the backup egr= ess node is active."

I think that this clearly describes behavior of r= edundant connection to CE,1+1 redundancy. The proposed in the document = is nevertheless is based on redundant connection of CE.

·       =             &nb= sp; Same as= for Section 4.1

·       =             &nb= sp; Same as= for Section 4.4

·       =             &nb= sp; Same as= for Section 5

[[Chen,Hua= imo]] Same as or similar to the answers above.

 

        Regard= s,

        &= nbsp;       Greg

 

--_000_5316A0AB3C851246A7CA5758973207D4325F25D0dfweml505mbx_-- From yshen@juniper.net Fri Mar 23 10:24:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3BC21F85A0 for ; Fri, 23 Mar 2012 10:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gVE1MQG0Cdf for ; Fri, 23 Mar 2012 10:24:12 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2F21F850C for ; Fri, 23 Mar 2012 10:24:05 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT2yxtQECjAWpdifAB7QLA4UMYlBTjA4a@postini.com; Fri, 23 Mar 2012 10:24:11 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 10:20:08 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 23 Mar 2012 13:20:08 -0400 From: Yimin Shen To: "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Date: Fri, 23 Mar 2012 13:20:07 -0400 Thread-Topic: comments on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac0JGTG4v7yHr4wFQ/e3Na8ErxEObw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C70D0DB994EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] comments on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 17:24:13 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C70D0DB994EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, I have following comments for this draft. The draft allows a primary ingress router to send an "LSP info" message to = a backup ingress to set up a backup p2mp LSP. This message defines the leaf= nodes and the set of must-traverse intermediate nodes (i.e. the set of 1st= hops of the primary p2mp LSP) for the backup p2mp LSP. [1] Security The creation of backup p2mp LSP is purely based on an external message. Sec= urity must be addressed. It is unclear in the draft whether a primary ingress and a backup ingress m= ust be one hop away from each other, or may be multi hops away. [2] P2P LSPs If the mechanism can apply to p2p LSPs, as claimed, it needs to be addresse= d in detail. [3] CSPF It assumes that the backup ingress can do path computation, e.g. CSPF. What= if it cannot? This would affect applicability. [4] Debuggability Once a the primary ingress has sent a "LSP info" message to a backup ingres= s, there is no way for the primary ingress to learn the existence or succes= s/failure/error state of the backup P2MP LSP. There needs to be some mechanism, such as notification to primary ingress, = to facilitate trouble shooting. [5] No explicit teardown message Please consider an explicit teardown message that a primary ingress can sen= d to tear down the backup LSP. Time-out based mechanism may be too slow. [6] Merge point behavior Detail about merge point behavior: How to distinguish primary LSP and backup LSP; How to handle and propagate ResvTear and PathErr received from downstream; Thanks, -Yimin Shen Juniper Networks Thanks, -Yimin --_000_DF7F294AF4153D498141CBEFADB17704C70D0DB994EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors,
 
I have following comments for this draft.
 
The draft allows a primary ingress router to send an "LSP info&qu= ot; message to a backup ingress to set up a backup p2mp LSP. This message d= efines the leaf nodes and the set of must-traverse intermediate nodes (i.e.= the set of 1st hops of the primary p2mp LSP) for the backup p2mp LSP.
 
[1] Security
 
The creation of backup p2mp LSP is purely based on an external message= . Security must be addressed.
 
It is unclear in the draft whether a primary ingress and a backup ingr= ess must be one hop away from each other, or may be multi hops away.
 
[2] P2P LSPs
 
If the mechanism can apply to p2p LSPs, as claimed, it needs to be add= ressed in detail.
 
[3] CSPF
 
It assumes that the backup ingress can do path computation, e.g. CSPF.= What if it cannot? This would affect applicability.
 
[4] Debuggability
 
Once a the primary ingress has sent a "LSP info" message to = a backup ingress, there is no way for the primary ingress to learn the exis= tence or success/failure/error state of the backup P2MP LSP.
 
There needs to be some mechanism, such as notification to primary ingr= ess, to facilitate trouble shooting.
 
[5] No explicit teardown message
 
Please consider an explicit teardown message that a primary ingress ca= n send to tear down the backup LSP. Time-out based mechanism may be too slo= w.
 
[6] Merge point behavior
 
Detail about merge point behavior:
How to distinguish primary LSP and backup LSP;
How to handle and propagate ResvTear and PathErr received from downstr= eam;
 
 
 
Thanks,
 
-Yimin Shen
 
Juniper Networks
 
 
 
 
Thanks,
 
-Yimin
 
 
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C70D0DB994EMBX01WFjnprn_-- From huaimo.chen@huawei.com Fri Mar 23 13:06:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8A721E804E for ; Fri, 23 Mar 2012 13:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKCKNq3I5DEb for ; Fri, 23 Mar 2012 13:06:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5D21E8026 for ; Fri, 23 Mar 2012 13:06:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEI37092; Fri, 23 Mar 2012 16:06:44 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 13:04:31 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:04:33 -0700 From: Huaimo Chen To: Yimin Shen , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: comments on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac0JGTG4v7yHr4wFQ/e3Na8ErxEObwAEkhnA Date: Fri, 23 Mar 2012 20:04:33 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F26E7@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.214] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F26E7dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:06:46 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F26E7dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See my answers inline below. Regards, Huaimo ________________________________ From: Yimin Shen [mailto:yshen@juniper.net] Sent: Friday, March 23, 2012 1:20 PM To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: comments on draft-chen-mpls-p2mp-ingress-protection Authors, I have following comments for this draft. The draft allows a primary ingress router to send an "LSP info" message to = a backup ingress to set up a backup p2mp LSP. This message defines the leaf= nodes and the set of must-traverse intermediate nodes (i.e. the set of 1st= hops of the primary p2mp LSP) for the backup p2mp LSP. [1] Security The creation of backup p2mp LSP is purely based on an external message. Sec= urity must be addressed. [[Chen,Huaimo]] The primary ingress node and the backup ingress node are in= the same trusted network. Normally the backup ingress node is directly con= nected to the primary ingress node. The LSP info message that the backup in= gress node receives is from the primary ingress node, which is in the same = trusted network as the backup ingress node. It seems that there is not any = security issue in this case. It is unclear in the draft whether a primary ingress and a backup ingress m= ust be one hop away from each other, or may be multi hops away. [[Chen,Huaimo]] The primary ingress node should be directly connected to th= e backup ingress node. That is that the primary ingress node and the backup= ingress node should be one hop away. [2] P2P LSPs If the mechanism can apply to p2p LSPs, as claimed, it needs to be addresse= d in detail. [[Chen,Huaimo]] Some details may be added in the next version. [3] CSPF It assumes that the backup ingress can do path computation, e.g. CSPF. What= if it cannot? This would affect applicability. [[Chen,Huaimo]] If the backup ingress node can not do CSPF, it should have = a way to get a path. For example, PCE may be used to compute the path. In a= normal situation, how does a router without CSPF capability get a protecti= on path satisfying a given set of constraints? [4] Debuggability Once a the primary ingress has sent a "LSP info" message to a backup ingres= s, there is no way for the primary ingress to learn the existence or succes= s/failure/error state of the backup P2MP LSP. There needs to be some mechanism, such as notification to primary ingress, = to facilitate trouble shooting. [[Chen,Huaimo]]This will be considered. [5] No explicit teardown message Please consider an explicit teardown message that a primary ingress can sen= d to tear down the backup LSP. Time-out based mechanism may be too slow. [[Chen,Huaimo]] It seems that time is critical here. [6] Merge point behavior Detail about merge point behavior: How to distinguish primary LSP and backup LSP; How to handle and propagate ResvTear and PathErr received from downstream; [[Chen,Huaimo]] Some details may be added in the next version. Thanks, -Yimin Shen Juniper Networks Thanks, -Yimin --_000_5316A0AB3C851246A7CA5758973207D4325F26E7dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See my answ= ers inline below.

 =

Regards,

Huaimo=

From: Yimin Shen [mailto:yshen@juniper.net]
Sent: Friday, March 23, 2012= 1:20 PM
To: draft-chen-mpls-p2mp-ing= ress-protection@tools.ietf.org
Cc: mpls@ietf.org
Subject: comments on draft-c= hen-mpls-p2mp-ingress-protection

 

Authors,

 

I have following commen= ts for this draft.

 

The draft allows a prim= ary ingress router to send an "LSP info" message to a backup ingr= ess to set up a backup p2mp LSP. This message defines the leaf nodes and the set of must-traverse intermediate nodes (i.e. the s= et of 1st hops of the primary p2mp LSP) for the backup p2mp LSP.

 

[1] Security=

 

The creation of backup = p2mp LSP is purely based on an external message. Security must be addressed= .

 

[[Chen,Huaimo]] The primary ingress node and the ba= ckup ingress node are in the same trusted network. Normally the backup ingress node is directly = connected to the primary ingress node. The LSP info message that the backup= ingress node receives is from the primary ingress node, which is in the sa= me trusted network as the backup ingress node. It seems that there is not any security issue in this case. =

 

It is unclear in the dr= aft whether a primary ingress and a backup ingress must be one hop away fro= m each other, or may be multi hops away.

 

[[Chen,Huaimo]] The primary ingress node should be = directly connected to the backup ingress node. That is that the primary ingress node and the bac= kup ingress node should be one hop away.

 

[2] P2P LSPs=

 

If the mechanism can ap= ply to p2p LSPs, as claimed, it needs to be addressed in detail.=

 

[[Chen,Huaimo]] Some details may be added in the ne= xt version.

 

[3] CSPF

 

It assumes that the bac= kup ingress can do path computation, e.g. CSPF. What if it cannot? This wou= ld affect applicability.

 

[[Chen,Huaimo]] If the backup ingress node can not = do CSPF, it should have a way to get a path. For example, PCE may be used to compute the path. In = a normal situation, how does a router without CSPF capability get a protect= ion path satisfying a given set of constraints?

 

[4] Debuggability<= /o:p>

 

Once a the primary ingr= ess has sent a "LSP info" message to a backup ingress, there is n= o way for the primary ingress to learn the existence or success/failure/error state of the backup P2MP LSP. <= /font>

 

 

There needs to be some = mechanism, such as notification to primary ingress, to facilitate trouble s= hooting.

 

[[Chen,Huaimo]]This will be considered.

 

[5] No explicit teardow= n message

 

Please consider an expl= icit teardown message that a primary ingress can send to tear down the back= up LSP. Time-out based mechanism may be too slow.

 

[[Chen,Huaimo]] It seems that time is critical here= .

 

[6] Merge point behavio= r

 

Detail about merge poin= t behavior:

How to distinguish prim= ary LSP and backup LSP;

How to handle and propa= gate ResvTear and PathErr received from downstream;

 

 

[[Chen,Huaimo]] Some details may be added in the ne= xt version.

 

Thanks,

 

-Yimin Shen<= /span>

 

Juniper Networks

 

 

 

 

Thanks,

 

-Yimin

 

 

 

 

--_000_5316A0AB3C851246A7CA5758973207D4325F26E7dfweml505mbx_-- From gregory.mirsky@ericsson.com Sat Mar 24 05:47:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A744121F86B8 for ; Sat, 24 Mar 2012 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N7neMJchPIz for ; Sat, 24 Mar 2012 05:47:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25121F86B6 for ; Sat, 24 Mar 2012 05:47:04 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2OCku3W027455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 24 Mar 2012 07:46:56 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sat, 24 Mar 2012 08:46:56 -0400 From: Gregory Mirsky To: Huaimo Chen , "Ning.So@verizonbusiness.com" , "femi@cisco.com" , "le-liu@kddilabs.jp" Date: Sat, 24 Mar 2012 08:46:50 -0400 Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 Thread-Index: Ac0HcrwrMeiuulkjRAO3D0kFTSjwhwBk64zAACyyjlA= Message-ID: References: <5316A0AB3C851246A7CA5758973207D4325F25D0@dfweml505-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4325F25D0@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13550DA0FE0EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:47:05 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13550DA0FE0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Huaimo, et al, please find my notes in-lined tagged by GIM>>. Regards, Geg ________________________________ From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, March 23, 2012 9:12 AM To: Gregory Mirsky; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kdd= ilabs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 See my answers inline below. Regards, Huaimo ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, March 21, 2012 10:56 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-c= hen-mpls-p2mp-eggress-protection-05 Dear Authors, et al., Please find my questions to changes in the latest versions below. On draft-chen-mpls-p2mp-ingress-protection-05 * Introduction "The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair, which is an intermediate node between the ingress node and the egress node of the protected LSP." I think that your definition excludes ingress node as PLR by saying "potent= ial point of local repair, which is an intermediate node ...". In fact, any= node, except for egress LER of course, can be PLR if a detour LSP can be c= reated. [[Chen,Huaimo]] Will be rephrased. * Section 4.1 "The time for switching the traffic after= R1 fails is within tens of milliseconds." I don't see what supports this s= tatement. I think that switchover depends on LOC detection by Ra and intern= al processing. The former, BFD interval and DetectMultiplier, i.e. operator= selected configuration parameters, would determine only part of switchover= performance whereas second part is implementation specific and would likel= y depends on number of streams Ra and R1 share. [[Chen,Huaimo]] This is a local protection. Backup ingress node Ra detects = failures in primary ingress node R1 through using the same technical such a= s BFD as an intermediate node as a PLR detects failures in its next hop nod= e for FRR. If an intermediate node can switch the traffic within tens of mi= lliseconds after its next hop node fails, why not backup ingress Ra? GIM>> Firstly, Ra would not distinguish between R1 failure and failure of t= he link between Ra and R1. Hence we might have false positives. Secondly, PLR detects failure of immediate link and local protection might = be of two kinds - link and node. You're not protecting link but try to prot= ect an upstream node. This is not Local Protection per RFC 4090. * Section 4.4 "In the GMPLS networks where the control plane and data plane are physically separated, the detection and localization of failures in the physical layer can be achieved by introducing the link management protocol (LMP) or assisting by performance monitoring devices." I assume you refer to MPLS-TP network in this paragraph. I think that it is= not clear: * on which links you recommend to run LMP or PM * what would constitute failure particularly in case of PM being use= d * how failure detection will trigger protection switchover [[Chen,Huaimo]] Some details may be added. * Section 5 "However, there is not any standard that locally protects the ingress of the P2MP LSP. The ingress local protection mechanism described above fills this gap." I think that the document describes redundancy, not ingress protection. [[Chen,Huaimo]] What are your definitions of redundancy and protection? GIM>> This is very good question and I'm glad we came to its discussion (pe= rhaps we can use some time at the meeting to it). IMO, need to differentiat= e between transport and service. Transport protection assumes single connec= tion to client whereas service protection might have redundant connection (= multi-homed). I think that one practical example is PW redundancy http://to= ols.ietf.org/html/draft-ietf-pwe3-redundancy-06. And I'll note that case in= Section 3.2.3 Single-homed CE with MS-PW redundancy can be viewed as MS-PW= e2e Linear Protection. On draft-chen-mpls-p2mp-eggress-protection-05: * Introduction "The receiver selects the egress or backup egrss node for receiving the traffic according to the route to the source through RPF. In a normal situation, it selects the egress node. When the egress node fails, it selects the backup egress for receiving the traffic since the route to the source through the egress node is gone and the route to the source through the backup egress node is active." I think that this clearly describes behavior of redundant connection to CE,= 1+1 redundancy. The proposed in the document is nevertheless is based on re= dundant connection of CE. * Same as for Section 4.1 * Same as for Section 4.4 * Same as for Section 5 [[Chen,Huaimo]] Same as or similar to the answers above. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13550DA0FE0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Huaimo, et al,
please find my notes in-lined tagged by=20 GIM>>.
 
  &n= bsp; Regards,
        Geg

From: Huaimo Chen=20 [mailto:huaimo.chen@huawei.com]
Sent: Friday, March 23, 2012 9:1= 2=20 AM
To: Gregory Mirsky; Ning.So@verizonbusiness.com; femi@cisco.co= m;=20 le-liu@kddilabs.jp
Cc: mpls@ietf.org
Subject: RE: Comme= nts=20 to draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05

<= SPAN=20 lang=3DEN-US style=3D"FONT-SIZE: 12pt; COLOR: navy">See my answers inline=20 below.

<= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"> 

<= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy">Regards,

<= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 12pt; COLOR: navy">Huaimo

From: Gregory Mirsky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 21, 2012 10:5= 6=20 AM
To: Huaimo Chen;=20 Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddilabs.jp
Cc: mpls@ietf.org
Subject: Comments to=20 draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05

 

Dear Authors, et=20 al.,

Please find my questions to c= hanges=20 in the latest versions below.

On=20 draft-chen-mpls-p2mp-ingress-protection-05

= ·=       &= nbsp;           &nbs= p; =20 Introduction=20

   "The first metho= d is a=20 one-to-one backup method, where

   a detour backup = P2P LSP=20 for each protected P2P LSP is created at each

<= /DIV>

   potential point = of=20 local repair, which is an intermediate node

   between the ingr= ess=20 node and the egress node of the protected=20 LSP."

I think that your definition= =20 excludes ingress node as PLR by saying "potential point of local repair, wh= ich=20 is an intermediate node ...". In fact, any node, except for egress LER of=20 course, can be PLR if a detour LSP can be created.=

[[Chen,Huaimo]]=20 Will be rephrased.

= ·=       &= nbsp;           &nbs= p; =20 Section 4.1 "The= time for=20 switching the traffic after R1 fails is within tens of milliseconds." I don= 't=20 see what supports this statement. I think that switchover depends on LOC=20 detection by Ra and internal processing. The former, BFD interval and=20 DetectMultiplier, i.e. operator selected configuration parameters, would=20 determine only part of switchover performance whereas second part is=20 implementation specific and would likely depends on number of streams Ra an= d R1=20 share.

[[Chen,Huaimo]]=20 This is a local protection. Backup ingress node Ra detects failures in prim= ary=20 ingress node R1 through using the same technical such as BFD as an intermed= iate=20 node as a PLR detects failures in its next hop node for FRR. If an intermed= iate=20 node can switch the traffic within tens of milliseconds after its next hop = node=20 fails, why not backup ingress Ra? 

GIM>> Firstly, = Ra would=20 not distinguish between R1 failure and failure of the link between Ra and R= 1.=20 Hence we might have false positives.

Secondly, PLR detects fail= ure of=20 immediate link and local protection might be of two kinds - link and node.= =20 You're not protecting link but try to protect an upstream node. This is not= =20 Local Protection per RFC 4090.

= ·=       &= nbsp;           &nbs= p; =20 Section=20 4.4

   "In the GMPLS ne= tworks=20 where the control plane and data plane are

   physically separ= ated,=20 the detection and localization of failures in

<= /DIV>

   the physical lay= er can=20 be achieved by introducing the link=20 management

   protocol (LMP) o= r=20 assisting by performance monitoring devices."

<= /DIV>

I assume you refer to MPLS-TP= =20 network in this paragraph. I think that it is not=20 clear:

= ·=       &= nbsp;=20 on which links y= ou=20 recommend to run LMP or PM

= ·=       &= nbsp;=20 what would const= itute=20 failure particularly in case of PM being used

= ·=       &= nbsp;=20 how failure dete= ction=20 will trigger protection switchover

[[Chen,Huaimo]]=20 Some details may be added.

= ·=       &= nbsp;           &nbs= p; =20 Section=20 5

   "However, there = is not=20 any standard that locally

   protects the ing= ress of=20 the P2MP LSP.  The ingress local=20 protection

   mechanism descri= bed=20 above fills this gap."

I think that the document des= cribes=20 redundancy, not ingress protection.

[[Chen,Huaimo]]=20 What are your definitions of redundancy and protection? 

GIM>> This is very&n= bsp;good=20 question and I'm glad we came to its discussion (perhaps we can use so= me=20 time at the meeting to it). IMO, need to differentiate=20 between transport and service. Transport protection assumes singl= e=20 connection to client whereas service protection might have redundant connec= tion=20 (multi-homed). I think that one practical example is PW redundancy http://to= ols.ietf.org/html/draft-ietf-pwe3-redundancy-06.=20 And I'll note that case in Section 3.2.3 Single-homed CE with MS-PW redunda= ncy=20 can be viewed as MS-PW e2e Linear=20 Protection.

 

On=20 draft-chen-mpls-p2mp-eggress-protection-05:

= ·=       &= nbsp;           &nbs= p; =20 Introduction

   "The receiver se= lects=20 the egress or backup egrss node for receiving

<= /DIV>

   the traffic acco= rding=20 to the route to the source through RPF.  In=20 a

   normal situation= , it=20 selects the egress node.  When the egress=20 node

   fails, it select= s the=20 backup egress for receiving the traffic since

<= /DIV>

   the route to the= source=20 through the egress node is gone and the route

<= /DIV>

   to the source th= rough=20 the backup egress node is active."

I think that this clearly des= cribes=20 behavior of redundant connection to CE,1+1 redundancy. The proposed in the= =20 document is nevertheless is based on redundant connection of=20 CE.

= ·=       &= nbsp;           &nbs= p; =20 Same as for Sect= ion=20 4.1

= ·=       &= nbsp;           &nbs= p; =20 Same as for Sect= ion=20 4.4

= ·=       &= nbsp;           &nbs= p; =20 Same as for Sect= ion=20 5

[[Chen,Huaimo]]=20 Same as or similar to the answers above.

 

     = ;  =20 Regards,

     = ;          =20 Greg

 

--_000_FE60A4E52763E84B935532D7D9294FF13550DA0FE0EUSAACMS0715e_-- From martin.vigoureux@alcatel-lucent.com Mon Mar 26 15:17:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C4F21E803A for ; Mon, 26 Mar 2012 15:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe11WwSUW6iE for ; Mon, 26 Mar 2012 15:17:15 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9487F21E801F for ; Mon, 26 Mar 2012 15:17:15 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2QMHCOV017726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 27 Mar 2012 00:17:12 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 00:17:12 +0200 Received: from [135.244.1.9] (135.5.27.12) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 26 Mar 2012 18:17:09 -0400 Message-ID: <4F70EAD8.40704@alcatel-lucent.com> Date: Tue, 27 Mar 2012 00:16:56 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [mpls] Attending MPLS WG sessions @IETF83 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 22:17:16 -0000 Session I: Tuesday 0900-1130 On site participation: Room 242AB Remote participation: Webex link: https://ietf.webex.com/ietf/j.php?ED=150868242&UID=1238593207&PW=NYmY2MGQxZGMw&RT=MiM0 Webex Meeting Number: 641 677 093 Audio stream: http://ietf83streaming.dnsalias.net/ietf/ietf833.m3u Chat room: mpls@jabber.ietf.org Session II: Friday 09:00-11:00 On site participation: Room Maillot Remote participation: Webex link: https://ietf.webex.com/ietf/j.php?ED=150870912&UID=1238606387&PW=NOWRiYTMzNWQz&RT=MiM0 Webex Meeting Number: 641 714 564 Audio stream: http://ietf83streaming.dnsalias.net/ietf/ietf838.m3u Chat room: mpls@jabber.ietf.org Agenda, presentations and minutes: http://tools.ietf.org/wg/mpls/agenda?item=agenda-83-mpls.html https://datatracker.ietf.org/meeting/83/materials.html From huaimo.chen@huawei.com Mon Mar 26 15:17:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0421E803A for ; Mon, 26 Mar 2012 15:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqenZcjEJ2t5 for ; Mon, 26 Mar 2012 15:17:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 590F121E802C for ; Mon, 26 Mar 2012 15:17:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEK23584; Mon, 26 Mar 2012 18:17:16 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Mar 2012 15:15:05 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 26 Mar 2012 15:14:58 -0700 From: Huaimo Chen To: Gregory Mirsky , "Ning.So@verizonbusiness.com" , "femi@cisco.com" , "le-liu@kddilabs.jp" Thread-Topic: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 Thread-Index: Ac0HcrwrMeiuulkjRAO3D0kFTSjwhwBk64zAACyyjlAAc7o5cA== Date: Mon, 26 Mar 2012 22:14:58 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F3008@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.9.245] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F3008dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-chen-mpls-p2mp-eggress-protection-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 22:17:18 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F3008dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See my answers (marked by [[Huaimo Chen]] (2nd Round):) inline below. Regards, Huaimo [X] From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, March 24, 2012 8:47 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 Dear Huaimo, et al, please find my notes in-lined tagged by GIM>>. Regards, Geg [X] From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, March 23, 2012 9:12 AM To: Gregory Mirsky; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kdd= ilabs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 See my answers inline below. Regards, Huaimo [X] From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, March 21, 2012 10:56 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-c= hen-mpls-p2mp-eggress-protection-05 Dear Authors, et al., Please find my questions to changes in the latest versions below. On draft-chen-mpls-p2mp-ingress-protection-05 * Introduction "The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair, which is an intermediate node between the ingress node and the egress node of the protected LSP." I think that your definition excludes ingress node as PLR by saying "potent= ial point of local repair, which is an intermediate node ...". In fact, any= node, except for egress LER of course, can be PLR if a detour LSP can be c= reated. [[Chen,Huaimo]] Will be rephrased. * Section 4.1 "The time for switching the traffic af= ter R1 fails is within tens of milliseconds." I don't see what supports thi= s statement. I think that switchover depends on LOC detection by Ra and int= ernal processing. The former, BFD interval and DetectMultiplier, i.e. opera= tor selected configuration parameters, would determine only part of switcho= ver performance whereas second part is implementation specific and would li= kely depends on number of streams Ra and R1 share. [[Chen,Huaimo]] This is a local protection. Backup ingress node Ra detects = failures in primary ingress node R1 through using the same technical such a= s BFD as an intermediate node as a PLR detects failures in its next hop nod= e for FRR. If an intermediate node can switch the traffic within tens of mi= lliseconds after its next hop node fails, why not backup ingress Ra? GIM>> Firstly, Ra would not distinguish between R1 failure and failure of t= he link between Ra and R1. Hence we might have false positives. [[Chen,Huaimo]] (2nd Round): A few of people mentioned this special case be= fore; we had considered it and discussed a few of possible solutions. Secondly, PLR detects failure of immediate link and local protection might = be of two kinds - link and node. You're not protecting link but try to prot= ect an upstream node. This is not Local Protection per RFC 4090. [[Chen,Huaimo]] (2nd Round): RFC 4090 describes the local protection for th= e links and intermediate nodes of a TE LSP. It does not specify any local p= rotection for the ingress node of a TE LSP. Thus (of course) this ingress l= ocal protection is not the local protection per RFC 4090. The ingress LOCAL protection detects the failure of the ingress node of the= TE LSP LOCALLY (i.e., the failure of the ingress node is detected by the b= ackup ingress node one hop away) and repairs the failure of the ingress nod= e LOCALLY. Thus if a PLR (node) can switch the traffic within tens of milli= seconds after its next hop node (an intermediate node) fails, the backup in= gress node (e.g., Ra) can do the same (switch the traffic within tens of mi= lliseconds after the ingress node fails). * Section 4.4 "In the GMPLS networks where the control plane and data plane are physically separated, the detection and localization of failures in the physical layer can be achieved by introducing the link management protocol (LMP) or assisting by performance monitoring devices." I assume you refer to MPLS-TP network in this paragraph. I think that it is= not clear: * on which links you recommend to run LMP or PM * what would constitute failure particularly in case of PM bei= ng used * how failure detection will trigger protection switchover [[Chen,Huaimo]] Some details may be added. * Section 5 "However, there is not any standard that locally protects the ingress of the P2MP LSP. The ingress local protection mechanism described above fills this gap." I think that the document describes redundancy, not ingress protection. [[Chen,Huaimo]] What are your definitions of redundancy and protection? GIM>> This is very good question and I'm glad we came to its discussion (pe= rhaps we can use some time at the meeting to it). IMO, need to differentiat= e between transport and service. Transport protection assumes single connec= tion to client whereas service protection might have redundant connection (= multi-homed). I think that one practical example is PW redundancy http://to= ols.ietf.org/html/draft-ietf-pwe3-redundancy-06. And I'll note that case in= Section 3.2.3 Single-homed CE with MS-PW redundancy can be viewed as MS-PW= e2e Linear Protection. [[Chen,Huaimo]] (2nd Round): In this case, the question you asked here this= time is similar or equivalent to the question you asked in previous IETF m= eetings, which is what are the differences between the PW redundancy and th= e ingress local protection. There are a number of differences between the PW redundancy and the ingress= local protection. At first, a PW and a TE LSP are different. There is a PW working group in = which people work on the PW related work and there is a MPLS working group = in which people work on TE LSP related work. Secondly, a PW is not at the same level as a TE LSP. The level of a PW is h= igher than the level of a TE LSP. Moreover, (more critically) the method of ingress local protection describe= d in our draft is different from the method of PW redundancy specified in = http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-06 even though we ass= ume that a PW and a TE LSP are the same type of tunnel (of a generic thing)= . On draft-chen-mpls-p2mp-eggress-protection-05: * Introduction "The receiver selects the egress or backup egrss node for receiving the traffic according to the route to the source through RPF. In a normal situation, it selects the egress node. When the egress node fails, it selects the backup egress for receiving the traffic since the route to the source through the egress node is gone and the route to the source through the backup egress node is active." I think that this clearly describes behavior of redundant connection to CE,= 1+1 redundancy. The proposed in the document is nevertheless is based on re= dundant connection of CE. * Same as for Section 4.1 * Same as for Section 4.4 * Same as for Section 5 [[Chen,Huaimo]] Same as or similar to the answers above. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D4325F3008dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
See my answers (marked by [[Huaimo Chen]= ] (2nd Round):) inline below.
 
Regards,
Huaimo
Fr= om: Gregory Mirsky [mail= to:gregory.mirsky@ericsson.com]
Sent: Saturday, March 24, 2012 8:47 AM
To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu= @kddilabs.jp
Cc: mpls@ietf.org
Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 = and draft-chen-mpls-p2mp-eggress-protection-05
 
Dear Huaimo, et al,
please find my notes in-lined tagged by GIM>>.=
 
    Regards,
        Geg
 
From: Huaimo Chen [mailto:huaimo.chen@huawei.com]
Sent: Friday, March 23, 2012 9:12 AM
To: Gregory Mirsky; Ning.So@verizonbusiness.com; femi@cisco.com; le-= liu@kddilabs.jp
Cc: mpls@ietf.org
Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 = and draft-chen-mpls-p2mp-eggress-protection-05
See my answers inline below.
 
Regards,
Huaimo
Fr= om: Gregory Mirsky [mail= to:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 21, 2012 10:56 AM
To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu= @kddilabs.jp
Cc: mpls@ietf.org
Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and = draft-chen-mpls-p2mp-eggress-protection-05
 
Dear A= uthors, et al.,
Please= find my questions to changes in the latest versions below.
On dra= ft-chen-mpls-p2mp-ingress-protection-05
&mid= dot;  &nbs= p;            &= nbsp;     Introducti= on
 =   "The first method is a one-to-one backup method, where
 =   a detour backup P2P LSP for each protected P2P LSP is created at eac= h
 =   potential point of local repair, which is an intermediate node
 =   between the ingress node and the egress node of the protected LSP.&q= uot;
I thin= k that your definition excludes ingress node as PLR by saying "potenti= al point of local repair, which is an intermediate node ...". In fact,= any node, except for egress LER of course, can be PLR if a detour LSP can be created.
[[Chen,Huaimo]] Will be rephrased.
&mid= dot;  &nbs= p;            &= nbsp;     Section 4.= 1 "The time for switching the traffic after R1 fails is within tens of= milliseconds." I don't see what supports this statement. I think that switchover depends o= n LOC detection by Ra and internal processing. The former, BFD interval and= DetectMultiplier, i.e. operator selected configuration parameters, would d= etermine only part of switchover performance whereas second part is implementation specific and would likely= depends on number of streams Ra and R1 share.
[[Chen,Huaimo]]= This is a local protection. Backup ingress node Ra detects failures in pri= mary ingress node R1 through using the same technical such as BFD as an intermediate node as a PLR detects failures in = its next hop node for FRR. If an intermediate node can switch the traffic w= ithin tens of milliseconds after its next hop node fails, why not backup in= gress Ra? 
GIM>> Fir= stly, Ra would not distinguish between R1 failure and failure of the l= ink between Ra and R1. Hence we might have false positives.<= /font>
[[Chen,Huaimo]] (2nd Round): A few of peopl= e mentioned this special case before; we had considered it and discussed a = few of possible solutions.
Secondly, PLR d= etects failure of immediate link and local protection might be of two kinds= - link and node. You're not protecting link but try to protect an upstream node. This is not Local Protection per RFC 4= 090.
[[Chen,Huaimo]] (2nd Round): = RFC 4090 describes the local protection for the links and intermediate node= s of a TE LSP. It does not specify any local protection for the ingress node of a TE LSP. Thus (of course) this in= gress local protection is not the local protection per RFC 4090.
The ingress LOCAL protection detects the failure of the ingress node of= the TE LSP LOCALLY (i.e., the failure of the ingress node is detected by t= he backup ingress node one hop away) and repairs the failure of the ingress node LOCALLY. Thus if = a PLR (node) can switch the traffic within tens= of milliseconds after its next hop node (an in= termediate node) fails, the backup ingress node (e= .g., Ra) can do the same (switch the traffic wi= thin tens of milliseconds after the ingress nod= e fails).
&mid= dot;  &nbs= p;            &= nbsp;     Section 4.= 4
 =   "In the GMPLS networks where the control plane and data plane a= re
 =   physically separated, the detection and localization of failures in<= /span>
 =   the physical layer can be achieved by introducing the link managemen= t
 =   protocol (LMP) or assisting by performance monitoring devices."=
I assu= me you refer to MPLS-TP network in this paragraph. I think that it is not c= lear:
&mid= dot;  &nbs= p;     on which link= s you recommend to run LMP or PM
&mid= dot;  &nbs= p;     what would co= nstitute failure particularly in case of PM being used=
&mid= dot;  &nbs= p;     how failure d= etection will trigger protection switchover
[[Chen,Huaimo]]= Some details may be added.
&mid= dot;  &nbs= p;            &= nbsp;     Section 5<= /font>
 =   "However, there is not any standard that locally<= /div>
 =   protects the ingress of the P2MP LSP.  The ingress local protec= tion
 =   mechanism described above fills this gap."
I thin= k that the document describes redundancy, not ingress protection.
[[Chen,Huaimo]] What are your definitions of redundancy and = protection? <= /font>
GIM>> This is very good question and I'm glad we = came to its discussion (perhaps we can use some time at the meeting to= it). IMO, need to differentiate between transport and service. Transport protection assumes single connection to client whereas servi= ce protection might have redundant connection (multi-homed). I think that o= ne practical example is PW redundancy http://tools.ietf.org/html= /draft-ietf-pwe3-redundancy-06. And I'll note that case in Section 3.2.3 Single-homed CE with MS-PW redunda= ncy can be viewed as MS-PW e2e Linear Protection.
 =
[[Chen,Huaimo]] (2nd Round): In this case, the question you as= ked here this time is similar or equivalent to the question you asked in pr= evious IETF meetings, which is what are the differences between the PW redu= ndancy and the ingress local protection.
 
There are a number of differences between the PW redundan= cy and the ingress local protection.
At first, a PW and a TE LSP are different. There is a PW= working group in which people work on the PW related work and there is a M= PLS working group in which people work on TE LSP related work.
Secondly, a PW is not at the same level as a TE LSP. The = level of a PW is higher than the level of a TE LSP.
Moreover, (more critically) the method of ingress local p= rotection described in our draft is different from the method of PW redunda= ncy specified in http://tools.ietf.org/html/draft-iet= f-pwe3-redundancy-06 = even though we assume that a PW and a TE LSP are the same type of tunnel (of a generic thing).
 
On dra= ft-chen-mpls-p2mp-eggress-protection-05:
&mid= dot;  &nbs= p;            &= nbsp;     Introducti= on
 =   "The receiver selects the egress or backup egrss node for recei= ving
 =   the traffic according to the route to the source through RPF.  = In a
 =   normal situation, it selects the egress node.  When the egress = node
 =   fails, it selects the backup egress for receiving the traffic since<= /span>
 =   the route to the source through the egress node is gone and the rout= e
 =   to the source through the backup egress node is active."=
I thin= k that this clearly describes behavior of redundant connection to CE,1+= 1 redundancy. The proposed in the document is nevertheless is based on redu= ndant connection of CE.
&mid= dot;  &nbs= p;            &= nbsp;     Same as fo= r Section 4.1
&mid= dot;  &nbs= p;            &= nbsp;     Same as fo= r Section 4.4
&mid= dot;  &nbs= p;            &= nbsp;     Same as fo= r Section 5
[[Chen,Huaimo]]= Same as or similar to the answers above.
 =
 =        Regards,
 =             &nb= sp;  Greg
 =
 
 --_000_5316A0AB3C851246A7CA5758973207D4325F3008dfweml505mbx_-- From internet-drafts@ietf.org Mon Mar 26 18:16:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6E121E804C; Mon, 26 Mar 2012 18:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjVH9U7XMcHH; Mon, 26 Mar 2012 18:16:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA88821E802D; Mon, 26 Mar 2012 18:16:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327011628.7089.5977.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 18:16:28 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 01:16:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Richard F. Graveman Filename : draft-ietf-mpls-tp-security-framework-03.txt Pages : 25 Date : 2012-03-26 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, security requirements for MPLS-TP, and mitigation procedures for MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-0= 3.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-security-framework-03= .txt From ilya@nobulus.com Tue Mar 27 01:08:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C021F8667 for ; Tue, 27 Mar 2012 01:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2hTC6WBfzGS for ; Tue, 27 Mar 2012 01:08:30 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2D21F84F4 for ; Tue, 27 Mar 2012 01:08:27 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id AFA69172BE for ; Tue, 27 Mar 2012 10:08:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aBHNviFtn-8q for ; Tue, 27 Mar 2012 10:08:24 +0200 (CEST) Received: from HNIVARLAS2 (unknown [IPv6:2001:df8:0:16:cc8e:d879:3bbf:1359]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 87E7517438 for ; Tue, 27 Mar 2012 10:08:24 +0200 (CEST) From: "Ilya Varlashkin" To: "IETF MPLS" Date: Tue, 27 Mar 2012 10:08:12 +0200 Message-ID: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0L708buMfBe6ukQxWObGzgtcFLIg== Content-Language: en-gb Subject: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:08:31 -0000 Ahmed, Kamran, as first expressed at the mic during MPLS session, I'd like to ask you for a clarification of the motivation behind the draft. You say that this draft will provide faster switch-over/fail-over time compare to anything already existing today. Do you have some numbers for comparison? /iLya From stephane.litkowski@orange.com Tue Mar 27 01:20:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20B121F886F for ; Tue, 27 Mar 2012 01:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oIlCarAgBdb for ; Tue, 27 Mar 2012 01:20:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BD05321F853A for ; Tue, 27 Mar 2012 01:20:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A70772640D8; Tue, 27 Mar 2012 10:20:53 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 87B9C238062; Tue, 27 Mar 2012 10:20:53 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 10:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 10:20:52 +0200 Message-ID: <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0L708buMfBe6ukQxWObGzgtcFLIgAAqgkg References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> From: To: "Ilya Varlashkin" , "IETF MPLS" X-OriginalArrivalTime: 27 Mar 2012 08:20:53.0569 (UTC) FILETIME=[86D4B310:01CD0BF2] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.27.73315 Subject: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:20:59 -0000 Ilya, The best current available mechanism is BGP PIC Edge that relay on IGP conv= ergence to detect that remote PE is no longer reachable : PIC Edge result m= ainly depends on how fast your IGP is converging (sub sec or more). Ahmed solution is an FRR solution so doesn't rely on convergence. As soon a= s a P router detects that the link to the protected PE fails, it will switc= h (using pre-programmed backup NHLFE), so there you are in FRR numbers ... = 50msec - 100msec depending of implementation ... Clearly the solution is today complex, and I hope it could be a bit simplif= ied :) Regards, Stephane -----Message d'origine----- De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part de Ily= a Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation Ahmed, Kamran, as first expressed at the mic during MPLS session, I'd like to ask you for = a clarification of the motivation behind the draft. You say that this draft= will provide faster switch-over/fail-over time compare to anything already= existing today. Do you have some numbers for comparison? /iLya _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Tue Mar 27 01:34:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3321F88E7 for ; Tue, 27 Mar 2012 01:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S88OFB8qtZ9v for ; Tue, 27 Mar 2012 01:34:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AA3C321F88DA for ; Tue, 27 Mar 2012 01:34:55 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 12F4618C358; Tue, 27 Mar 2012 10:34:55 +0200 (CEST) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E354E4C06D; Tue, 27 Mar 2012 10:34:54 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 10:34:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD0BF4.790615D4" Date: Tue, 27 Mar 2012 10:34:48 +0200 Message-ID: <24653_1332837295_4F717BAE_24653_8637_1_4FC3556A36EE3646A09DAA60429F53350804C72C@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Ac0L9HitDiy4wQzqQmmVBjywdLuOlA== From: To: X-OriginalArrivalTime: 27 Mar 2012 08:34:50.0292 (UTC) FILETIME=[798E7F40:01CD0BF4] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.27.73315 Cc: IETF MPLS Subject: [mpls] draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:34:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0BF4.790615D4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD0BF4.790615D4" ------_=_NextPart_002_01CD0BF4.790615D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rajiv, =20 Regarding the discussion about separation of sessions between transport lay= ers. I don't have a strong position on this, I would say that like for BGP, it c= ould be fine to let each operator choose what they want and so both possibi= lities implemented.=20 If I compare to BGP , sometimes we are using multi AFI/SAFI on a common tra= nsport, sometimes we are separating (especially towards customer or at inte= r AS). The main concern I have with using one session per transport layer, is abou= t ok, we have two LDP session, one will transport Ipv4 FEC, one will transp= ort IPv6 FEC. But how will we control other FEC ? On which session PW FEC w= ill be propagated ? same for other FEC types ... In case of multiple sessio= ns, it s important that operators may have control on FEC types transported= on each session. =20 Regards, =20 =20 Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network t=E9l. +33 2 23 28 49 83 stephane.litkowski@orange.com =20 =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ------_=_NextPart_002_01CD0BF4.790615D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rajiv,
 
Regarding= the=20 discussion about separation of sessions between transport=20 layers.
I don't h= ave a=20 strong position on this, I would say that like for BGP, it could be fine to= let=20 each operator choose what they want and so both possibilities=20 implemented. 
If I comp= are to BGP=20 , sometimes we are using multi AFI/SAFI on a common transport, sometimes we= are=20 separating (especially towards customer or at inter AS).
The main = concern I=20 have with using one session per transport layer, is about ok, we have two L= DP=20 session, one will transport Ipv4 FEC, one will transport IPv6 FEC. But how = will=20 we control other FEC ? On which session PW FEC will be propagated ? same fo= r=20 other FEC types ... In case of multiple sessions, it s important that opera= tors=20 may have control on FEC types transported on each session.
 
Regards,
 
=

Stephane=20 Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational=20 Engineering & Support IPTAC for RAEI network
t=E9l. +33 2 23 = 28 49=20 83
stephane.litkowski@orange.com=

 
_____________________________________________________=
____________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
------_=_NextPart_002_01CD0BF4.790615D4-- ------_=_NextPart_001_01CD0BF4.790615D4 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-Description: orange_logo.gif Content-Location: http://www.orange.com/sirius/logos_mail/orange_logo.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01CD0BF4.790615D4 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-Description: ampersand.gif Content-Location: http://www.orange.com/sirius/logos_mail/ampersand.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01CD0BF4.790615D4-- From jeff.tantsura@ericsson.com Tue Mar 27 01:43:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED9D21F88BB for ; Tue, 27 Mar 2012 01:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PizPmjSyJy86 for ; Tue, 27 Mar 2012 01:43:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBB21F87EF for ; Tue, 27 Mar 2012 01:43:48 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2R8hkDv022822; Tue, 27 Mar 2012 03:43:47 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 27 Mar 2012 04:43:41 -0400 From: Jeff Tantsura To: "stephane.litkowski@orange.com" Date: Tue, 27 Mar 2012 04:43:44 -0400 Thread-Topic: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0L9bW1HXrGpVqSQzC+0Pl0bGTBMA== Message-ID: References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF MPLS Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:43:49 -0000 SGksDQoNClRoZSBzd2l0Y2hvdmVyIEFGVEVSIHRoZSBmYWlsdXJlIGhhcyBiZWVuIGRldGVjdGVk IGluIGJvdGggY2FzZXMgaXM6DQpQcmVmaXggaW5kZXBlbmRlbnQgLSBpZSBubyBSSUItPkZJQiBp bnRlcmFjdGlvbnMNClN1YiAxMDBtcyBmb3IgcmVhc29uYWJsZSBudW1iZXIgb2YgcHJpbWFyeS9i YWNrdXAgcGFpcnMNCg0KU28gdGhlIHJlYWwgaXNzdWUgaGVyZSBpcyByZWxpYWJsZSBhbmQgZmFz dCBmYWlsdXJlIG5vdGlmaWNhdGlvbiENCg0KQXMgZm9yIHRoaXMgZHJhZnQgLSBpZiB0aGUgcmVw YWlyaW5nIFAgcm91dGVyIGlzIG5vdCBkaXJlY3RseSBjb25uZWN0ZWQgdG8gdGhlIHByaW1hcnkg UEUgaXQgaXMgc3ViamVjdCB0byB0aGUgc2FtZSBsaW1pdGF0aW9ucyBhbmQgd291bGQgaW5pdGlh dGUgc3dpdGNob3ZlciBvbiBlaXRoZXIgbXVsdGlob3AgQkZEIGRvd24gb3IgSUdQIGNvbnZlcmdl bmNlLg0KRXZlbiB0aG91Z2ggaXQgaXMgcHJlc3VtYWJseSBjbG9zZXIgdG8gdGhlIGZhaWx1cmUg dGhhbiBpbmdyZXNzIFBFIGFuZCBjb3VsZCByZWFjdCBmYXN0ZXIgSU1ITyB0aGUgY29tcGxleGl0 eSBpbnRyb2R1Y2VkIGlzIHJhdGhlciBzaWduaWZpY2FudCBjb21wYXJlZCB0byB0aGUgZ2Fpbi4N Cg0KUmVnYXJkcywNCkplZmYNCg0KT24gTWFyIDI3LCAyMDEyLCBhdCAxMDoyMSBBTSwgInN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+ IHdyb3RlOg0KDQo+IElseWEsDQo+IA0KPiBUaGUgYmVzdCBjdXJyZW50IGF2YWlsYWJsZSBtZWNo YW5pc20gaXMgQkdQIFBJQyBFZGdlIHRoYXQgcmVsYXkgb24gSUdQIGNvbnZlcmdlbmNlIHRvIGRl dGVjdCB0aGF0IHJlbW90ZSBQRSBpcyBubyBsb25nZXIgcmVhY2hhYmxlIDogUElDIEVkZ2UgcmVz dWx0IG1haW5seSBkZXBlbmRzIG9uIGhvdyBmYXN0IHlvdXIgSUdQIGlzIGNvbnZlcmdpbmcgKHN1 YiBzZWMgb3IgbW9yZSkuDQo+IA0KPiBBaG1lZCBzb2x1dGlvbiBpcyBhbiBGUlIgc29sdXRpb24g c28gZG9lc24ndCByZWx5IG9uIGNvbnZlcmdlbmNlLiBBcyBzb29uIGFzIGEgUCByb3V0ZXIgZGV0 ZWN0cyB0aGF0IHRoZSBsaW5rIHRvIHRoZSBwcm90ZWN0ZWQgUEUgZmFpbHMsIGl0IHdpbGwgc3dp dGNoICh1c2luZyBwcmUtcHJvZ3JhbW1lZCBiYWNrdXAgTkhMRkUpLCBzbyB0aGVyZSB5b3UgYXJl IGluIEZSUiBudW1iZXJzIC4uLiA1MG1zZWMgLSAxMDBtc2VjIGRlcGVuZGluZyBvZiBpbXBsZW1l bnRhdGlvbiAuLi4NCj4gDQo+IENsZWFybHkgdGhlIHNvbHV0aW9uIGlzIHRvZGF5IGNvbXBsZXgs IGFuZCBJIGhvcGUgaXQgY291bGQgYmUgYSBiaXQgc2ltcGxpZmllZCA6KQ0KPiANCj4gUmVnYXJk cywNCj4gDQo+IFN0ZXBoYW5lDQo+IA0KPiANCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlIDogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIElseWEgVmFybGFzaGtpbg0KPiBFbnZvecOpIDogbWFyZGkgMjcg bWFycyAyMDEyIDEwOjA4DQo+IMOAIDogSUVURiBNUExTDQo+IE9iamV0IDogW21wbHNdIGRyYWZ0 LWJhc2hhbmR5LW1wbHMtbGRwLWJncC1mcnItMDAgbW90aXZhdGlvbg0KPiANCj4gQWhtZWQsIEth bXJhbiwNCj4gDQo+IGFzIGZpcnN0IGV4cHJlc3NlZCBhdCB0aGUgbWljIGR1cmluZyBNUExTIHNl c3Npb24sIEknZCBsaWtlIHRvIGFzayB5b3UgZm9yIGEgY2xhcmlmaWNhdGlvbiBvZiB0aGUgbW90 aXZhdGlvbiBiZWhpbmQgdGhlIGRyYWZ0LiBZb3Ugc2F5IHRoYXQgdGhpcyBkcmFmdCB3aWxsIHBy b3ZpZGUgZmFzdGVyIHN3aXRjaC1vdmVyL2ZhaWwtb3ZlciB0aW1lIGNvbXBhcmUgdG8gYW55dGhp bmcgYWxyZWFkeSBleGlzdGluZyB0b2RheS4gRG8geW91IGhhdmUgc29tZSBudW1iZXJzIGZvciBj b21wYXJpc29uPw0KPiANCj4gL2lMeWENCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gRnJhbmNlIFRlbGVjb20gLSBP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPiB0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N Cj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu DQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From skraza@cisco.com Tue Mar 27 01:55:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497C21F88A1 for ; Tue, 27 Mar 2012 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.516 X-Spam-Level: X-Spam-Status: No, score=-8.516 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Sj4HbZm+cFP for ; Tue, 27 Mar 2012 01:55:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BA7A721F844F for ; Tue, 27 Mar 2012 01:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=skraza@cisco.com; l=12945; q=dns/txt; s=iport; t=1332838517; x=1334048117; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=c/6NfAr4EUZzT1hSreR4me1O/syjS/5CsOue5Je8f7o=; b=CXhHsMRtmMH5118j61P2HACmuvQ6V3JBrzdNMGlfga6WPQXNVbk4WffS PA5iYUVoxX3Y2/hTb4V3+kydA2O3kj6zhDfzUYim+M+qFzGmjnGedr1gE Ie1hNVY5unbbbOXPkBMaBFNfsRWOjuvGG7lmJOosykNGgzFcVSQJeOopn k=; X-Files: image.gif, image.gif : 1264, 1081 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANF/cU+tJXHB/2dsb2JhbABCA4JGtQl5gQeCCQEBAQMBAQEBAgEMARIJDxgPAggLBQ0BCB0BAQEVEwUQDwEwAQEEAQ0EASKHYwULmjqfEI1mgykEiCWHZoFyg2SORYFogwOBQA X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="gif'147?scan'147,208,217,147";a="69690663" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 27 Mar 2012 08:55:16 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2R8tFqL008670; Tue, 27 Mar 2012 08:55:15 GMT Received: from xmb-rcd-103.cisco.com ([72.163.62.145]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 03:55:15 -0500 Received: from 10.21.114.151 ([10.21.114.151]) by XMB-RCD-103.cisco.com ([72.163.62.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Mar 2012 08:55:14 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 27 Mar 2012 04:56:21 -0400 From: Kamran Raza To: , Message-ID: Thread-Topic: [mpls] draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Ac0L9HitDiy4wQzqQmmVBjywdLuOlAAAwIwi In-Reply-To: <24653_1332837295_4F717BAE_24653_8637_1_4FC3556A36EE3646A09DAA60429F53350804C72C@PUEXCBL0.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: multipart/related; boundary="B_3415668981_27918038" X-OriginalArrivalTime: 27 Mar 2012 08:55:15.0731 (UTC) FILETIME=[53F9A630:01CD0BF7] Cc: IETF MPLS Subject: Re: [mpls] draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:55:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415668981_27918038 Content-type: multipart/alternative; boundary="B_3415668981_27917592" --B_3415668981_27917592 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable IMO, the =B3default=B2 choice for a host session for different types of [ LDP application ] FECs be as follows: 1. MP (P2MP/MP2MP) FECs: Root Address=B9s AFI determines the host LDP session= . 2. PW (Pwid, G. PWid, PW P2MP) FECs: Remote PE =B3target=B2 address=B9s AFI determines the host LDP session. 3. Multi-Topo (MT IP/MT IPv6) FECs: MT is just an extension to LDP FEC so MT IP FEC takes IPv4 session, MT IPv6 takes IPv6 session In addition to above defaults, a configuration option could/should be provided per-app [and/or per-fec-type] to allow a user to change the defaul= t AFI for host session. =20 My 2 cents. On 12-03-27 4:34 AM, "stephane.litkowski@orange.com" wrote: > Rajiv, > =20 > Regarding the discussion about separation of sessions between transport > layers. > I don't have a strong position on this, I would say that like for BGP, it > could be fine to let each operator choose what they want and so both > possibilities implemented. > If I compare to BGP , sometimes we are using multi AFI/SAFI on a common > transport, sometimes we are separating (especially towards customer or at > inter AS). > The main concern I have with using one session per transport layer, is ab= out > ok, we have two LDP session, one will transport Ipv4 FEC, one will transp= ort > IPv6 FEC. But how will we control other FEC ? On which session PW FEC wil= l be > propagated ? same for other FEC types ... In case of multiple sessions, i= t s > important that operators may have control on FEC types transported on eac= h > session. > =20 > Regards, > =20 >=20 >=20 > Stephane Litkowski > FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE >=20 > Operational Engineering & Support IPTAC for RAEI network > t=E9l. +33 2 23 28 49 83 > stephane.litkowski@orange.com >=20 >=20 >=20 > =20 > _________________________________________________________________________= _____ > ___________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges > that have been modified, changed or falsified. > Thank you. >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc., Kanata, ON, K2K 3E8, Canada Ph: +1 (613) 254-4520 http://www.cisco.com --B_3415668981_27917592 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [mpls] draft-ietf-mpls-ldp-ipv6-06
IMO, the “default” choice for a host session for different type= s of [ LDP application ] FECs be as follows:

1. MP (P2MP/MP2MP) FECs: Root Address’s AFI determines the host LDP s= ession.
2. PW (Pwid, G. PWid, PW P2MP) FECs: Remote PE “target” address= ’s AFI determines the host LDP session.
3. Multi-Topo (MT IP/MT IPv6) FECs: MT is just an extension to LDP FEC &nbs= p;so MT IP FEC takes IPv4 session, MT IPv6 takes IPv6 session

In addition to above defaults, a  configuration option could/should be= provided per-app [and/or per-fec-type] to allow a user to change the defaul= t AFI for host session.
 
My 2 cents.

On 12-03-27 4:34 AM, "stephane= .litkowski@orange.com" <= stephane.litkowski@orange.com> wrote:

R= ajiv,
Regarding the discussion about separation of sess= ions between transport layers.
I don't have a strong position on this, I would say that like for BGP, it c= ould be fine to let each operator choose what they want and so both possibil= ities implemented.
If I compare to BGP , sometimes we are using multi AFI/SAFI on a common tra= nsport, sometimes we are separating (especially towards customer or at inter= AS).
The main concern I have with using one session per transport layer, is abou= t ok, we have two LDP session, one will transport Ipv4 FEC, one will transpo= rt IPv6 FEC. But how will we control other FEC ? On which session PW FEC wil= l be propagated ? same for other FEC types ... In case of multiple sessions,= it s important that operators may have control on FEC types transported on = each session.
Regards,


Stephane Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational Engineering & Support IPTAC for RAEI network
tél. +33 2 23 28 49 83
stephane.litk= owski@orange.com



 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

___________= ____________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/m= ailman/listinfo/mpls

--
Syed Kamran Raza
Technical Leader, SPRSG IOS-XR Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada
Ph: +1 (613) 254-4520
http://www.cisco.co= m



--B_3415668981_27917592-- --B_3415668981_27918038 Content-Type: image/gif; name="image.gif" Content-ID: <3415668981_27903377> Content-Transfer-Encoding: base64 R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9Z AP/69v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/U uP9xF/+/lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9l Av+cXf/IpP/8+v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+A Lf9zGv+1h//w5v/u4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9v Ev+zhf9aAP91JP/07P/Dnf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9i Cv+ocv+QSv/Zwv/AmP+8j/+dXv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9n A/9eBP/bw//aw//k1P+STf/r3f/n1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/X vP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/hzv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9l Af9yFv+pcf94KP+xe//Yv/94If9pCv+COf+ZVf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9o A//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+X Vf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8kQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgAAAj/AAEIHEiwoMGD CBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQAQYQCEBAZABO UnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAUINBpABIP qmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBnyQIM ClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0W UCUElMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCH AMEwIcAOOQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhh CQO8THCJDsIUNRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7G FEQhR6yCSQc1HeURXKSMEKdCAQEAOw== --B_3415668981_27918038 Content-Type: image/gif; name="image.gif" Content-ID: <3415668981_27879972> Content-Transfer-Encoding: base64 R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91 AO51APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x 9/7x9vnGk/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P76 9falofzjyvjBivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnN nuo0MeszN/e7gP3r2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxN Q+onK/zm0egaGe5rCvKXOukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvj yvFzdPKQLfCADOgUFPjHkvKNJv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOkl GuszK/rbue9ZW/739uoyMv3w4/jHju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rK y//8/PKZPO9nZ+5OUf759O9xAPjCi+5RSPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve 3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucLC/B/DPrNzvnEu/a2dffBffOEhvaipv738O1R TvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQAAAj/AAEIHDgwlYgs TaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYCR06iMgVLIKUd D7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQcIEJlYSFS pQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUBVAyB UQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAA Ow== --B_3415668981_27918038-- From stephane.litkowski@orange.com Tue Mar 27 01:55:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4895C21F88DC for ; Tue, 27 Mar 2012 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxdDn9uYlWy5 for ; Tue, 27 Mar 2012 01:55:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB221F844F for ; Tue, 27 Mar 2012 01:55:28 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4844E3B403D; Tue, 27 Mar 2012 10:55:26 +0200 (CEST) Received: from puexcc31.nanterre.francetelecom.fr (unknown [10.168.74.8]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2AC49238048; Tue, 27 Mar 2012 10:55:26 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc31.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 10:55:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 10:55:24 +0200 Message-ID: <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: Ac0L9bW1HXrGpVqSQzC+0Pl0bGTBMAAAKwPg References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> From: To: "Jeff Tantsura" X-OriginalArrivalTime: 27 Mar 2012 08:55:26.0402 (UTC) FILETIME=[5A55EA20:01CD0BF7] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: IETF MPLS Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:55:30 -0000 I totally agree with your point as if the P router is not directly connecte= d to the protected PE, the solution doesn't bring any improvement compared = to PIC Edge. The solution as a value for a repairing P connnected to the PE and so detec= ting the failure immediately. If the repairing P is remote to the failure, we are no more in a FRR case .= .. And I think this should be prevented ... -----Message d'origine----- De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Envoy=E9 : mardi 27 mars 2012 10:44 =C0 : LITKOWSKI Stephane DTF/DERX Cc : Ilya Varlashkin; IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation Hi, The switchover AFTER the failure has been detected in both cases is: Prefix independent - ie no RIB->FIB interactions Sub 100ms for reasonable n= umber of primary/backup pairs So the real issue here is reliable and fast failure notification! As for this draft - if the repairing P router is not directly connected to = the primary PE it is subject to the same limitations and would initiate swi= tchover on either multihop BFD down or IGP convergence. Even though it is presumably closer to the failure than ingress PE and coul= d react faster IMHO the complexity introduced is rather significant compare= d to the gain. Regards, Jeff On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: > Ilya, >=20 > The best current available mechanism is BGP PIC Edge that relay on IGP co= nvergence to detect that remote PE is no longer reachable : PIC Edge result= mainly depends on how fast your IGP is converging (sub sec or more). >=20 > Ahmed solution is an FRR solution so doesn't rely on convergence. As soon= as a P router detects that the link to the protected PE fails, it will swi= tch (using pre-programmed backup NHLFE), so there you are in FRR numbers ..= . 50msec - 100msec depending of implementation ... >=20 > Clearly the solution is today complex, and I hope it could be a bit=20 > simplified :) >=20 > Regards, >=20 > Stephane >=20 >=20 > -----Message d'origine----- > De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 > de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS=20 > Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >=20 > Ahmed, Kamran, >=20 > as first expressed at the mic during MPLS session, I'd like to ask you fo= r a clarification of the motivation behind the draft. You say that this dra= ft will provide faster switch-over/fail-over time compare to anything alrea= dy existing today. Do you have some numbers for comparison? >=20 > /iLya >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ilya@nobulus.com Tue Mar 27 01:55:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861CD21F88FB for ; Tue, 27 Mar 2012 01:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwW+q0vcD9V8 for ; Tue, 27 Mar 2012 01:55:45 -0700 (PDT) Received: from nobulus.com (nobulus.com [IPv6:2001:6f8:892:6ff::11:152]) by ietfa.amsl.com (Postfix) with ESMTP id AF8A921F88FA for ; Tue, 27 Mar 2012 01:55:44 -0700 (PDT) Received: from nobulus.com (localhost [127.0.0.1]) by nobulus.com (Postfix) with ESMTP id 0DD4A1755F; Tue, 27 Mar 2012 10:55:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at nobulus.com Received: from nobulus.com ([127.0.0.1]) by nobulus.com (nobulus.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N8erSxNYUYOM; Tue, 27 Mar 2012 10:55:38 +0200 (CEST) Received: from HNIVARLAS2 (unknown [IPv6:2001:df8:0:16:993d:a8b9:f752:3dc6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by nobulus.com (Postfix) with ESMTPSA id 37ECB17568; Tue, 27 Mar 2012 10:55:38 +0200 (CEST) From: "Ilya Varlashkin" To: , "'IETF MPLS'" References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> Date: Tue, 27 Mar 2012 10:55:25 +0200 Message-ID: <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3RvAe49uYSLxVSIfvfdRukh0PXAKofSLMlhQac5A= Content-Language: en-gb Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:55:45 -0000 > -----Original Message----- > The best current available mechanism is BGP PIC Edge that relay on IGP > convergence to detect that remote PE is no longer reachable : PIC Edge result > mainly depends on how fast your IGP is converging (sub sec or more). > I've been recently measuring convergence on not very fast RP and found that even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlikely to be seen in many networks if in any at all. And for real-world sized nets convergence is like few tens of ms - not really to worry about. > Ahmed solution is an FRR solution so doesn't rely on convergence. As soon as > a P router detects that the link to the protected PE fails, it will switch (using > pre-programmed backup NHLFE), so there you are in FRR numbers ... 50msec > - 100msec depending of implementation ... > If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN, PWE, L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that contradicts with original idea of P nodes (they shouldn't care what's inside, only how to get to the edge independent of "payload"). > Clearly the solution is today complex, and I hope it could be a bit simplified :) > Because of previous statement I see proposed solution as complication rather than simplification, and because of above mentioned IGP convergence times the gain seems to be too little when balanced against complexity. /iLya From stephane.litkowski@orange.com Tue Mar 27 02:05:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D498221F88FC; Tue, 27 Mar 2012 02:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF-KhpxvIPPu; Tue, 27 Mar 2012 02:05:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9221F88D4; Tue, 27 Mar 2012 02:04:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E9F1622C0BB; Tue, 27 Mar 2012 11:04:56 +0200 (CEST) Received: from puexcc41.nanterre.francetelecom.fr (unknown [10.168.74.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CF52E23806C; Tue, 27 Mar 2012 11:04:56 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by puexcc41.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:04:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 11:04:55 +0200 Message-ID: <17281_1332839096_4F7182B8_17281_1356_1_4FC3556A36EE3646A09DAA60429F53350804C794@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation Thread-Index: AQH3RvAe49uYSLxVSIfvfdRukh0PXAKofSLMlhQac5CAAAOs0A== References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> From: To: "Ilya Varlashkin" , "IETF MPLS" , X-OriginalArrivalTime: 27 Mar 2012 09:04:56.0953 (UTC) FILETIME=[AE691690:01CD0BF8] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:05:01 -0000 As said to you offline, I would be interrested with discussing about your t= esting, achieving tns of msec with convergence is something I don't really = see in a real world (otherwise why should we implement TE FRR or LFA ??). Regarding the paradigm of giving VPN info on P, yes I agree with your point= , that is something to care about. Globally the solution proposed, gives a per CE view at P router (not really= per VPN) and I have some scaling concerns about it. Today I'm not pushing this kind of solution as clearly it has some issues a= nd brings concerns , I'm just interrested looking at it and see what could = be the improvement that we could provide to some premium customers. The improvement exists, but it must be clearly measured against scaling con= cern, interop with current FRR mechanism ... As we are more discussing about the solution, rather than the LDP evolution= s, I propose to move the discussion to IDR mailing list ... -----Message d'origine----- De : Ilya Varlashkin [mailto:ilya@nobulus.com]=20 Envoy=E9 : mardi 27 mars 2012 10:55 =C0 : LITKOWSKI Stephane DTF/DERX; 'IETF MPLS' Objet : RE: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation > -----Original Message----- > The best current available mechanism is BGP PIC Edge that relay on IGP=20 > convergence to detect that remote PE is no longer reachable : PIC Edge result > mainly depends on how fast your IGP is converging (sub sec or more). > I've been recently measuring convergence on not very fast RP and found that= even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlikely = to be seen in many networks if in any at all. And for real-world sized nets= convergence is like few tens of ms - not really to worry about. =20 > Ahmed solution is an FRR solution so doesn't rely on convergence. As=20 > soon as > a P router detects that the link to the protected PE fails, it will=20 > switch (using > pre-programmed backup NHLFE), so there you are in FRR numbers ...=20 > 50msec > - 100msec depending of implementation ... >=20 If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN, PWE= , L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that cont= radicts with original idea of P nodes (they shouldn't care what's inside, o= nly how to get to the edge independent of "payload"). > Clearly the solution is today complex, and I hope it could be a bit simplified :) > Because of previous statement I see proposed solution as complication rathe= r than simplification, and because of above mentioned IGP convergence times= the gain seems to be too little when balanced against complexity. =20 /iLya ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From stephane.litkowski@orange.com Tue Mar 27 02:06:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA6121E80DC for ; Tue, 27 Mar 2012 02:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFu3oAGA15g6 for ; Tue, 27 Mar 2012 02:06:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 423BD21F88FC for ; Tue, 27 Mar 2012 02:06:22 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A8C2318C0AF; Tue, 27 Mar 2012 11:06:16 +0200 (CEST) Received: from PUEXCC51.nanterre.francetelecom.fr (unknown [10.168.74.61]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 831F327C046; Tue, 27 Mar 2012 11:06:16 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC51.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:06:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD0BF8.DD6EE788" Date: Tue, 27 Mar 2012 11:06:15 +0200 Message-ID: <15082_1332839176_4F718308_15082_6329_1_4FC3556A36EE3646A09DAA60429F53350804C796@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [mpls] draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Ac0L9HitDiy4wQzqQmmVBjywdLuOlAAAwIwiAABXN6A= References: <24653_1332837295_4F717BAE_24653_8637_1_4FC3556A36EE3646A09DAA60429F53350804C72C@PUEXCBL0.nanterre.francetelecom.fr> From: To: "Kamran Raza" , X-OriginalArrivalTime: 27 Mar 2012 09:06:16.0559 (UTC) FILETIME=[DDDBFFF0:01CD0BF8] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.27.82415 Cc: IETF MPLS Subject: Re: [mpls] draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:06:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0BF8.DD6EE788 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD0BF8.DD6EE788" ------_=_NextPart_002_01CD0BF8.DD6EE788 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. =20 ________________________________ De : Kamran Raza [mailto:skraza@cisco.com]=20 Envoy=E9 : mardi 27 mars 2012 10:56 =C0 : LITKOWSKI Stephane DTF/DERX; rajiva@cisco.com Cc : IETF MPLS Objet : Re: [mpls] draft-ietf-mpls-ldp-ipv6-06 =09 =09 =09 IMO, the "default" choice for a host session for different types of [ LDP = application ] FECs be as follows: =09 1. MP (P2MP/MP2MP) FECs: Root Address's AFI determines the host LDP sessio= n. 2. PW (Pwid, G. PWid, PW P2MP) FECs: Remote PE "target" address's AFI dete= rmines the host LDP session. 3. Multi-Topo (MT IP/MT IPv6) FECs: MT is just an extension to LDP FEC so= MT IP FEC takes IPv4 session, MT IPv6 takes IPv6 session =09 In addition to above defaults, a configuration option could/should be pro= vided per-app [and/or per-fec-type] to allow a user to change the default A= FI for host session. =09=20 My 2 cents. =09 On 12-03-27 4:34 AM, "stephane.litkowski@orange.com" wrote: =09 =09 Rajiv, =09=09 Regarding the discussion about separation of sessions between transport l= ayers. I don't have a strong position on this, I would say that like for BGP, it= could be fine to let each operator choose what they want and so both possi= bilities implemented.=20 If I compare to BGP , sometimes we are using multi AFI/SAFI on a common t= ransport, sometimes we are separating (especially towards customer or at in= ter AS). The main concern I have with using one session per transport layer, is ab= out ok, we have two LDP session, one will transport Ipv4 FEC, one will tran= sport IPv6 FEC. But how will we control other FEC ? On which session PW FEC= will be propagated ? same for other FEC types ... In case of multiple sess= ions, it s important that operators may have control on FEC types transport= ed on each session. =09=09 Regards, =09=09 =09=09=20 =09=09 Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE =09=09 Operational Engineering & Support IPTAC for RAEI network t=E9l. +33 2 23 28 49 83 stephane.litkowski@orange.com =09=09 =09=09=20 =09=09 =09=09=20 _________________________________________________________________________= ________________________________________________ =09=09 Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. =09=09 This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and de= lete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. Thank you. =09=09 =09=09 ________________________________ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls =09=09 =09 --=20 Syed Kamran Raza Technical Leader, SPRSG IOS-XR Routing (MPLS) Cisco Systems, Inc.,=20 Kanata, ON, K2K 3E8, Canada=20 Ph: +1 (613) 254-4520 http://www.cisco.com=20 =09 =09 =09 =09 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ------_=_NextPart_002_01CD0BF8.DD6EE788 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [mpls] draft-ietf-mpls-ldp-ipv6-06
Thanks for the clarification.
 <= /DIV>
De : Kamran Raza=20 [mailto:skraza@cisco.com]
Envoy=E9 : mardi 27 mars 2012= =20 10:56
=C0 : LITKOWSKI Stephane DTF/DERX;=20 rajiva@cisco.com
Cc : IETF MPLS
Objet : Re:= =20 [mpls] draft-ietf-mpls-ldp-ipv6-06


IMO, the =93default=94 choice for a host se= ssion for=20 different types of [ LDP application ] FECs be as follows:

1. MP= =20 (P2MP/MP2MP) FECs: Root Address=92s AFI determines the host LDP session.<= BR>2.=20 PW (Pwid, G. PWid, PW P2MP) FECs: Remote PE =93target=94 address=92s AFI = determines=20 the host LDP session.
3. Multi-Topo (MT IP/MT IPv6) FECs: MT is just a= n=20 extension to LDP FEC  so MT IP FEC takes IPv4 session, MT IPv6 takes= IPv6=20 session

In addition to above defaults, a  configuration optio= n=20 could/should be provided per-app [and/or per-fec-type] to allow a user to= =20 change the default AFI for host session.
 
My 2 cents.

= On=20 12-03-27 4:34 AM, "stephane.litkowski@orange.com"= <stephane.litkowski@orange.com&= gt;=20 wrote:
Rajiv,

Regarding the discussion about separation of sessions betw= een=20 transport layers.
I don't have a strong position on this, I would sa= y=20 that like for BGP, it could be fine to let each operator choose what th= ey=20 want and so both possibilities implemented.
If I compare to BGP ,= =20 sometimes we are using multi AFI/SAFI on a common transport, sometimes = we=20 are separating (especially towards customer or at inter AS).
The mai= n=20 concern I have with using one session per transport layer, is about ok,= we=20 have two LDP session, one will transport Ipv4 FEC, one will transport I= Pv6=20 FEC. But how will we control other FEC ? On which session PW FEC will b= e=20 propagated ? same for other FEC types ... In case of multiple sessions,= it s=20 important that operators may have control on FEC types transported on e= ach=20 session.

Regards,



Stephane=20 Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operati= onal=20 Engineering & Support IPTAC for RAEI network
t=E9l. +33 2 23 28 = 49=20 83
stephane.litkowski@orange.com



 
_______________________________= ___________________________________________________________________________= _______________

Ce=20 message et ses pieces jointes peuvent contenir des informations=20 confidentielles ou privilegiees et ne doivent donc
pas etre diffuses= ,=20 exploites ou copies sans autorisation. Si vous avez recu ce message par= =20 erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que= les=20 pieces jointes. Les messages electroniques etant susceptibles=20 d'alteration,
France Telecom - Orange decline toute responsabilite s= i ce=20 message a ete altere, deforme ou falsifie. Merci.

This message a= nd=20 its attachments may contain confidential or privileged information that= may=20 be protected by law;
they should not be distributed, used or copied= =20 without authorisation.
If you have received this email in error, ple= ase=20 notify the sender and delete this message and its attachments.
As em= ails=20 may be altered, France Telecom - Orange is not liable for messages that= have=20 been modified, changed or falsified.
Thank you.

_____________________________________________= __
mpls=20 mailing list
mpls@ietf.org
https://www.ietf.or= g/mailman/listinfo/mpls

--=20
Syed Kamran Raza
Technical Leader, SPRSG IOS-= XR=20 Routing (MPLS)
Cisco Systems, Inc.,
Kanata, ON, K2K 3E8, Canada Ph:=20 +1 (613) 254-4520
http://www.cisco.com=20 



___=
___________________________________________________________________________=
___________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
------_=_NextPart_002_01CD0BF8.DD6EE788-- ------_=_NextPart_001_01CD0BF8.DD6EE788 Content-Type: image/gif; name="image.gif" Content-Transfer-Encoding: base64 Content-ID: <305060609@27032012-0754> Content-Description: image.gif Content-Location: image.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01CD0BF8.DD6EE788 Content-Type: image/gif; name="image.gif" Content-Transfer-Encoding: base64 Content-ID: <305060609@27032012-075B> Content-Description: image.gif Content-Location: image-1.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01CD0BF8.DD6EE788-- From stephane.litkowski@orange.com Tue Mar 27 02:20:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC04A21F8951 for ; Tue, 27 Mar 2012 02:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_LONG=1.08, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzh85L4OWpFS for ; Tue, 27 Mar 2012 02:20:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2921F8946 for ; Tue, 27 Mar 2012 02:20:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C66BF18C388 for ; Tue, 27 Mar 2012 11:20:12 +0200 (CEST) Received: from PUEXCC21.nanterre.francetelecom.fr (unknown [10.168.72.145]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A28C935C048 for ; Tue, 27 Mar 2012 11:20:12 +0200 (CEST) Received: from PUEXCBL0.nanterre.francetelecom.fr ([10.168.74.47]) by PUEXCC21.nanterre.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:20:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CD0BFA.CFE48BA4" Date: Tue, 27 Mar 2012 11:20:11 +0200 Message-ID: <4877_1332840012_4F71864C_4877_10644_1_4FC3556A36EE3646A09DAA60429F53350804C7C2@PUEXCBL0.nanterre.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-shen-mpls-rsvp-setup-protection-00 Thread-Index: Ac0L+s99Sl0k58CRRKObadxSfPWWgg== From: To: "IETF MPLS" X-OriginalArrivalTime: 27 Mar 2012 09:20:12.0896 (UTC) FILETIME=[D05AE600:01CD0BFA] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.27.85415 Subject: [mpls] Comments on draft-shen-mpls-rsvp-setup-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:20:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0BFA.CFE48BA4 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CD0BFA.CFE48BA4" ------_=_NextPart_002_01CD0BFA.CFE48BA4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, =20 I'm wondering about the use case of this solution. Do you have some feedbacks some provider where RSVP-TE tunnel setup is an i= ssue ? =20 Globally, if you are setting up a new tunnel, it doesn't really matter if i= t takes an extra 2 or 3 seconds to establish it on a new path. Regarding an established path, FRR mechanism permit traffic to be protected= during failure inside the LSP. Path Err sent to the ingress that is recomputing a new path, if path can't = be setup because chosen path is not available (new link failure), it's not = an issue as LSP is still on FRR and traffic is fine. =20 So I don't really see the use case and the value for this enhancement. Could you explain your vision ? =20 Thanks, =20 =20 =20 Stephane Litkowski FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE Operational Engineering & Support IPTAC for RAEI network t=E9l. +33 2 23 28 49 83 stephane.litkowski@orange.com =20 =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ------_=_NextPart_002_01CD0BFA.CFE48BA4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Authors,
 
I'm wonde= ring about=20 the use case of this solution.
Do you ha= ve some=20 feedbacks some provider where RSVP-TE tunnel setup is an issue=20 ?
 
Globally,= if you are=20 setting up a new tunnel, it doesn't really matter if it takes an extra 2 or= 3=20 seconds to establish it on a new path.
Regarding= an=20 established path, FRR mechanism permit traffic to be protected during failu= re=20 inside the LSP.
Path Err = sent to the=20 ingress that is recomputing a new path, if path can't be setup because chos= en=20 path is not available (new link failure), it's not an issue as LSP is still= on=20 FRR and traffic is fine.
 
So I don'= t really=20 see the use case and the value for this enhancement.
Could you= explain=20 your vision ?
 
Thanks,
 
 
=

Stephane=20 Litkowski
FT/OF/DTF/DEX/DERX/EE IP/TAC ENTREPRISE

Operational=20 Engineering & Support IPTAC for RAEI network
t=E9l. +33 2 23 = 28 49=20 83
stephane.litkowski@orange.com=

 
_____________________________________________________=
____________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
------_=_NextPart_002_01CD0BFA.CFE48BA4-- ------_=_NextPart_001_01CD0BFA.CFE48BA4 Content-Type: image/gif; name="orange_logo.gif" Content-Transfer-Encoding: base64 Content-Description: orange_logo.gif Content-Location: http://www.orange.com/sirius/logos_mail/orange_logo.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01CD0BFA.CFE48BA4 Content-Type: image/gif; name="ampersand.gif" Content-Transfer-Encoding: base64 Content-Description: ampersand.gif Content-Location: http://www.orange.com/sirius/logos_mail/ampersand.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01CD0BFA.CFE48BA4-- From PPan@infinera.com Thu Mar 22 16:08:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295F521E801F for ; Thu, 22 Mar 2012 16:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZkVvWFy9jZJ for ; Thu, 22 Mar 2012 16:08:27 -0700 (PDT) Received: from SV-CASHT-PROD3.infinera.com (sv-casht-prod3.infinera.com [8.4.225.26]) by ietfa.amsl.com (Postfix) with ESMTP id BE1DD21E801B for ; Thu, 22 Mar 2012 16:08:27 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by SV-CASHT-PROD3.infinera.com ([::1]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 16:08:27 -0700 From: Ping Pan To: Gregory Mirsky , Rajan Rao , Biao Lu , "lufang@cisco.com" , "andrew.g.malis@verizon.com" , "zhangfatai@huawei.com" , "sam.aldrin@huawei.com" , "zhang.fei3@zte.com.cn" , "SriMohanS@Tellabs.com" Thread-Topic: Comments to draft-pan-shared-mesh-protection-04 Thread-Index: AQKjg+0sddLBwclNZfo8OSjr4iiO3JTJ9CyA Date: Thu, 22 Mar 2012 23:08:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_FEAF6B517274834CAE12C974DA17B1D903DBBBFFSVEXDBPROD2infi_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 27 Mar 2012 02:27:32 -0700 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments to draft-pan-shared-mesh-protection-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:09:34 -0000 --_000_FEAF6B517274834CAE12C974DA17B1D903DBBBFFSVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Gregory, Thanks for the questions. Sorry about the delay. See in-line Regards, Ping From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, March 20, 2012 2:40 PM To: Ping Pan; Rajan Rao; Biao Lu; lufang@cisco.com; andrew.g.malis@verizon.= com; zhangfatai@huawei.com; sam.aldrin@huawei.com; zhang.fei3@zte.com.cn; S= riMohanS@Tellabs.com Cc: mpls@ietf.org Subject: Comments to draft-pan-shared-mesh-protection-04 Dear Authors, et al., Please find my comments to the latest version below: * Section 3 "All paths are assumed to be bi-directional." Do you make distinction between: * co-routed and associated bi-directional LSP * Coordinated and independent protection mode for associated bi-dire= ctional LSP We are considering co-routed and associated bi-directional LSP's at this po= int. The key reason is that this enables us to initiate the protection swit= ching-over operation on one headend node to take care of the entire bi-dire= ctional circuits. We need to check the design and see if the existing desig= n can support coordinated LSP's. * Section 5.2 "If a sender is not getting the reply within a time i= nterval." How this time interval defined, determined. Does it have to be th= e same for both head- and tail-end of protecting path? We think that the time-out timer is a local implementation issue. Our design is the following: upon the detection of a network failure, the h= eadend node will trigger activation messages that traverse through the enti= re data path (a.k.a. LSP) to perform switch-over function on each hop. The = processing overhead on each hop should be very small - in the neighborhood = of BFD packet handling. As such, within one round-trip, the activation mess= ages should enable the completion of the entire protection switching operat= ion. Of course, the messages are transmitted as LSP packets, and could be droppe= d in data networks. In this case, the headend should detect the activation = failure, and switch to another protection path. To protect user traffic, th= e time-our interval should be small. Similar to the implementation of BFD, the implementation for Shared Mesh Pr= otection could be in software or with hardware-assistance. The processing c= omplexity at each node should be similar too. Today, one can get a commerci= al chip to support BFD processing at near wire speed, and generate one mess= age each 3.3 msec. We would think that, the protection message round trip d= elay should be well within 50msec time range. In fact, given the network to= pology, the activation interval should be fixed, if it is implemented with = hardware-assistance. The short answer is, the time-out should be nx50msec. * Section 6.1 "If the headend node is not receiving the acknowledge= ment within a time internal ..." Is this the same time interval referenced = in Section 5.2? Is there a default value for it? Perhaps it might be named = for ease of reference. Yes. Thanks. Will make the changes. Regards, Ping Thank you for your kind consideration. Regards, Greg --_000_FEAF6B517274834CAE12C974DA17B1D903DBBBFFSVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Gregory,

 <= /p>

Thanks for the questions.= Sorry about the delay.

 <= /p>

See in-line

 <= /p>

Regards,

 <= /p>

Ping

 <= /p>

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, March 20, 2012 2:40 PM
To: Ping Pan; Rajan Rao; Biao Lu; lufang@cisco.com; andrew.g.malis@v= erizon.com; zhangfatai@huawei.com; sam.aldrin@huawei.com; zhang.fei3@zte.co= m.cn; SriMohanS@Tellabs.com
Cc: mpls@ietf.org
Subject: Comments to draft-pan-shared-mesh-protection-04<= /span>

 

Dear Authors, = et al.,

Please find my= comments to the latest version below:

·         Section 3 "All paths are ass= umed to be bi-directional."

Do you make di= stinction between:

·        co-routed and associated bi-direc= tional LSP

·        Coordinated and independent prote= ction mode for associated bi-directional LSP

We are considering co-routed and associ= ated bi-directional LSP’s at this point. The key reason is that this enables us to initiate the protection switching-over operation o= n one headend node to take care of the entire bi-directional circuits. We n= eed to check the design and see if the existing design can support coordina= ted LSP’s.

 

·         Section 5.2 "If a sender is = not getting the reply within a time interval." How this time interval = defined, determined. Does it have to be the same for both head- and tail-end of protecting path?

We think that the time-out timer is a l= ocal implementation issue.

Our design is the following: upon the d= etection of a network failure, the headend node will trigger activation messages that traverse through the entire data path (a.k.a. LSP= ) to perform switch-over function on each hop. The processing overhead on e= ach hop should be very small – in the neighborhood of BFD packet hand= ling. As such, within one round-trip, the activation messages should enable the completion of the entire protect= ion switching operation.

Of course, the messages are transmitted= as LSP packets, and could be dropped in data networks. In this case, the headend should detect the activation failure, and switch to= another protection path. To protect user traffic, the time-our interval sh= ould be small.

Similar to the implementation of BFD, t= he implementation for Shared Mesh Protection could be in software or with hardware-assistance. The processing complexity at each node should= be similar too. Today, one can get a commercial chip to support BFD proces= sing at near wire speed, and generate one message each 3.3 msec. We would t= hink that, the protection message round trip delay should be well within 50msec time range. In fact, given t= he network topology, the activation interval should be fixed, if it is impl= emented with hardware-assistance.

The short answer is, the time-out shoul= d be nx50msec.

·         Section 6.1 "If the headend = node is not receiving the acknowledgement within a time internal …&qu= ot; Is this the same time interval referenced in Section 5.2? Is there a default value for it? Perhaps it might be named for ease of reference.

Yes. Thanks. Will make the changes.

Regards,<= /p>

 <= /p>

Ping

 <= /p>

Thank you for = your kind consideration.

 

  &n= bsp;     Regards,

  &n= bsp;            = ; Greg

 

--_000_FEAF6B517274834CAE12C974DA17B1D903DBBBFFSVEXDBPROD2infi_-- From bashandy@cisco.com Tue Mar 27 02:32:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB421E8126 for ; Tue, 27 Mar 2012 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JVcPEg36jPA for ; Tue, 27 Mar 2012 02:32:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7521F8925 for ; Tue, 27 Mar 2012 02:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=2880; q=dns/txt; s=iport; t=1332840756; x=1334050356; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Fjo/D0NTc6dX/NTZGtnUvtLJiixT1K5gqzralAxdjpA=; b=ZVWzN+Hjbp7CETpyZ0MYuqHdDYZmHSOWEJ6iDVGmKfkOyYUHhVBXxvI2 yRUZvKozhWlttCcd9j4nAn+oQbPaI51ItfgTfrO5vPrypTBW26cbhsAZC 5OEw401enAw7IY+p8Rg+SNDjeTdGScW4kVlXOn2b3x33MCzkTB+wiwtmq U=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="asc'?scan'208";a="69421724" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 09:32:35 +0000 Received: from [10.61.98.238] (dhcp-10-61-98-238.cisco.com [10.61.98.238]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2R9WYTj000439; Tue, 27 Mar 2012 09:32:35 GMT Message-ID: <4F71892D.8010307@cisco.com> Date: Tue, 27 Mar 2012 11:32:29 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ilya Varlashkin References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> In-Reply-To: <00e901cd0bf7$5a41ecf0$0ec5c6d0$@nobulus.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4BB3D418440567FFEE31A737" Cc: 'IETF MPLS' Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:32:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4BB3D418440567FFEE31A737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable see comment inline about P routers having VPN level knowldege Thanks Ahmed On 3/27/2012 10:55 AM, Ilya Varlashkin wrote: >> -----Original Message----- >> The best current available mechanism is BGP PIC Edge that relay on IGP= >> convergence to detect that remote PE is no longer reachable : PIC Edge= > result >> mainly depends on how fast your IGP is converging (sub sec or more). >> > I've been recently measuring convergence on not very fast RP and found = that > even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlike= ly to > be seen in many networks if in any at all. And for real-world sized net= s > convergence is like few tens of ms - not really to worry about. > =20 >> Ahmed solution is an FRR solution so doesn't rely on convergence. As s= oon > as >> a P router detects that the link to the protected PE fails, it will sw= itch > (using >> pre-programmed backup NHLFE), so there you are in FRR numbers ... 50ms= ec >> - 100msec depending of implementation ... >> > If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN,= PWE, > L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that > contradicts with original idea of P nodes (they shouldn't care what's > inside, only how to get to the edge independent of "payload"). The solution defined in draft-bashandy-bgp-edge-node-frr ensures that the core routers do NOT have VPN level knowledge. We are also working on a solution that would actually bring down the information stored in the core router to a very small number, much smaller than what is proposed in version 02 of the draft. So lookout for version 03 > >> Clearly the solution is today complex, and I hope it could be a bit > simplified :) > Because of previous statement I see proposed solution as complication r= ather > than simplification, and because of above mentioned IGP convergence tim= es > the gain seems to be too little when balanced against complexity. > =20 > /iLya > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------enig4BB3D418440567FFEE31A737 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPcYky+G19kFA5zIYRAmdFAJ9l82B54DQXt3WXz9K5OdpFJR/fKACfXUuD +HLx3JwYfcc7L10lCF9s270= =565S -----END PGP SIGNATURE----- --------------enig4BB3D418440567FFEE31A737-- From gregory.mirsky@ericsson.com Tue Mar 27 04:56:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2912621F8831 for ; Tue, 27 Mar 2012 04:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orTi5omfj9WR for ; Tue, 27 Mar 2012 04:56:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7786D21F89D0 for ; Tue, 27 Mar 2012 04:56:19 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2RBuBRl001067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Mar 2012 06:56:11 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 27 Mar 2012 07:56:10 -0400 From: Gregory Mirsky To: Huaimo Chen , "Ning.So@verizonbusiness.com" Date: Tue, 27 Mar 2012 07:56:08 -0400 Thread-Topic: Failure handling on link between PE1 and CE1 Thread-Index: AQHNC/yMAWXSR7ST1EWucyh9sOvkQZZ+BLrQ Message-ID: References: <5316A0AB3C851246A7CA5758973207D4325F31C8@dfweml505-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4325F31C8@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13550DA15ADEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Failure handling on link between PE1 and CE1 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:56:36 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13550DA15ADEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Huaimo and Ning, thank you for reminder of earlier presentation. To the beset of my understa= nding you propose to run BFD session from CE through R1 terminating it at R= a for ingress redundancy. Is that correct? I wonder whether you're planning= to run multi-hop IP BFD session and if so how you're planning to different= iate failure of CE-R1 link from, e.g. R1-Ra link failure. Would appreciate if you can explain how monitoring of CE-R1 link would be a= ddressed in MPLS-TP networks. Would it be LMP or Performance Measurement us= ed (Section 4.4 third para)? Besides, what are security implications of having IP connectivity between C= E and LSRs in case of MPLS-TE netwok. I've noticed that neither document ha= s Security Considerations section in it. Regards, Greg ________________________________ From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Tuesday, March 27, 2012 2:33 AM To: Gregory Mirsky Subject: Failure handling on link between PE1 and CE1 Regarding to how to handle the failure of the link between PE1 and CE1, whi= ch you asked today, The handling of failure on the link between PE1 and CE1 was presented by Ni= ng So in IETF 81. The slides from IETF 81 proceeding is below. http://www.ietf.org/proceedings/81/slides/mpls-7.pdf Regards, Huaimo _____________________________________________ From: Huaimo Chen Sent: Monday, March 26, 2012 6:15 PM To: 'Gregory Mirsky'; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@k= ddilabs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 See my answers (marked by [[Huaimo Chen]] (2nd Round):) inline below. Regards, Huaimo [rtfimage://] From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, March 24, 2012 8:47 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 Dear Huaimo, et al, please find my notes in-lined tagged by GIM>>. Regards, Geg [rtfimage://] From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, March 23, 2012 9:12 AM To: Gregory Mirsky; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kdd= ilabs.jp Cc: mpls@ietf.org Subject: RE: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and dra= ft-chen-mpls-p2mp-eggress-protection-05 See my answers inline below. Regards, Huaimo [rtfimage://] From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, March 21, 2012 10:56 AM To: Huaimo Chen; Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddila= bs.jp Cc: mpls@ietf.org Subject: Comments to draft-chen-mpls-p2mp-ingress-protection-05 and draft-c= hen-mpls-p2mp-eggress-protection-05 Dear Authors, et al., Please find my questions to changes in the latest versions below. On draft-chen-mpls-p2mp-ingress-protection-05 * Introduction "The first method is a one-to-one backup method, where a detour backup P2P LSP for each protected P2P LSP is created at each potential point of local repair, which is an intermediate node between the ingress node and the egress node of the protected LSP." I think that your definition excludes ingress node as PLR by saying "potent= ial point of local repair, which is an intermediate node ...". In fact, any= node, except for egress LER of course, can be PLR if a detour LSP can be c= reated. [[Chen,Huaimo]] Will be rephrased. * Section 4.1 "The time for switching the traffic after= R1 fails is within tens of milliseconds." I don't see what supports this s= tatement. I think that switchover depends on LOC detection by Ra and intern= al processing. The former, BFD interval and DetectMultiplier, i.e. operator= selected configuration parameters, would determine only part of switchover= performance whereas second part is implementation specific and would likel= y depends on number of streams Ra and R1 share. [[Chen,Huaimo]] This is a local protection. Backup ingress node Ra detects = failures in primary ingress node R1 through using the same technical such a= s BFD as an intermediate node as a PLR detects failures in its next hop nod= e for FRR. If an intermediate node can switch the traffic within tens of mi= lliseconds after its next hop node fails, why not backup ingress Ra? GIM>> Firstly, Ra would not distinguish between R1 failure and failure of t= he link between Ra and R1. Hence we might have false positives. [[Chen,Huaimo]] (2nd Round): A few of people mentioned this special case be= fore; we had considered it and discussed a few of possible solutions. Secondly, PLR detects failure of immediate link and local protection might = be of two kinds - link and node. You're not protecting link but try to prot= ect an upstream node. This is not Local Protection per RFC 4090. [[Chen,Huaimo]] (2nd Round): RFC 4090 describes the local protection for th= e links and intermediate nodes of a TE LSP. It does not specify any local p= rotection for the ingress node of a TE LSP. Thus (of course) this ingress l= ocal protection is not the local protection per RFC 4090. The ingress LOCAL protection detects the failure of the ingress node of the= TE LSP LOCALLY (i.e., the failure of the ingress node is detected by the b= ackup ingress node one hop away) and repairs the failure of the ingress nod= e LOCALLY. Thus if a PLR (node) can switch the traffic within tens of milli= seconds after its next hop node (an intermediate node) fails, the backup in= gress node (e.g., Ra) can do the same (switch the traffic within tens of mi= lliseconds after the ingress node fails). * Section 4.4 "In the GMPLS networks where the control plane and data plane are physically separated, the detection and localization of failures in the physical layer can be achieved by introducing the link management protocol (LMP) or assisting by performance monitoring devices." I assume you refer to MPLS-TP network in this paragraph. I think that it is= not clear: * on which links you recommend to run LMP or PM * what would constitute failure particularly in case of PM being use= d * how failure detection will trigger protection switchover [[Chen,Huaimo]] Some details may be added. * Section 5 "However, there is not any standard that locally protects the ingress of the P2MP LSP. The ingress local protection mechanism described above fills this gap." I think that the document describes redundancy, not ingress protection. [[Chen,Huaimo]] What are your definitions of redundancy and protection? GIM>> This is very good question and I'm glad we came to its discussion (pe= rhaps we can use some time at the meeting to it). IMO, need to differentiat= e between transport and service. Transport protection assumes single connec= tion to client whereas service protection might have redundant connection (= multi-homed). I think that one practical example is PW redundancy http://to= ols.ietf.org/html/draft-ietf-pwe3-redundancy-06. And I'll note that case in= Section 3.2.3 Single-homed CE with MS-PW redundancy can be viewed as MS-PW= e2e Linear Protection. [[Chen,Huaimo]] (2nd Round): In this case, the question you asked here this= time is similar or equivalent to the question you asked in previous IETF m= eetings, which is what are the differences between the PW redundancy and th= e ingress local protection. There are a number of differences between the PW redundancy and the ingress= local protection. At first, a PW and a TE LSP are different. There is a PW working group in w= hich people work on the PW related work and there is a MPLS working group i= n which people work on TE LSP related work. Secondly, a PW is not at the same level as a TE LSP. The level of a PW is h= igher than the level of a TE LSP. Moreover, (more critically) the method of ingress local protection describe= d in our draft is different from the method of PW redundancy specified in h= ttp://tools.ietf.org/html/draft-ietf-pwe3-redundancy-06 even though we assu= me that a PW and a TE LSP are the same type of tunnel (of a generic thing). On draft-chen-mpls-p2mp-eggress-protection-05: * Introduction "The receiver selects the egress or backup egrss node for receiving the traffic according to the route to the source through RPF. In a normal situation, it selects the egress node. When the egress node fails, it selects the backup egress for receiving the traffic since the route to the source through the egress node is gone and the route to the source through the backup egress node is active." I think that this clearly describes behavior of redundant connection to CE,= 1+1 redundancy. The proposed in the document is nevertheless is based on re= dundant connection of CE. * Same as for Section 4.1 * Same as for Section 4.4 * Same as for Section 5 [[Chen,Huaimo]] Same as or similar to the answers above. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13550DA15ADEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Huaimo and Ning,
thank you for reminder of earlier presentation. = To the=20 beset of my understanding you propose to run BFD session from CE through R1= =20 terminating it at Ra for ingress redundancy. Is that correct? I wonder whet= her=20 you're planning to run multi-hop IP BFD session and if so how you're planni= ng to=20 differentiate failure of CE-R1 link from, e.g. R1-Ra link=20 failure.
Would appreciate if you can explain how monitori= ng of=20 CE-R1 link would be addressed in MPLS-TP networks. Would it be LMP or=20 Performance Measurement used (Section 4.4 third para)?
Besides, what are security implications of havin= g IP=20 connectivity between CE and LSRs in case of MPLS-TE netwok. I've noticed th= at=20 neither document has Security Considerations section in it.
 
    Regards,
       =20 Greg
From: Huaim= o Chen=20 [mailto:huaimo.chen@huawei.com]
Sent: Tuesday, March 27, 2012 2:= 33=20 AM
To: Gregory Mirsky
Subject: Failure handling on link= =20 between PE1 and CE1

Regarding to how to handle the failure of the li= nk=20 between PE1 and CE1, which you asked today,
 
The handling of failure on the link between PE1 = and CE1=20 was presented by Ning So in IETF 81.
The slides from IETF 81 proceeding is=20 below.
 
 
Regards,
Huaimo
_____________________________________________
= From:=20 Huaimo Chen
Sent: Monday, March 26, 2012 6:15 PM
To:=20 'Gregory Mirsky'; Ning.So@verizonbusiness.com; femi@cisco.com;=20 le-liu@kddilabs.jp
Cc: mpls@ietf.org
Subject: RE: Comme= nts=20 to draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05
 
See my answers (marked by [[Huaimo Chen]]<= /I>=20 (2nd Round):) inline below.
 
Regards,
Huaimo
From:<= /B> Gregory=20 Mirsky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Saturday, March 24, 2012 8:47 AM
To: Huaimo Chen= ;=20 Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddilabs.jp
Cc:=20 mpls@ietf.org
Subject: RE: Comments to=20 draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05
 
Dear=20 Huaimo, et al,
please=20 find my notes in-lined tagged by GIM>>.
 
    Regards,
        Geg
 
From: Huaimo Chen [mailto:huaimo.chen@huawei.com]=20
Sent: Friday, March 23, 2012 9:12 AM
To: Gregory Mirsk= y;=20 Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddilabs.jp
Cc:=20 mpls@ietf.org
Subject: RE: Comments to=20 draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05
See my answers inline below.
 
Regards,
Huaimo
From:<= /B> Gregory=20 Mirsky [mailto:gregory.mirsky@ericsson.= com]=20
Sent: Wednesday, March 21, 2012 10:56 AM
To: Huaimo Ch= en;=20 Ning.So@verizonbusiness.com; femi@cisco.com; le-liu@kddilabs.jp
Cc:=20 mpls@ietf.org
Subject: Comments to=20 draft-chen-mpls-p2mp-ingress-protection-05 and=20 draft-chen-mpls-p2mp-eggress-protection-05
 
Dear Autho= rs, et=20 al.,
Please fin= d my=20 questions to changes in the latest versions below.
On=20 draft-chen-mpls-p2mp-ingress-protection-05
·        &n= bsp;           =20 Introduction
 &nbs= p; "The=20 first method is a one-to-one backup method, where
 &nbs= p; a detour=20 backup P2P LSP for each protected P2P LSP is created at each<= /DIV>
 &nbs= p;=20 potential point of local repair, which is an intermediate=20 node
 &nbs= p; between=20 the ingress node and the egress node of the protected LSP."
I think th= at your=20 definition excludes ingress node as PLR by saying "potential point of local= =20 repair, which is an intermediate node ...". In fact, any node, except for e= gress=20 LER of course, can be PLR if a detour LSP can be created.
[[Chen,Huaimo]] Will be rephrased.=20
·        &n= bsp;           =20 Section 4.1 "The time for switching the tr= affic=20 after R1 fails is within tens of milliseconds." I don't see what supports t= his=20 statement. I think that switchover depends on LOC detection by Ra and inter= nal=20 processing. The former, BFD interval and DetectMultiplier, i.e. operator=20 selected configuration parameters, would determine only part of switchover= =20 performance whereas second part is implementation specific and would likely= =20 depends on number of streams Ra and R1 share.
[[Chen,Huaimo]] This is a lo= cal=20 protection. Backup ingress node Ra detects failures in primary ingress node= R1=20 through using the same technical such as BFD as an intermediate node as a P= LR=20 detects failures in its next hop node for FRR. If an intermediate node can= =20 switch the traffic within tens of milliseconds after its next hop node fail= s,=20 why not backup ingress Ra? 
GIM>> Firstly, Ra= would=20 not distinguish between R1 failure and failure of the link between Ra and R= 1.=20 Hence we might have false positives.
[[Chen,Huaimo]] (2nd Round): A few of p= eople=20 mentioned this special case before; we had considered it and discussed a fe= w of=20 possible solutions.
Secondly, PLR detects failur= e of=20 immediate link and local protection might be of two kinds - link and node.= =20 You're not protecting link but try to protect an upstream node. This is not= =20 Local Protection per RFC 4090.
[[Chen,Huaimo]] (2nd Round): RFC 4090=20 describes the local protection for the links and intermediate nodes of a TE= LSP.=20 It does not specify any local protection for the ingress node of a TE LSP. = Thus=20 (of course) this ingress local protection is not the local protection per R= FC=20 4090.
The=20 ingress LOCAL protection detects the failure of the ingress node of the TE = LSP=20 LOCALLY (i.e., the failure of the ingress node is detected by the backup in= gress=20 node one hop away) and repairs the failure of the ingress node LOCALLY. Thu= s if=20 a PLR (node) can switch the traffic within tens of milliseconds after its n= ext=20 hop node (an intermediate node) fails, the backup ingress node (e.g., Ra) c= an do=20 the same (switch the traffic within tens of milliseconds after the ingress = node=20 fails).
·        &n= bsp;           =20 Section 4.4
 &nbs= p; "In the=20 GMPLS networks where the control plane and data plane are
 &nbs= p;=20 physically separated, the detection and localization of failures=20 in
 &nbs= p; the=20 physical layer can be achieved by introducing the link=20 management
 &nbs= p; protocol=20 (LMP) or assisting by performance monitoring devices."
I assume y= ou refer to=20 MPLS-TP network in this paragraph. I think that it is not=20 clear:
·      = ; =20 on which links you recommend to run LMP or= =20 PM
·      = ; =20 what would constitute failure particularly= in=20 case of PM being used
·      = ; =20 how failure detection will trigger protect= ion=20 switchover
[[Chen,Huaimo]] Some details= may be=20 added.
·        &n= bsp;           =20 Section 5
 &nbs= p;=20 "However, there is not any standard that locally
 &nbs= p; protects=20 the ingress of the P2MP LSP.  The ingress local=20 protection
 &nbs= p;=20 mechanism described above fills this gap."
I think th= at the=20 document describes redundancy, not ingress protection.
[[Chen,Huaimo]] What are your definitions o= f=20 redundancy and protection? 
GIM>> This is very good question= and=20 I'm glad we came to its discussion (perhaps we can use some time at th= e=20 meeting to it). IMO, need to differentiate between transport and= =20 service. Transport protection assumes single connection to client wher= eas=20 service protection might have redundant connection (multi-homed). I think t= hat=20 one practical example is PW redundancy = http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-06= .=20 And I'll note that case in Section 3.2.3 Single-homed CE with MS-PW redunda= ncy=20 can be viewed as MS-PW e2e Linear Protection.
 
[[Chen,Huaimo]] (2nd=20 Round): In this case, the question you asked here this = time=20 is similar or equivalent to the question you asked in previous IETF meeting= s,=20 which is what are the differences between the PW redundancy and the ingress= =20 local protection.
 
There are a number of differences between t= he PW=20 redundancy and the ingress local protection.
At first, a PW and a TE LSP are different. = There=20 is a PW working group in which people work on the PW related work and there= is a=20 MPLS working group in which people work on TE LSP related=20 work.
Secondly, a PW is not at the same level as = a TE=20 LSP. The level of a PW is higher than the level of a TE=20 LSP.
Moreover, (more critically) the method of i= ngress=20 local protection described in our draft is different from the method of PW= =20 redundancy specified in http://tools.ietf.org/html/draft-ietf-pwe3-redundancy= -06 even though we assume that a PW an= d a TE=20 LSP are the same type of tunnel (of a generic=20 thing).
 
On=20 draft-chen-mpls-p2mp-eggress-protection-05:
·        &n= bsp;           =20 Introduction
 &nbs= p; "The=20 receiver selects the egress or backup egrss node for=20 receiving
 &nbs= p; the=20 traffic according to the route to the source through RPF.  In=20 a
 &nbs= p; normal=20 situation, it selects the egress node.  When the egress=20 node
 &nbs= p; fails,=20 it selects the backup egress for receiving the traffic since<= /DIV>
 &nbs= p; the=20 route to the source through the egress node is gone and the=20 route
 &nbs= p; to the=20 source through the backup egress node is active."
I think th= at this=20 clearly describes behavior of redundant connection to CE,1+1 redundancy. Th= e=20 proposed in the document is nevertheless is based on redundant connection o= f=20 CE.
·        &n= bsp;           =20 Same as for Section=20 4.1
·        &n= bsp;           =20 Same as for Section=20 4.4
·        &n= bsp;           =20 Same as for Section 5=
[[Chen,Huaimo]] Same as or s= imilar to=20 the answers above.
 
       =20 Regards,
        &= nbsp;      =20 Greg
 
 
--_000_FE60A4E52763E84B935532D7D9294FF13550DA15ADEUSAACMS0715e_-- From sboutros@cisco.com Tue Mar 27 05:56:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8276121E81E3 for ; Tue, 27 Mar 2012 05:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO-lwO0EDWgJ for ; Tue, 27 Mar 2012 05:56:06 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD121E818A for ; Tue, 27 Mar 2012 05:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sboutros@cisco.com; l=336; q=dns/txt; s=iport; t=1332852966; x=1334062566; h=date:to:from:subject:cc:in-reply-to:references: mime-version:message-id; bh=aNV6vk/nd9pSxRx2nXdtKE6CIJ6U3eWwI/GCH/X8Dbw=; b=iCNXORAd9A3YqRwu3+rZiYLugsO1ib6sDA1BHwRUD0FpOsAaukBLnbgp OINYBLwOx04qaM6eFip12VvI0+pA5mnL0UWwRuDnKbtPX7cJsDF3TViLL FCilqE9MCb8UFRYeRAVAbE3FOxZKeXplogLV0uh8XsYmCFTy+ARxAzta+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHi4cU+rRDoH/2dsb2JhbABEiFCvcIEHggoBAQQSASUCPxAHOhAZPgY1h2cBmmifE5EPBIhYm06BaIMH X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="37753938" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Mar 2012 12:56:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2RCu6SZ015138; Tue, 27 Mar 2012 12:56:06 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 05:56:06 -0700 Received: from sboutros-wxp01.ciswco.com ([10.21.168.106]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2012 05:56:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Mar 2012 05:55:26 -0700 To: Kireeti Kompella From: Sami Boutros In-Reply-To: <859E7D41-481D-4941-A78F-4B5768864CB8@juniper.net> References: <201008030024.o730OPqj027604@harbor.orleans.occnc.com> <859E7D41-481D-4941-A78F-4B5768864CB8@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2012 12:56:06.0012 (UTC) FILETIME=[F9038BC0:01CD0C18] Cc: "mpls@ietf.org" Subject: [mpls] draft-ietf-mpls-entropy-label-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:56:07 -0000 Hi Kireeti, I have one question about your presentation today. With the ELI + EL under the tunnel label and above the AL, does that mean that all transient LSRs now while doing a label swap operation need to see if the label below the label to be swapped is an ELI and if so use the EL to pick the path? Thanks, Sami From Internet-Drafts@ietf.org Tue Mar 27 07:16:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844C21F8842; Tue, 27 Mar 2012 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFvZMWjukfJY; Tue, 27 Mar 2012 07:16:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102521F8836; Tue, 27 Mar 2012 07:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327141652.8537.24207.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 07:16:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-temporal-hitless-psm-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:16:55 -0000 --NextPart 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 : Temporal and hitless path segment monitoring Author(s) : M. Paul, et al Filename : draft-ietf-mpls-tp-temporal-hitless-psm Pages : 15 Date : March 27, 2012 The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-temporal-hitless-psm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-temporal-hitless-psm"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-27071652.I-D@ietf.org> --NextPart-- From yshen@juniper.net Tue Mar 27 07:28:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2277A21F8902 for ; Tue, 27 Mar 2012 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bD6GSJ7Bir4 for ; Tue, 27 Mar 2012 07:28:39 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id C8C1621F85CC for ; Tue, 27 Mar 2012 07:27:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HOY0WftBFxSfbEbf55NGtYsSKM165E@postini.com; Tue, 27 Mar 2012 07:28:38 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 07:27:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 27 Mar 2012 10:26:52 -0400 From: Yimin Shen To: Huaimo Chen , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Date: Tue, 27 Mar 2012 10:26:50 -0400 Thread-Topic: comments on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac0JGTG4v7yHr4wFQ/e3Na8ErxEObwAEkhnAAL1yggA= Message-ID: References: <5316A0AB3C851246A7CA5758973207D4325F26E7@dfweml505-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4325F26E7@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C70D32BBA0EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:28:42 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C70D32BBA0EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Huaimo, The following items from your clarification for my comment [1] and [3] may = impact the applicability of the draft. - The primary ingress node should be directly connected to the backup in= gress node. That is that the primary ingress node and the backup ingress no= de should be one hop away. - If the backup ingress node can not do CSPF, it should have a way to ge= t a path. For example, PCE may be used to compute the path. In a normal sit= uation, how does a router without CSPF capability get a protection path sat= isfying a given set of constraints? Two more comments: [7] TE constraints for CSPF on backup ingress PE Are the TE constraints used by a backup ingress PE for CSPF same or differe= nt than those used by the primary ingress PE? Either case, how does a backup ingress PE know about the TE constraints ? T= he "LSP info" message is basically a copy of Path message of the primary P2= MP LSP, and it contains only bandwidth info. What about other TE constraint= s that the backup PE must consider ? [8] Reversion Please describe all possible revertive modes. I have the following concern,= as the reversion would be driven by the two PEs, rather than a single CE. When the primary ingress PE is restored, it will make an independent decisi= on to start forwarding traffic again over the primary P2MP LSP. Likewise, t= he backup ingress PE will detect the active state of the primary PE and mak= e an independent decision to stop forwarding traffic. It seems unavoidable = that there would be a window where both PEs are forwarding traffic at the s= ame time. This would generate duplicate traffic in the network. How do you = handle such kind of scenario ? Thanks, -Yimin Shen Juniper Networks From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, March 23, 2012 4:05 PM To: Yimin Shen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: RE: comments on draft-chen-mpls-p2mp-ingress-protection See my answers inline below. Regards, Huaimo ________________________________ From: Yimin Shen [mailto:yshen@juniper.net] Sent: Friday, March 23, 2012 1:20 PM To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: comments on draft-chen-mpls-p2mp-ingress-protection Authors, I have following comments for this draft. The draft allows a primary ingress router to send an "LSP info" message to = a backup ingress to set up a backup p2mp LSP. This message defines the leaf= nodes and the set of must-traverse intermediate nodes (i.e. the set of 1st= hops of the primary p2mp LSP) for the backup p2mp LSP. [1] Security The creation of backup p2mp LSP is purely based on an external message. Sec= urity must be addressed. [[Chen,Huaimo]] The primary ingress node and the backup ingress node are in= the same trusted network. Normally the backup ingress node is directly con= nected to the primary ingress node. The LSP info message that the backup in= gress node receives is from the primary ingress node, which is in the same = trusted network as the backup ingress node. It seems that there is not any = security issue in this case. It is unclear in the draft whether a primary ingress and a backup ingress m= ust be one hop away from each other, or may be multi hops away. [[Chen,Huaimo]] The primary ingress node should be directly connected to th= e backup ingress node. That is that the primary ingress node and the backup= ingress node should be one hop away. [2] P2P LSPs If the mechanism can apply to p2p LSPs, as claimed, it needs to be addresse= d in detail. [[Chen,Huaimo]] Some details may be added in the next version. [3] CSPF It assumes that the backup ingress can do path computation, e.g. CSPF. What= if it cannot? This would affect applicability. [[Chen,Huaimo]] If the backup ingress node can not do CSPF, it should have = a way to get a path. For example, PCE may be used to compute the path. In a= normal situation, how does a router without CSPF capability get a protecti= on path satisfying a given set of constraints? [4] Debuggability Once a the primary ingress has sent a "LSP info" message to a backup ingres= s, there is no way for the primary ingress to learn the existence or succes= s/failure/error state of the backup P2MP LSP. There needs to be some mechanism, such as notification to primary ingress, = to facilitate trouble shooting. [[Chen,Huaimo]]This will be considered. [5] No explicit teardown message Please consider an explicit teardown message that a primary ingress can sen= d to tear down the backup LSP. Time-out based mechanism may be too slow. [[Chen,Huaimo]] It seems that time is critical here. [6] Merge point behavior Detail about merge point behavior: How to distinguish primary LSP and backup LSP; How to handle and propagate ResvTear and PathErr received from downstream; [[Chen,Huaimo]] Some details may be added in the next version. Thanks, -Yimin Shen Juniper Networks Thanks, -Yimin --_000_DF7F294AF4153D498141CBEFADB17704C70D32BBA0EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Huaimo,

 

The following items from your clarification fo= r my comment [1] and [3] may impact the applicability of the draft.

 

-    The primary in= gress node should be directly connected to the backup ingress node. That is= that the primary ingress node and the backup ingress node should be one ho= p away.

-   = If the backup ingress node can not do CSPF, it = should have a way to get a path. For example, PCE may be used to compute th= e path. In a normal situation, how does a router without CSPF capability ge= t a protection path satisfying a given set of constraints?

 

Two more comments:

 

[7]= TE constraints for CSPF on backup ingress PE

 

Are the TE constraints used by a backup ingress PE for CSPF same or differ= ent than those used by the primary ingress PE?  

=

 

Either case, how does a backup ingress PE know about the TE constr= aints ? The “LSP info” message is basically a copy of Path mess= age of the primary P2MP LSP, and it contains only bandwidth info. What abou= t other TE constraints that the backup PE must consider ?=

 

[8] Reversion

 

Please describe al= l possible revertive modes. I have the following concern, as the reversion = would be driven by the two PEs, rather than a single CE.<= /p>

 

When the primary ingress PE is restored, it will make an indepe= ndent decision to start forwarding traffic again over the primary P2MP LSP.= Likewise, the backup ingress PE will detect the active state of the primar= y PE and make an independent decision to stop forwarding traffic. It seems = unavoidable that there would be a window where both PEs are forwarding traf= fic at the same time. This would generate duplicate traffic in the network.= How do you handle such kind of scenario ?

 

Thanks,

 

-Yimin Shen

<= p class=3DMsoNormal> 

Juniper Networks

<= o:p> 

 

 

 

<= p class=3DMsoNormal>From: Huaimo Chen [mailto:huaimo.chen@huawei.com]
= Sent: Friday, March 23, 2012 4:05 PM
To: Yimin Shen; draft-ch= en-mpls-p2mp-ingress-protection@tools.ietf.org
Cc: mpls@ietf.org<= br>Subject: RE: comments on draft-chen-mpls-p2mp-ingress-protection =

 

See my answers inline belo= w.

 

Re= gards,

Huaimo

From: Yimin Shen [mailto:yshen@juniper.net]
Sent: F= riday, March 23, 2012 1:20 PM
To: draft-chen-mpls-p2mp-ingress-pr= otection@tools.ietf.org
Cc: mpls@ietf.org
Subject: comm= ents on draft-chen-mpls-p2mp-ingress-protection

 

Authors,

 

=

= I have following comments for this draft.

<= p class=3DMsoNormal>&= nbsp;

The draft allows a primary ingress ro= uter to send an "LSP info" message to a backup ingress to set up = a backup p2mp LSP. This message defines the leaf nodes and the set of must-= traverse intermediate nodes (i.e. the set of 1st hops of the primary p2mp L= SP) for the backup p2mp LSP.

 

[1] Security

&nbs= p;

The creation of backup p2mp LSP is purel= y based on an external message. Security must be addressed.

 

[[Chen,Huaimo= ]] The primary ingress node and the backup ingress node are in the same tru= sted network. Normally the backup ingress node is directly connected to the= primary ingress node. The LSP info message that the backup ingress node re= ceives is from the primary ingress node, which is in the same trusted netwo= rk as the backup ingress node. It seems that there is not any security issu= e in this case.

=  

It is unclear in the draft whether a primary ingress and = a backup ingress must be one hop away from each other, or may be multi hops= away.

 

[[Chen,Huaimo]] The primary ingress node should be directly conne= cted to the backup ingress node. That is that the primary ingress node and = the backup ingress node should be one hop away.

 

[2] P2P LSPs=

 

If the mechani= sm can apply to p2p LSPs, as claimed, it needs to be addressed in detail.

 

[[Chen,Huaimo]] Some details may be added in the next version.<= /span>

 

[3] CSP= F

 

It= assumes that the backup ingress can do path computation, e.g. CSPF. What i= f it cannot? This would affect applicability.

 

[[Chen,Huaimo]] If the back= up ingress node can not do CSPF, it should have a way to get a path. For ex= ample, PCE may be used to compute the path. In a normal situation, how does= a router without CSPF capability get a protection path satisfying a given = set of constraints?

 

[4] Debuggability

=

=  

Once a the primary ingress has sent = a "LSP info" message to a backup ingress, there is no way for the= primary ingress to learn the existence or success/failure/error state of t= he backup P2MP LSP.

<= span style=3D'font-size:10.0pt;font-family:Consolas'> 

 =

There needs to be some mechanism, such as notification to pr= imary ingress, to facilitate trouble shooting.

 

[[Chen,Huaim= o]]This will be considered.

 

[5] No explicit teardown message<= /span>

 

Please consider= an explicit teardown message that a primary ingress can send to tear down = the backup LSP. Time-out based mechanism may be too slow.=

 

[[Chen,Huaimo]]= It seems that time is critical here.

 

[6] Merge point behavior

 

Detail abou= t merge point behavior:

How to distinguish = primary LSP and backup LSP;

How to handle a= nd propagate ResvTear and PathErr received from downstream;

 

 

[[Chen,Huaimo]] Some details may be added in the = next version.

 =

Thanks,

 

-Yimin Shen

 <= /o:p>

Juniper Networks

 

 

 

 

Thanks,

 

-Yimi= n

 

&n= bsp;

 <= /o:p>

 

= --_000_DF7F294AF4153D498141CBEFADB17704C70D32BBA0EMBX01WFjnprn_-- From Internet-Drafts@ietf.org Tue Mar 27 08:59:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8F21E8087; Tue, 27 Mar 2012 08:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo-AuP2fLfq7; Tue, 27 Mar 2012 08:59:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE01321E81D1; Tue, 27 Mar 2012 08:59:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327155908.16716.79004.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 08:59:08 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-temporal-hitless-psm-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:59:09 -0000 --NextPart 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 : Temporal and hitless path segment monitoring Author(s) : Y. Koike, et al Filename : draft-ietf-mpls-tp-temporal-hitless-psm Pages : 15 Date : March 27, 2012 The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-temporal-hitless-psm-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-temporal-hitless-psm"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-27085908.I-D@ietf.org> --NextPart-- From bashandy@cisco.com Wed Mar 28 03:17:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BE821F859A for ; Wed, 28 Mar 2012 03:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JotirH81H+B4 for ; Wed, 28 Mar 2012 03:17:34 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5E21F858E for ; Wed, 28 Mar 2012 03:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bashandy@cisco.com; l=6759; q=dns/txt; s=iport; t=1332929854; x=1334139454; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=p04R3cBVEdXSirJXOE4EHGd78EMfby8ZsS2LVSa1uQk=; b=bgKQPYZP9cPkGXzE8rxLloJIcc4c9uHqP1kQIs3yKx5jxYahbn/vZIII ktiVooEbOPV7d/o0btAmHJDCcKr3QEIvDvA2N/4vBohNRjfTd1dU/DBPH LOLsWB8Vhqjpwx7OffbEVT+iRGdFqkYhu9Sm50W8CnhFj07fQnJWW8mnP k=; X-Files: signature.asc : 251 X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="asc'?scan'208";a="69529553" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Mar 2012 10:17:22 +0000 Received: from [10.55.80.154] (dhcp-10-55-80-154.cisco.com [10.55.80.154]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2SAHKQU032667; Wed, 28 Mar 2012 10:17:20 GMT Message-ID: <4F72E529.4030800@cisco.com> Date: Wed, 28 Mar 2012 12:17:13 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: stephane.litkowski@orange.com References: <00df01cd0bf0$c184e0e0$448ea2a0$@nobulus.com> <11890_1332836453_4F717865_11890_2367_6_4FC3556A36EE3646A09DAA60429F53350804C705@PUEXCBL0.nanterre.francetelecom.fr> <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> In-Reply-To: <17281_1332838526_4F71807E_17281_577_1_4FC3556A36EE3646A09DAA60429F53350804C77B@PUEXCBL0.nanterre.francetelecom.fr> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA89D333F201B44AB40D6FEFA" Cc: IETF MPLS Subject: Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 10:17:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA89D333F201B44AB40D6FEFA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The basic idea behind any (IP)FRR mechanism is to have the repairing node per-calculate the repair path and be directly connected to the failure point. This allows the repairing node can make quick and small local modification to the FIB so that traffic gets re-routed over the per-calculated repair path within a guaranteed recovery period This draft, just like all (IP)FRR drafts (including those that protect multicast traffic), addresses the case of the repairing node being adjacent to failing network element. Detecting a remote failure is really beyond the scope Thanks Ahmed On 3/27/2012 10:55 AM, stephane.litkowski@orange.com wrote: > I totally agree with your point as if the P router is not directly conn= ected to the protected PE, the solution doesn't bring any improvement com= pared to PIC Edge. > The solution as a value for a repairing P connnected to the PE and so d= etecting the failure immediately. > If the repairing P is remote to the failure, we are no more in a FRR ca= se ... And I think this should be prevented ... > > -----Message d'origine----- > De : Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 > Envoy=E9 : mardi 27 mars 2012 10:44 > =C0 : LITKOWSKI Stephane DTF/DERX > Cc : Ilya Varlashkin; IETF MPLS > Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation > > Hi, > > The switchover AFTER the failure has been detected in both cases is: > Prefix independent - ie no RIB->FIB interactions Sub 100ms for reasonab= le number of primary/backup pairs > > So the real issue here is reliable and fast failure notification! > > As for this draft - if the repairing P router is not directly connected= to the primary PE it is subject to the same limitations and would initia= te switchover on either multihop BFD down or IGP convergence. > Even though it is presumably closer to the failure than ingress PE and = could react faster IMHO the complexity introduced is rather significant c= ompared to the gain. > > Regards, > Jeff > > On Mar 27, 2012, at 10:21 AM, "stephane.litkowski@orange.com" wrote: > >> Ilya, >> >> The best current available mechanism is BGP PIC Edge that relay on IGP= convergence to detect that remote PE is no longer reachable : PIC Edge r= esult mainly depends on how fast your IGP is converging (sub sec or more)= =2E >> >> Ahmed solution is an FRR solution so doesn't rely on convergence. As s= oon as a P router detects that the link to the protected PE fails, it wil= l switch (using pre-programmed backup NHLFE), so there you are in FRR num= bers ... 50msec - 100msec depending of implementation ... >> >> Clearly the solution is today complex, and I hope it could be a bit=20 >> simplified :) >> >> Regards, >> >> Stephane >> >> >> -----Message d'origine----- >> De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part=20 >> de Ilya Varlashkin Envoy=E9 : mardi 27 mars 2012 10:08 =C0 : IETF MPLS= =20 >> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation >> >> Ahmed, Kamran, >> >> as first expressed at the mic during MPLS session, I'd like to ask you= for a clarification of the motivation behind the draft. You say that thi= s draft will provide faster switch-over/fail-over time compare to anythin= g already existing today. Do you have some numbers for comparison? >> >> /iLya >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> ______________________________________________________________________= >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'al= teration, France Telecom - Orange decline toute responsabilite si ce mess= age a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and= delete this message and its attachments. >> As emails may be altered, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a et= e altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for mes= sages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --------------enigA89D333F201B44AB40D6FEFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPcuUu+G19kFA5zIYRAoVdAJ9gf7Ip/vIkKNPv7y724sIjPyKV1gCbBIYR utn1Rf4qq6dDhYIYG4/VVNI= =u8pc -----END PGP SIGNATURE----- --------------enigA89D333F201B44AB40D6FEFA-- From mustapha.aissaoui@alcatel-lucent.com Wed Mar 28 12:56:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7397121E8108 for ; Wed, 28 Mar 2012 12:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.319 X-Spam-Level: X-Spam-Status: No, score=-9.319 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj3IY0r2J965 for ; Wed, 28 Mar 2012 12:56:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A76FE21E80A5 for ; Wed, 28 Mar 2012 12:56:30 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q2SJuSXG024393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 14:56:28 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2SJuM3i001764 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Mar 2012 14:56:28 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 28 Mar 2012 14:56:26 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" Date: Wed, 28 Mar 2012 14:56:24 -0500 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdAB0mgbIAIJkWAAAyG5R5A= Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5A08BB0@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA195@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C079FA195@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:56:33 -0000 Hi Rajiv, I am afraid we are not making progress on the technical questions I raised = on this draft. For the benefit of everyone else on the mailing list, I am going to state t= he main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. Thi= s proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) whic= h can be resolved in the datapath over a given link based on the type of th= e control plane adjacency (IPv4 or IPv6) established over that link. This c= oupling of FEC resolution to the type of control plane adjacency is not cor= rect and breaks so many things in RFC 5036. In RFC 5036, the ability to res= olve a FEC type between peers is independent of the adjacency established. In addition, this proposal now means that we need 2 link Hello adjacencies = over each link and 2 targeted Hello adjacencies between any two LSR nodes. = This is not good from a scaling perspective while it provides no gain. In an earlier exchange on this thread, we discussed the need for introducin= g per Hello adjacency capability negotiation to address the probem of which= FEC types can be resolved over a given link adjacency. That is the correct= approach to the problem and we should keep the behaviour of RFC 5036 as is= , that is an IPv4 link Hello adjacency will bootstrap an IPv4 LDP session a= nd an IPv6 link adjacency will bootstrap an IPv6 LDP session. There is no n= eed or value for two link Hellos associating with the same IPv4 or IPv6 LDP= session. Regards, Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 12:25 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Carlos Pignataro (cpignata) Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, Thanks for the discussion. Please see inline, 1. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 2. > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. It is not about the FEC. It is about the LSP, and rightfully so. Hopefully, answering this Q will help us - If there are 3 links (LDP enabled) between two LSRs and only two have hello adj leading to the workin= g LDP session, then would the LSRs use the 3rd link (which doesn't have val= id hello adj) for MPLS packet forwarding? - If your answer is Yes, then we have a fundamental disagreement independen= t of LDP IPv6. - If the answer is No, then that's inline with what's described in the last= para of section 3 - differentiating IPv4 hello adj from IPv6 hello adj. Perhaps, the text needs a bit of rephrasing, so please feel free to= suggest. The above has no bearing on FEC type e.g. IPv4 packet being sent over LSPv6 or vice versa. Hence, we leave the text as-it-is. 3. > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. Removing last paragraph of section 2.5.2 from RFC 5036 ? That would fundamentally break RFC5036. > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. Correct and that's because each LSR uses the same LDP Identifier and qualif= ies for the point 1 of section 2.5.2 in RFC5036, which suggests to not esta= blish a new session if there is already one existing using the same LDP Ide= ntifier: // 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > It becomes an issue of association of multiple Hello adjacencies with > a single TCP connection. And it is not an issue thanks to the last para of section 2.5.2. We can NOT= afford to remove it. Hence, we leave the text as-it-is in section 4 of ldp-ipv6. 4. > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. That's incorrect. As you know, PW-FEC, as per RFC5036, already requires 'ex= tended/targetted hello adj', not 'basic hello adj' with the peer before exc= hanging PW-FECs with that peer. In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is en= abled on an interface. This is already implicit in RFC5036. And if the interface is a dual-stack interface, then the behavior shouldn't= change. 5. > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. Well, RFC5036 (LDP version 1) prescribes using a single session for exchang= ing FEC-label bindings for various FEC types. We could work on version 2 to move away from that intention e.g. allow usin= g more than one session between two LSRs. > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be excha= nged, as permitted. We are in agreement here. 6. Given the lack of response for #6, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 7. > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a Please see my response to #4. Nonetheless, this is moot, as it is a MAY, a= nd is local to the LSR. FWIW, this point has been beaten to death last yr, and I would urge you to = check the discussion on the mailing list from last yr. 8. > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? If the node still receives the unsupported FEC or address type, then it ind= icates that the peer has a bug, and it should follow the behavior specified= in RFC5036 e.g. declare a fatal error. This is orthogonal to capability or FEC filter, since the assumption here i= s that an LSR is willing to send/receive FEC-label bindings for both IPv4 a= nd IPv6 and more. The point is that the loophole that has existed all along= is closed when an LSR gets upgraded with the code compliant with this spec= ification. 9. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 10. > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. You do make a good point about us not changing the LDP protocol version, so= , it is not a new protocol, and I agree. I will consider to change GTSM to optional (MAY), subjected to Carlos's opi= nion. We will revisit it if/when the consensus suggests otherwise prior to RFC pu= blication. We can close this point as well. Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, March 02, 2012 1:09 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Rajiv, > See some follow-up inline. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, February 29, 2012 10:28 PM > To: Aissaoui, Mustapha (Mustapha); Shane Amante > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Mustapha, > > Thanks for the review of the document and the feedback. It is never too late. > :) Sorry about the delay in getting back to you. > > Please see inline, > > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > Yes, they were discussed in the past and closed. > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > No. > > While it is a common practice to assign a host route to the loopback interface, > and it is a common practice to use loopback interface as the next-hop, we > must not assume the common practice to be the norm for the protocol. In > fact, there is NO technical argument against using the non-host route on a > loopback interface. > > In fact, almost every implementation allows the next-hop to be a non-host > route, and I am aware of at least one implementation that allows LDP to > correctly resolve the next-hop when it uses a non-host route. > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if hello adj > ceases to exist on an interface, then LDP concludes the lack of MPLS > forwarding on that interface. So, if IPv6 hello adj failed, then stop the IPv6 > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of blindly > stopping MPLS forwarding altogether. That wouldn't make sense. > > // > when it receives a Hello that matches the adjacency. If the timer > expires without receipt of a matching Hello from the peer, LDP > concludes that the peer no longer wishes to label switch using that > label space for that link (or target, in the case of Targeted Hellos) > or that the peer has failed. The LSR then deletes the Hello // > > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > I agree. It doesn't have anything to do with the address family, but it > becomes restrictive when having to accommodate transport of two different > address families (IPv4 and IPv6). Pls see more details on this later on. > > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > That's not correct (and the implementation is in violation of RFC5036). > > We had good discussion on this early on. In fact, we had an editor's note on > this in initial versions of this document to solicit discussion on that. > > The last para of section 2.5.2, as stated, would result in a particular IP address > (1.1.1.1, say) being encoded in the transport address in both > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared (which is > what the WG agreed to during IETF 80), then it prohibits IPv6 hello from > carrying IPv6 transport address (or IPv4 hello from carrying > IPv4 transport address). It would not make sense. > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport address > and vice versa. It wouldn't make sense and would be incorrect. > > That's why the change was needed. > > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. It becomes an issue of association of multiple Hello > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > We thought so too, but we uncovered various corner cases in which this > becomes problematic, not to mention that the indeterminism it would bring > into the picture. The easiest was to maintain hello adj per address-family per > peer. > > For ex, consider three LDP enabled interfaces between R1 and R2, where > two are dual-stack, whereas the 3rd is single-stack (v4). If they maintain only > single adj, then they would have hello adj of one transport (v6, say) on dual- > stack interfaces, and another transport (v4, > say) on 3rd interface. > > Hello adj is tightly coupled with the functional LDP peering. If (the > last) hello adj is lost, then LDP peering must be brought down. > Additionally, if hello adj is gone from an interface, then LDP should prohibit > MPLS forwarding from using that interface. > > Another way to think about it is - if IPv4 stops functioning on an interface, but > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be penalized. > And vice versa. > > Having separate hello adj maintenance is much cleaner/simpler and provides > deterministic behavior. > > Nonetheless, an implementation could choose to optimize, if needed, to > keep both address-family related info in a single adjacency structure, but this > is all implementation specific. :) > > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > Good point, but this is a different problem. It is not about the sequence > (which was ok if IPv4 hellow as carrying two IPv4 transport addresses). > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > transport address is fundamentally a wrong approach, IMO. How would IPv4 > know that IPv6 transport is even functional (and vice versa). IPv4 based > discovery should suggest IPv4 transport, and IPv6 based discovery should > suggest IPv6 transport. > > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > connection and vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > We need the address-family awareness in peer hello adjacency/s, whether it > is a kept in a single adj structure or not. > > Loosing the AFI awareness leads up the other problems that I mentioned > earlier. > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > It is MAY. :) > It was changed to MAY based on the exhaustive discussion on mailing list in > 2011 for us to move forward. > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > different protocol. > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > We initially thought so too, until we discovered the following very explicitly in > RFC5036. This is a recipe for a disaster, if left untreated. > > // > Section 3.5.5.1 - > If an LSR does not support the Address Family specified in the Address List > TLV, it SHOULD send an Unsupported Address Family Notification to its LDP > signaling an error and abort processing the message. > > Section 3.4.1.1 - > If in decoding a FEC TLV an LSR encounters a FEC Element with an Address > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > processing the message containing the TLV, and send an "Unsupported > Address Family" Notification message to its LDP peer signaling an error. > // > > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > Because it is native in IPv6 to allow for link-local addresses that IPv4 never > allowed. > So, what was an anomaly with IPv4 is now a standard behavior with IPv6, > hence, that verbiage. > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > We posed the Q about GTSM being the default or not during IETF 80, and > there were 10-yes and 0-no (mostly from operators) Pls see the minutes, > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Monday, February 06, 2012 3:21 PM > > To: Shane Amante > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > LDP as defined in RFC 5036 can carry multiple FEC types within an LDP > session > > from a peer which is identified by the LDP identifier tuple {LSR-id, > label-space- > > id}. If two LSR nodes using the same LSR-id want to advertise two > different label > > spaces, then they must use two different Hello adjacencies and LDP > sessions for > > that. Also, if an implementation supports virtualization of LDP, then > a different > > LDP identifier altogether can be used to establish a separate LDP > session. Other > > than that, there is no relation between the type of adjacency and the > FEC which > > are carried. For example, the same LDP Hello Adjacency and LDP session > are > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between > two > > directly connected peers. > > > > As far as I know BGP is not very different. It offers the ability to > carry IPv4 NLRI > > over a IPv6 session and vice versa. > > > > If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 > on an IPv4 > > session between two LSRs, then we should consider extending RFC 5036 > to > > allow for two different LSR-id values sharing the same global label > space. This > > way, we can have separate Hello adjacency and LDP session and it is up > to the > > user to assign which FEC type is allowed on which LDP session. This is > a new > > work item but in my view much cleaner and backward compatible with RFC > > 5036 than to try to tie the address family to the type of Hello > adjacency. > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > Hello > > adjacency but a single shared LDP session. It is not exactly what you > are asking > > for. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Friday, February 03, 2012 11:32 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mustapha, > > > > I am not an author, but I do want to provide some operational input on > some of > > your comments. Specifically, I get the sense from several of your > comments -- > > actually, moreso from #3 -- that you are opposed to maintaining > separate LDP > > Hello and/or Session Adjacencies: 1 for each address family. (If my > impression > > is incorrect I apologize). > > > > I actually *do* want to have separate LDP Hello and Session > adjacencies: one > > per address family, at least at this point in time. I'm concerned > about > > [operational] issues that may develop in, for example, v6 affecting > the > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one > more > > concrete example, 6man/v6ops are only right now working on improving > the > > robustness of IPv6 ND to DoS attacks. There are potentially other > areas where > > IPv6 will be hardened, as well. The bottom-line is I do not want > problems in v6 > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > FWIW, there has > > already been a precedent here wrt BGP where there it maintains > separate > > neighbors/sessions for each address family, so why aren't we doing the > same > > thing for LDP? > > > > Ultimately, having separate sessions over-the-wire is much more > intuitive to > > operators in lots of cases where they may expect that a configuration > change > > or bugs they /think/ are only going to affect one address family, > really do only > > affect one address family. Besides, LDP Hello & Sessions timers, when > set to > > default, are extremely relaxed (order of several seconds), so the > burden on > > implementations to maintain separate sessions should be miniscule. > > > > IMO, I would prefer that the default be separate Hellos & Sessions > over the > > wire to avoid "fate sharing". Only when an operator chooses to > explicitly > > configure their device to have hellos and sessions share fate should > the device > > do so. > > > > Just my $0.02, > > > > -shane > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > Dear authors, > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > > > > > Regards, > > > Mustapha. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > > > > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From prvs=9434cbe2b9=hshah@ciena.com Wed Mar 28 13:05:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4CF21E8089 for ; Wed, 28 Mar 2012 13:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhEnTqDyVn5J for ; Wed, 28 Mar 2012 13:05:51 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0562321E80D7 for ; Wed, 28 Mar 2012 13:05:50 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q2SK4wqr015625; Wed, 28 Mar 2012 16:05:38 -0400 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 13v8h204ky-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Mar 2012 16:05:36 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Wed, 28 Mar 2012 16:05:37 -0400 From: "Shah, Himanshu" To: "Aissaoui, Mustapha (Mustapha)" , "Rajiv Asati (rajiva)" Date: Wed, 28 Mar 2012 16:05:34 -0400 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdAB0mgbIAIJkWAAAyG5R5AADZbVkA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA195@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5A08BB0@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5A08BB0@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18786.002 x-tm-as-result: No--23.967800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-28_08:2012-03-28, 2012-03-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1203280213 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:05:56 -0000 I second the same concern and fail to understand the rationale to bypass th= e available tool (capacity negotiation). Thanks, himanshu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ais= saoui, Mustapha (Mustapha) Sent: Wednesday, March 28, 2012 3:56 PM To: Rajiv Asati (rajiva) Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Rajiv, I am afraid we are not making progress on the technical questions I raised = on this draft. For the benefit of everyone else on the mailing list, I am going to state t= he main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. Thi= s proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) whic= h can be resolved in the datapath over a given link based on the type of th= e control plane adjacency (IPv4 or IPv6) established over that link. This c= oupling of FEC resolution to the type of control plane adjacency is not cor= rect and breaks so many things in RFC 5036. In RFC 5036, the ability to res= olve a FEC type between peers is independent of the adjacency established. In addition, this proposal now means that we need 2 link Hello adjacencies = over each link and 2 targeted Hello adjacencies between any two LSR nodes. = This is not good from a scaling perspective while it provides no gain. In an earlier exchange on this thread, we discussed the need for introducin= g per Hello adjacency capability negotiation to address the probem of which= FEC types can be resolved over a given link adjacency. That is the correct= approach to the problem and we should keep the behaviour of RFC 5036 as is= , that is an IPv4 link Hello adjacency will bootstrap an IPv4 LDP session a= nd an IPv6 link adjacency will bootstrap an IPv6 LDP session. There is no n= eed or value for two link Hellos associating with the same IPv4 or IPv6 LDP= session. Regards, Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 12:25 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Carlos Pignataro (cpignata) Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, Thanks for the discussion. Please see inline, 1. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 2. > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. It is not about the FEC. It is about the LSP, and rightfully so. Hopefully, answering this Q will help us - If there are 3 links (LDP enabled) between two LSRs and only two have hello adj leading to the workin= g LDP session, then would the LSRs use the 3rd link (which doesn't have val= id hello adj) for MPLS packet forwarding? - If your answer is Yes, then we have a fundamental disagreement independen= t of LDP IPv6. - If the answer is No, then that's inline with what's described in the last= para of section 3 - differentiating IPv4 hello adj from IPv6 hello adj. Perhaps, the text needs a bit of rephrasing, so please feel free to= suggest. The above has no bearing on FEC type e.g. IPv4 packet being sent over LSPv6 or vice versa. Hence, we leave the text as-it-is. 3. > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. Removing last paragraph of section 2.5.2 from RFC 5036 ? That would fundamentally break RFC5036. > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. Correct and that's because each LSR uses the same LDP Identifier and qualif= ies for the point 1 of section 2.5.2 in RFC5036, which suggests to not esta= blish a new session if there is already one existing using the same LDP Ide= ntifier: // 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > It becomes an issue of association of multiple Hello adjacencies with > a single TCP connection. And it is not an issue thanks to the last para of section 2.5.2. We can NOT= afford to remove it. Hence, we leave the text as-it-is in section 4 of ldp-ipv6. 4. > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. That's incorrect. As you know, PW-FEC, as per RFC5036, already requires 'ex= tended/targetted hello adj', not 'basic hello adj' with the peer before exc= hanging PW-FECs with that peer. In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is en= abled on an interface. This is already implicit in RFC5036. And if the interface is a dual-stack interface, then the behavior shouldn't= change. 5. > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. Well, RFC5036 (LDP version 1) prescribes using a single session for exchang= ing FEC-label bindings for various FEC types. We could work on version 2 to move away from that intention e.g. allow usin= g more than one session between two LSRs. > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be excha= nged, as permitted. We are in agreement here. 6. Given the lack of response for #6, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 7. > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a Please see my response to #4. Nonetheless, this is moot, as it is a MAY, a= nd is local to the LSR. FWIW, this point has been beaten to death last yr, and I would urge you to = check the discussion on the mailing list from last yr. 8. > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? If the node still receives the unsupported FEC or address type, then it ind= icates that the peer has a bug, and it should follow the behavior specified= in RFC5036 e.g. declare a fatal error. This is orthogonal to capability or FEC filter, since the assumption here i= s that an LSR is willing to send/receive FEC-label bindings for both IPv4 a= nd IPv6 and more. The point is that the loophole that has existed all along= is closed when an LSR gets upgraded with the code compliant with this spec= ification. 9. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 10. > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. You do make a good point about us not changing the LDP protocol version, so= , it is not a new protocol, and I agree. I will consider to change GTSM to optional (MAY), subjected to Carlos's opi= nion. We will revisit it if/when the consensus suggests otherwise prior to RFC pu= blication. We can close this point as well. Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, March 02, 2012 1:09 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Rajiv, > See some follow-up inline. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, February 29, 2012 10:28 PM > To: Aissaoui, Mustapha (Mustapha); Shane Amante > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Mustapha, > > Thanks for the review of the document and the feedback. It is never too late. > :) Sorry about the delay in getting back to you. > > Please see inline, > > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > Yes, they were discussed in the past and closed. > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > No. > > While it is a common practice to assign a host route to the loopback interface, > and it is a common practice to use loopback interface as the next-hop, we > must not assume the common practice to be the norm for the protocol. In > fact, there is NO technical argument against using the non-host route on a > loopback interface. > > In fact, almost every implementation allows the next-hop to be a non-host > route, and I am aware of at least one implementation that allows LDP to > correctly resolve the next-hop when it uses a non-host route. > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if hello adj > ceases to exist on an interface, then LDP concludes the lack of MPLS > forwarding on that interface. So, if IPv6 hello adj failed, then stop the IPv6 > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of blindly > stopping MPLS forwarding altogether. That wouldn't make sense. > > // > when it receives a Hello that matches the adjacency. If the timer > expires without receipt of a matching Hello from the peer, LDP > concludes that the peer no longer wishes to label switch using that > label space for that link (or target, in the case of Targeted Hellos) > or that the peer has failed. The LSR then deletes the Hello // > > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > I agree. It doesn't have anything to do with the address family, but it > becomes restrictive when having to accommodate transport of two different > address families (IPv4 and IPv6). Pls see more details on this later on. > > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > That's not correct (and the implementation is in violation of RFC5036). > > We had good discussion on this early on. In fact, we had an editor's note on > this in initial versions of this document to solicit discussion on that. > > The last para of section 2.5.2, as stated, would result in a particular IP address > (1.1.1.1, say) being encoded in the transport address in both > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared (which is > what the WG agreed to during IETF 80), then it prohibits IPv6 hello from > carrying IPv6 transport address (or IPv4 hello from carrying > IPv4 transport address). It would not make sense. > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport address > and vice versa. It wouldn't make sense and would be incorrect. > > That's why the change was needed. > > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. It becomes an issue of association of multiple Hello > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > We thought so too, but we uncovered various corner cases in which this > becomes problematic, not to mention that the indeterminism it would bring > into the picture. The easiest was to maintain hello adj per address-family per > peer. > > For ex, consider three LDP enabled interfaces between R1 and R2, where > two are dual-stack, whereas the 3rd is single-stack (v4). If they maintain only > single adj, then they would have hello adj of one transport (v6, say) on dual- > stack interfaces, and another transport (v4, > say) on 3rd interface. > > Hello adj is tightly coupled with the functional LDP peering. If (the > last) hello adj is lost, then LDP peering must be brought down. > Additionally, if hello adj is gone from an interface, then LDP should prohibit > MPLS forwarding from using that interface. > > Another way to think about it is - if IPv4 stops functioning on an interface, but > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be penalized. > And vice versa. > > Having separate hello adj maintenance is much cleaner/simpler and provides > deterministic behavior. > > Nonetheless, an implementation could choose to optimize, if needed, to > keep both address-family related info in a single adjacency structure, but this > is all implementation specific. :) > > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > Good point, but this is a different problem. It is not about the sequence > (which was ok if IPv4 hellow as carrying two IPv4 transport addresses). > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > transport address is fundamentally a wrong approach, IMO. How would IPv4 > know that IPv6 transport is even functional (and vice versa). IPv4 based > discovery should suggest IPv4 transport, and IPv6 based discovery should > suggest IPv6 transport. > > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > connection and vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > We need the address-family awareness in peer hello adjacency/s, whether it > is a kept in a single adj structure or not. > > Loosing the AFI awareness leads up the other problems that I mentioned > earlier. > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > It is MAY. :) > It was changed to MAY based on the exhaustive discussion on mailing list in > 2011 for us to move forward. > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > different protocol. > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > We initially thought so too, until we discovered the following very explicitly in > RFC5036. This is a recipe for a disaster, if left untreated. > > // > Section 3.5.5.1 - > If an LSR does not support the Address Family specified in the Address List > TLV, it SHOULD send an Unsupported Address Family Notification to its LDP > signaling an error and abort processing the message. > > Section 3.4.1.1 - > If in decoding a FEC TLV an LSR encounters a FEC Element with an Address > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > processing the message containing the TLV, and send an "Unsupported > Address Family" Notification message to its LDP peer signaling an error. > // > > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > Because it is native in IPv6 to allow for link-local addresses that IPv4 never > allowed. > So, what was an anomaly with IPv4 is now a standard behavior with IPv6, > hence, that verbiage. > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > We posed the Q about GTSM being the default or not during IETF 80, and > there were 10-yes and 0-no (mostly from operators) Pls see the minutes, > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Monday, February 06, 2012 3:21 PM > > To: Shane Amante > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > LDP as defined in RFC 5036 can carry multiple FEC types within an LDP > session > > from a peer which is identified by the LDP identifier tuple {LSR-id, > label-space- > > id}. If two LSR nodes using the same LSR-id want to advertise two > different label > > spaces, then they must use two different Hello adjacencies and LDP > sessions for > > that. Also, if an implementation supports virtualization of LDP, then > a different > > LDP identifier altogether can be used to establish a separate LDP > session. Other > > than that, there is no relation between the type of adjacency and the > FEC which > > are carried. For example, the same LDP Hello Adjacency and LDP session > are > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between > two > > directly connected peers. > > > > As far as I know BGP is not very different. It offers the ability to > carry IPv4 NLRI > > over a IPv6 session and vice versa. > > > > If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 > on an IPv4 > > session between two LSRs, then we should consider extending RFC 5036 > to > > allow for two different LSR-id values sharing the same global label > space. This > > way, we can have separate Hello adjacency and LDP session and it is up > to the > > user to assign which FEC type is allowed on which LDP session. This is > a new > > work item but in my view much cleaner and backward compatible with RFC > > 5036 than to try to tie the address family to the type of Hello > adjacency. > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > Hello > > adjacency but a single shared LDP session. It is not exactly what you > are asking > > for. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Friday, February 03, 2012 11:32 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mustapha, > > > > I am not an author, but I do want to provide some operational input on > some of > > your comments. Specifically, I get the sense from several of your > comments -- > > actually, moreso from #3 -- that you are opposed to maintaining > separate LDP > > Hello and/or Session Adjacencies: 1 for each address family. (If my > impression > > is incorrect I apologize). > > > > I actually *do* want to have separate LDP Hello and Session > adjacencies: one > > per address family, at least at this point in time. I'm concerned > about > > [operational] issues that may develop in, for example, v6 affecting > the > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one > more > > concrete example, 6man/v6ops are only right now working on improving > the > > robustness of IPv6 ND to DoS attacks. There are potentially other > areas where > > IPv6 will be hardened, as well. The bottom-line is I do not want > problems in v6 > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > FWIW, there has > > already been a precedent here wrt BGP where there it maintains > separate > > neighbors/sessions for each address family, so why aren't we doing the > same > > thing for LDP? > > > > Ultimately, having separate sessions over-the-wire is much more > intuitive to > > operators in lots of cases where they may expect that a configuration > change > > or bugs they /think/ are only going to affect one address family, > really do only > > affect one address family. Besides, LDP Hello & Sessions timers, when > set to > > default, are extremely relaxed (order of several seconds), so the > burden on > > implementations to maintain separate sessions should be miniscule. > > > > IMO, I would prefer that the default be separate Hellos & Sessions > over the > > wire to avoid "fate sharing". Only when an operator chooses to > explicitly > > configure their device to have hellos and sessions share fate should > the device > > do so. > > > > Just my $0.02, > > > > -shane > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > Dear authors, > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > > > > > Regards, > > > Mustapha. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > > > > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From pranjal.dutta@alcatel-lucent.com Wed Mar 28 14:01:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D961421F8846 for ; Wed, 28 Mar 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.392 X-Spam-Level: X-Spam-Status: No, score=-7.392 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIoIpduKxg6d for ; Wed, 28 Mar 2012 14:01:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA1E521F8844 for ; Wed, 28 Mar 2012 14:01:33 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2SL1SPe009740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Mar 2012 16:01:30 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2SL1RiM019987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 02:31:27 +0530 Received: from INBANSXCHMBSA3.in.alcatel-lucent.com ([135.250.12.53]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 29 Mar 2012 02:31:27 +0530 From: "Dutta, Pranjal K (Pranjal)" To: "Aissaoui, Mustapha (Mustapha)" , "Rajiv Asati (rajiva)" Date: Thu, 29 Mar 2012 02:31:20 +0530 Thread-Topic: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Thread-Index: Aczi9gKBKcjtZosmRQi3iyzlmOQNUwB6XhAAAwQ3gdAB0mgbIAIJkWAAAyG5R5AAD16XQA== Message-ID: References: <5DF53972F7E9134782DCE51624466FE50AD55FD81F@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <5DF53972F7E9134782DCE51624466FE50AD55FD9D4@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C078BE11C@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD58116AA@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C079FA195@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5A08BB0@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5A08BB0@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 21:01:37 -0000 I have raised the same in mailing list multiple times, but no **technical j= ustification** has been provided in answers. Apart from scaling implication= s, LDP FEC next-hop resolution algorithms does not have dependency with wha= t is the IP address type being used for LDP hello adjacency. If ldp-ipv6 authors claim that IPv6 FEC resolution is different than how we= have been doing so far and ipv6 based hello adjacency is a MUST in order f= or existing LDP implementations to resolve next-hop for an IPV6 FEC then th= at requires a technical debate in this mailing list. Yes, we are certainly not making any progress on the technical questions we= had raised. Thanks, Pranjal -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ais= saoui, Mustapha (Mustapha) Sent: Wednesday, March 28, 2012 12:56 PM To: Rajiv Asati (rajiva) Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Rajiv, I am afraid we are not making progress on the technical questions I raised = on this draft. For the benefit of everyone else on the mailing list, I am going to state t= he main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. Thi= s proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) whic= h can be resolved in the datapath over a given link based on the type of th= e control plane adjacency (IPv4 or IPv6) established over that link. This c= oupling of FEC resolution to the type of control plane adjacency is not cor= rect and breaks so many things in RFC 5036. In RFC 5036, the ability to res= olve a FEC type between peers is independent of the adjacency established. In addition, this proposal now means that we need 2 link Hello adjacencies = over each link and 2 targeted Hello adjacencies between any two LSR nodes. = This is not good from a scaling perspective while it provides no gain. In an earlier exchange on this thread, we discussed the need for introducin= g per Hello adjacency capability negotiation to address the probem of which= FEC types can be resolved over a given link adjacency. That is the correct= approach to the problem and we should keep the behaviour of RFC 5036 as is= , that is an IPv4 link Hello adjacency will bootstrap an IPv4 LDP session a= nd an IPv6 link adjacency will bootstrap an IPv6 LDP session. There is no n= eed or value for two link Hellos associating with the same IPv4 or IPv6 LDP= session. Regards, Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Monday, March 12, 2012 12:25 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Carlos Pignataro (cpignata) Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 Hi Mustapha, Thanks for the discussion. Please see inline, 1. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 2. > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. It is not about the FEC. It is about the LSP, and rightfully so. Hopefully, answering this Q will help us - If there are 3 links (LDP enabled) between two LSRs and only two have hello adj leading to the workin= g LDP session, then would the LSRs use the 3rd link (which doesn't have val= id hello adj) for MPLS packet forwarding? - If your answer is Yes, then we have a fundamental disagreement independen= t of LDP IPv6. - If the answer is No, then that's inline with what's described in the last= para of section 3 - differentiating IPv4 hello adj from IPv6 hello adj. Perhaps, the text needs a bit of rephrasing, so please feel free to= suggest. The above has no bearing on FEC type e.g. IPv4 packet being sent over LSPv6 or vice versa. Hence, we leave the text as-it-is. 3. > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. Removing last paragraph of section 2.5.2 from RFC 5036 ? That would fundamentally break RFC5036. > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. Correct and that's because each LSR uses the same LDP Identifier and qualif= ies for the point 1 of section 2.5.2 in RFC5036, which suggests to not esta= blish a new session if there is already one existing using the same LDP Ide= ntifier: // 1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > It becomes an issue of association of multiple Hello adjacencies with > a single TCP connection. And it is not an issue thanks to the last para of section 2.5.2. We can NOT= afford to remove it. Hence, we leave the text as-it-is in section 4 of ldp-ipv6. 4. > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. That's incorrect. As you know, PW-FEC, as per RFC5036, already requires 'ex= tended/targetted hello adj', not 'basic hello adj' with the peer before exc= hanging PW-FECs with that peer. In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is en= abled on an interface. This is already implicit in RFC5036. And if the interface is a dual-stack interface, then the behavior shouldn't= change. 5. > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. Well, RFC5036 (LDP version 1) prescribes using a single session for exchang= ing FEC-label bindings for various FEC types. We could work on version 2 to move away from that intention e.g. allow usin= g more than one session between two LSRs. > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be excha= nged, as permitted. We are in agreement here. 6. Given the lack of response for #6, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 7. > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a Please see my response to #4. Nonetheless, this is moot, as it is a MAY, a= nd is local to the LSR. FWIW, this point has been beaten to death last yr, and I would urge you to = check the discussion on the mailing list from last yr. 8. > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? If the node still receives the unsupported FEC or address type, then it ind= icates that the peer has a bug, and it should follow the behavior specified= in RFC5036 e.g. declare a fatal error. This is orthogonal to capability or FEC filter, since the assumption here i= s that an LSR is willing to send/receive FEC-label bindings for both IPv4 a= nd IPv6 and more. The point is that the loophole that has existed all along= is closed when an LSR gets upgraded with the code compliant with this spec= ification. 9. Given the lack of response for #1, I am assuming this we have agreed and cl= osed the discussion on this point. Thanks. 10. > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. You do make a good point about us not changing the LDP protocol version, so= , it is not a new protocol, and I agree. I will consider to change GTSM to optional (MAY), subjected to Carlos's opi= nion. We will revisit it if/when the consensus suggests otherwise prior to RFC pu= blication. We can close this point as well. Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Friday, March 02, 2012 1:09 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Rajiv, > See some follow-up inline. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Wednesday, February 29, 2012 10:28 PM > To: Aissaoui, Mustapha (Mustapha); Shane Amante > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Mustapha, > > Thanks for the review of the document and the feedback. It is never too late. > :) Sorry about the delay in getting back to you. > > Please see inline, > > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > Yes, they were discussed in the past and closed. > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > No. > > While it is a common practice to assign a host route to the loopback interface, > and it is a common practice to use loopback interface as the next-hop, we > must not assume the common practice to be the norm for the protocol. In > fact, there is NO technical argument against using the non-host route on a > loopback interface. > > In fact, almost every implementation allows the next-hop to be a non-host > route, and I am aware of at least one implementation that allows LDP to > correctly resolve the next-hop when it uses a non-host route. > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if hello adj > ceases to exist on an interface, then LDP concludes the lack of MPLS > forwarding on that interface. So, if IPv6 hello adj failed, then stop the IPv6 > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of blindly > stopping MPLS forwarding altogether. That wouldn't make sense. > > // > when it receives a Hello that matches the adjacency. If the timer > expires without receipt of a matching Hello from the peer, LDP > concludes that the peer no longer wishes to label switch using that > label space for that link (or target, in the case of Targeted Hellos) > or that the peer has failed. The LSR then deletes the Hello // > > MA> Not really. The "matching" has nothing to do with the type of FEC. It has > to do with the parameters of the adjacency (LSRid, label space) over that link. > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > I agree. It doesn't have anything to do with the address family, but it > becomes restrictive when having to accommodate transport of two different > address families (IPv4 and IPv6). Pls see more details on this later on. > > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > That's not correct (and the implementation is in violation of RFC5036). > > We had good discussion on this early on. In fact, we had an editor's note on > this in initial versions of this document to solicit discussion on that. > > The last para of section 2.5.2, as stated, would result in a particular IP address > (1.1.1.1, say) being encoded in the transport address in both > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared (which is > what the WG agreed to during IETF 80), then it prohibits IPv6 hello from > carrying IPv6 transport address (or IPv4 hello from carrying > IPv4 transport address). It would not make sense. > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport address > and vice versa. It wouldn't make sense and would be incorrect. > > That's why the change was needed. > > MA> When parallel links exist between two LSRs, the TCP connection is > bootstrapped by one of the hello adjacencies. An implementation compliant > to RFC 5036 will not accept two TCP connections between the same two LSRs > and thus the fact that the transport addresses exchanged are different has > no impact. In fact take the simple case of a link LDP and a T-LDP sessions for > directly connected LSRs. The T-LDP can use a loopback address as the > transport address while the link LDP can use the link address as the transport > address and they will both share the same TCP connection which was > bootstrapped first. It becomes an issue of association of multiple Hello > adjacencies with a single TCP connection. That is why I am saying the last > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > We thought so too, but we uncovered various corner cases in which this > becomes problematic, not to mention that the indeterminism it would bring > into the picture. The easiest was to maintain hello adj per address-family per > peer. > > For ex, consider three LDP enabled interfaces between R1 and R2, where > two are dual-stack, whereas the 3rd is single-stack (v4). If they maintain only > single adj, then they would have hello adj of one transport (v6, say) on dual- > stack interfaces, and another transport (v4, > say) on 3rd interface. > > Hello adj is tightly coupled with the functional LDP peering. If (the > last) hello adj is lost, then LDP peering must be brought down. > Additionally, if hello adj is gone from an interface, then LDP should prohibit > MPLS forwarding from using that interface. > > Another way to think about it is - if IPv4 stops functioning on an interface, but > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be penalized. > And vice versa. > > Having separate hello adj maintenance is much cleaner/simpler and provides > deterministic behavior. > > Nonetheless, an implementation could choose to optimize, if needed, to > keep both address-family related info in a single adjacency structure, but this > is all implementation specific. :) > > MA> The proper way to handle this is to implement separate LDP sessions > not separate Hello adjacencies sharing the same LDP session. Current > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > exchanges and they do not require separate hello adjacencies. These are just > FEC types and have no relationship whatsoever to the type of adjacency. > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > Good point, but this is a different problem. It is not about the sequence > (which was ok if IPv4 hellow as carrying two IPv4 transport addresses). > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > transport address is fundamentally a wrong approach, IMO. How would IPv4 > know that IPv6 transport is even functional (and vice versa). IPv4 based > discovery should suggest IPv4 transport, and IPv6 based discovery should > suggest IPv6 transport. > > MA> Again, what you are asking for can be solved with the use of separate > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a protocol > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > connection and vice-versa. There is no relationship whatsoever between the > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > We need the address-family awareness in peer hello adjacency/s, whether it > is a kept in a single adj structure or not. > > Loosing the AFI awareness leads up the other problems that I mentioned > earlier. > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > It is MAY. :) > It was changed to MAY based on the exhaustive discussion on mailing list in > 2011 for us to move forward. > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > different protocol. > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > We initially thought so too, until we discovered the following very explicitly in > RFC5036. This is a recipe for a disaster, if left untreated. > > // > Section 3.5.5.1 - > If an LSR does not support the Address Family specified in the Address List > TLV, it SHOULD send an Unsupported Address Family Notification to its LDP > signaling an error and abort processing the message. > > Section 3.4.1.1 - > If in decoding a FEC TLV an LSR encounters a FEC Element with an Address > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > processing the message containing the TLV, and send an "Unsupported > Address Family" Notification message to its LDP peer signaling an error. > // > > MA> Well all this is controlled via the LDP capability or configuring the FEC > filters. If after this, the node still receives the unsupported FEC or address > type, what else do you suggest it should do? > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > Because it is native in IPv6 to allow for link-local addresses that IPv4 never > allowed. > So, what was an anomaly with IPv4 is now a standard behavior with IPv6, > hence, that verbiage. > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > We posed the Q about GTSM being the default or not during IETF 80, and > there were 10-yes and 0-no (mostly from operators) Pls see the minutes, > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > MA> Well that certainly contradicts the process. If you are creating a new LDP > version protocol, we can consider making it mandatory by default. If you > claim you are still compliant to RFC 5036 then you cannot change it and it > must remain optional. > > Cheers, > Rajiv > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Monday, February 06, 2012 3:21 PM > > To: Shane Amante > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Shane, > > LDP as defined in RFC 5036 can carry multiple FEC types within an LDP > session > > from a peer which is identified by the LDP identifier tuple {LSR-id, > label-space- > > id}. If two LSR nodes using the same LSR-id want to advertise two > different label > > spaces, then they must use two different Hello adjacencies and LDP > sessions for > > that. Also, if an implementation supports virtualization of LDP, then > a different > > LDP identifier altogether can be used to establish a separate LDP > session. Other > > than that, there is no relation between the type of adjacency and the > FEC which > > are carried. For example, the same LDP Hello Adjacency and LDP session > are > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs between > two > > directly connected peers. > > > > As far as I know BGP is not very different. It offers the ability to > carry IPv4 NLRI > > over a IPv6 session and vice versa. > > > > If what is required is to carry IPv6 FECs on an IPv6 session and IPv4 > on an IPv4 > > session between two LSRs, then we should consider extending RFC 5036 > to > > allow for two different LSR-id values sharing the same global label > space. This > > way, we can have separate Hello adjacency and LDP session and it is up > to the > > user to assign which FEC type is allowed on which LDP session. This is > a new > > work item but in my view much cleaner and backward compatible with RFC > > 5036 than to try to tie the address family to the type of Hello > adjacency. > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > Hello > > adjacency but a single shared LDP session. It is not exactly what you > are asking > > for. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Shane Amante [mailto:shane@castlepoint.net] > > Sent: Friday, February 03, 2012 11:32 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Mustapha, > > > > I am not an author, but I do want to provide some operational input on > some of > > your comments. Specifically, I get the sense from several of your > comments -- > > actually, moreso from #3 -- that you are opposed to maintaining > separate LDP > > Hello and/or Session Adjacencies: 1 for each address family. (If my > impression > > is incorrect I apologize). > > > > I actually *do* want to have separate LDP Hello and Session > adjacencies: one > > per address family, at least at this point in time. I'm concerned > about > > [operational] issues that may develop in, for example, v6 affecting > the > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As one > more > > concrete example, 6man/v6ops are only right now working on improving > the > > robustness of IPv6 ND to DoS attacks. There are potentially other > areas where > > IPv6 will be hardened, as well. The bottom-line is I do not want > problems in v6 > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > FWIW, there has > > already been a precedent here wrt BGP where there it maintains > separate > > neighbors/sessions for each address family, so why aren't we doing the > same > > thing for LDP? > > > > Ultimately, having separate sessions over-the-wire is much more > intuitive to > > operators in lots of cases where they may expect that a configuration > change > > or bugs they /think/ are only going to affect one address family, > really do only > > affect one address family. Besides, LDP Hello & Sessions timers, when > set to > > default, are extremely relaxed (order of several seconds), so the > burden on > > implementations to maintain separate sessions should be miniscule. > > > > IMO, I would prefer that the default be separate Hellos & Sessions > over the > > wire to avoid "fate sharing". Only when an operator chooses to > explicitly > > configure their device to have hellos and sessions share fate should > the device > > do so. > > > > Just my $0.02, > > > > -shane > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > Dear authors, > > > below are comments on this draft. I realize this draft passed WG > last call but I > > think the issues are significant enough in my view. I apologize if > some of these > > comments were already raised on this mailing list. > > > > > > Regards, > > > Mustapha. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > to a > > loopback interface of the egress router, not any other interface. That > is why > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > explicitly refer to > > /128 for IPv6. > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > " > > > Additionally, it is desirable that a packet is forwarded to an LSP > of an egress > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > with that of > > the LDP hello adjacency on the next-hop interface. > > > " > > > MA> RFC 5036 makes no tie, and there should not be, between the type > of > > resolved FEC and the adjacency to the next-hop. I think this statement > should be > > removed. > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > " > > > This document qualifies the first sentence of last paragraph of > > > Section 2.5.2 of [RFC5036] to be per address family and therefore > > > updates that sentence to the following: "For a given address > family > > > over which a Hello is sent, and a given label space, an LSR MUST > > > advertise the same transport address." This rightly enables the > per- > > > platform label space to be shared between IPv4 and IPv6. > > > " > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 has > anything > > to do with the address family. It only requires that an LSR advertises > the same > > transport address in all Hello adjacencies that advertise the same > label space. > > In fact the intent as explained in the second sentence of that same > paragraph > > was to make sure that if two LSRs are establishing multiple Hello > adjacencies > > that they play the same active/passive role for establishing the TCP > connection. > > > > > > In practice though, most implementations allow Hello adjacencies > over > > parallel links with different IPv4 transport addresses and it works > just fine. I > > think we should remove this restriction from RFC 5036 and not refer to > it in this > > draft. > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > MA> I understand the need to send both IPv4 and IPv6 Hello messages > over a > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > the same > > subnet. However, this does not justify the need to maintain two > separate Hello > > ajacencies per peer. In practice, each router can send both IPv4 and > IPv6 hellos > > but only a single Hello adjacency must be allowed with each peer > (LSR-id, label- > > space} over a given interface, whichever came up first. Over a P2P > interface, it > > is up to the user to configure which adjacency they want to form which > means > > there is only a need to send one type of hello. > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > and IPv6 transport address optional objects, but MUST use > only > > > the transport address whose address family is the same as > that > > > of the IP packet carrying Hello. > > > " > > > MA> This is not a new issue. If I am not mistaken, this can also > occur in RFC > > 5036 implementations if an LSR receives two optional IPv4 transport > address > > TLVs. RFC 506 does not say what to do with this and was left for > > implementations to handle. If we absolutely need to specify something, > maybe > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > hello adjacencies for the same LDP Identifier (over a dual- > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > LDP session with a remote LSR, if they attempted two TCP > > > connections using IPv4 and IPv6 transport addresses > > > simultaneously. > > > " > > > MA> No need for all this if you enforce that only a single adjacency > is > > maintained to each peer over a dual-stack interface. > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > " > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > well as interface addresses via ADDRESS message) from/to the peer > > > over an LDP session (using whatever transport), unless it has > valid > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > section 6.2. > > > " > > > MA> I do not agree that the advertisement of IPv6 label-FEC bindings > should > > depend on the existence of an IPv6 Hello adjacency. This is a very > narrow > > interpretation of RFC 5036. > > > The proper solution to this is to add an IPV6 LDP capability to > negotiate which > > FEC address family can be exchanged regardless if the Hello adjacency > is IPv4 > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > " > > > Additionally, to ensure backward compatibility (and interoperability > > > with IPv4-only LDP implementations), this document specifies that > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > containing FEC Elements of different address-family. In other words, a > FEC TLV > > in the label mapping message MUST contain the FEC Elements belonging > to the > > same address-family. > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > message) with an Address List TLV containing IP addresses of different > address- > > family. In other words, an Address List TLV in the Address (or Address > > Withdraw) message MUST contain the addresses belonging to the same > > address-family.. > > > " > > > MA> This is yet another narrow interpretation of RFC 5036. There is > no > > justification for such a restriction and certainly RFC 5036 does not > make it. A > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > Element has > > its own Type, Length, Value and is self sufficient. Although > implementations > > don't mix and match FEC elements but they are designed to handle it. > Same > > applies to Address list TLV. > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > MA> I believe the need to handle duplicate interface addresses > received from > > two different peers is not a new issue. It needed to be handled in > existing IPv4 > > based LDP implementations. Maybe the authors can specify why duplicate > link > > local addresses is any different. > > > > > > > > > 10. Section 9 - LDP TTL Security > > > " > > > This document also specifies that the LDP/TCP transport connection > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL Security > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > session peering established between the adjacent LSRs using Basic > > > Discovery, by default. > > > " > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > not > > defining a new protocol and as such it should remain optional as in > RFC 5036. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Mar 29 00:35:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0C21F87D2 for ; Thu, 29 Mar 2012 00:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tEBsc-9Qtsk for ; Thu, 29 Mar 2012 00:35:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DA4C821F87BC for ; Thu, 29 Mar 2012 00:35:19 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2T7ZFbm020818; Thu, 29 Mar 2012 02:35:17 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Mar 2012 03:35:11 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Thu, 29 Mar 2012 03:35:10 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13551008E73EUSAACMS0715e_" MIME-Version: 1.0 Subject: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:35:21 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13551008E73EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please kindly consider my comments to the document: * Section 1.2, second bullet. Is LER-A expecting to receive W1 from P= after is sends PSC message to LER-Z? * Section 1.2, third bullet. I think that part of the last sentence d= oesn't correctly reflect LER-A to LER-Z flow of W1: "... LER-Z receives the= W1 data traffic from P ...". I believe that LER-Z would not be receiving W= 1 until, as described in bullet #4, LER-A processes PSC reply from LER-Z. P= erhaps the following can replace the text in question: "... LER-Z doesn't r= eceive W1 data traffic ..." If the intention of the phrase in question is t= o indicate that LER-Z is prepared to receive W1 from P, then wording might = be something like "... LER-Z is ready to receive the W1 data traffic from P= if and when LER-A sends them ..." * Section 1.2 is not consistent with Section 3.3.1.2 * Section 1.4 I think that in case of FIFO priority policy PSC must b= e used to guarantee deterministic switchover to protected path by analyzing= MEP_ID and introduction of tie breaking rule(s), not to leave it to an ope= rator. * Section 3.3.1.1 - uni-directional non-locking 1:n scenario - simult= aneous detection in opposite directions. * Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z re= move W2 from P * Section 4.3.2, as mentioned in note above, protection at LER-A and = LER-Z might be triggered by almost simulteneous failures of two working pat= hs, e.g. W1 and W2 respectively, of the same priority. Thus FIFO should be = used but since LER-A would protect W1 while LER-Z - W2 a tiebreaker should = be used to avoid situation where both working paths would be partially lock= ed out and protection would not be useful. Some generalization question: "Can, and if "yes", is it worth it, 1:n be vi= ewed as special case of Shared Mesh Protection?" Personally, I think that 1= :n can be viewed as special case of SMP but optimization of operation for 1= :n makes it not worth of applying generic SMP solution. Thank you for your kind consideration. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13551008E73EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please kindly consider my comments to the document:
  • Section 1.2, second bullet. Is LER-A expecting to receive W1 from P aft= er is sends PSC message to LER-Z?
  • Section 1.2, third bullet. I thin= k that part of the last sentence doesn't correctly reflect LER-A to LER-Z f= low of W1: "… LER-Z receives the W1 data traffic from P …&= quot;. I believe that LER-Z would not be receiving W1 until, as described i= n bullet #4, LER-A processes PSC reply from LER-Z. Perhaps the following can replace the text = in question: "… LER-Z doesn't receive W1 data traffic …&qu= ot; If the intention of the phrase in question is to indicate that LER-Z is= prepared to receive W1 from P, then wording might be something like "… LER-Z is ready to receive the W1 data traffic = from P if and when LER-A sends them …"
  • Section 1.2 is no= t consistent with Section 3.3.1.2
  • Section 1.4 I think that in case = of FIFO priority policy PSC must be used to guarantee deterministic switcho= ver to protected path by analyzing MEP_ID and introduction of tie breaking = rule(s), not to leave it to an operator.
  • Section 3.3.1.1 - uni-dire= ctional non-locking 1:n scenario - simultaneous detection in opposite direc= tions.
  • Section 3.3.3.3, Figure 8. Not clear when and if LER-A and L= ER-Z remove W2 from P
  • Section 4.3.2, as mentioned in note above, pr= otection at LER-A and LER-Z might be triggered by almost simulteneous failu= res of two working paths, e.g. W1 and W2 respectively, of the same priority= . Thus FIFO should be used but since LER-A would protect W1 while LER-Z - W2 a tiebreaker should be used to avoid situation where both = working paths would be partially locked out and protection would not be use= ful.
 
Some generalization question: "Can, and if "yes", is it= worth it, 1:n be viewed as special case of Shared Mesh Protection?" P= ersonally, I think that 1:n can be viewed as special case of SMP but optimi= zation of operation for 1:n makes it not worth of applying generic SMP solution.
 
Thank you for your kind consideration.
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF13551008E73EUSAACMS0715e_-- From wyaacov@gmail.com Thu Mar 29 01:52:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFADB21F88EB for ; Thu, 29 Mar 2012 01:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzbRuqWG45hs for ; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id B893121F891A for ; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) Received: by qafi31 with SMTP id i31so217908qaf.15 for ; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0iYxJFJL4zL0WQKkuOeiEt6hnjMKK2axe97GbODvGhY=; b=UyU2fGC4H79MSwnCn060nBguz6At1pnxEq+XKfgcxQKI6gAiFD4xYMtdFfBdrMwkZl LrS16HPvmK01Cf8FDHLBADDilPZjoar2ogKObIRcP8AGUtLPpLkcTgfTthaA72HyEfBi 2uSptERtf6fYQtTnX0YPFi7ECDAoyTz7qK6QQFPGiRzqrup1vJvBrZEj8rLifSg5XOKx B6vof05rbhAJNbRB5IiIhRaJT220tm2I/5DYIsNMFX5CoXrPD6W2fUADEk5Po8ns5K4o pjRdyNoDa119NWo7poqe9W9sYUqHqSv7+K0oGNsQtVUbzTg4kjxYN3bsrjWaKMezd7tU 1LMg== MIME-Version: 1.0 Received: by 10.224.105.79 with SMTP id s15mr42472948qao.35.1333011177227; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Thu, 29 Mar 2012 01:52:57 -0700 (PDT) Date: Thu, 29 Mar 2012 10:52:57 +0200 Message-ID: From: Yaacov Weingarten To: Gregory Mirsky Content-Type: multipart/alternative; boundary=20cf306f7266b3445504bc5dd969 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:52:58 -0000 --20cf306f7266b3445504bc5dd969 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greg, hi Unfortunately, I am not sure that I fully understand all of your comments, but I will try to address them as well as possible inline. BR, yaacov On Mar 29, 2012 9:35 AM, "Gregory Mirsky" wrote: > > Dear Authors, et al., > Please kindly consider my comments to the document: > Section 1.2, second bullet. Is LER-A expecting to receive W1 from P after is sends PSC message to LER-Z? yw> Yes, LER-A is prepared to acept W1 traffic from the protection path, but will not transport the traffic until it is sure that LER-Z can process it. > Section 1.2, third bullet. I think that part of the last sentence doesn't correctly reflect LER-A to LER-Z flow of W1: "=85 LER-Z receives the W1 dat= a traffic from P =85". I believe that LER-Z would not be receiving W1 until, = as described in bullet #4, LER-A processes PSC reply from LER-Z. Perhaps the following can replace the text in question: "=85 LER-Z doesn't receive W1 data traffic =85" If the intention of the phrase in question is to indicate that LER-Z is prepared to receive W1 from P, then wording might be something like "=85 LER-Z is ready to receive the W1 data traffic from P if and when LER-A sends them =85" yw> yes, your interpretation is correct and we will clarify the text. > Section 1.2 is not consistent with Section 3.3.1.2 yw> thank you for pointing this out - we will align the two descriptions. > Section 1.4 I think that in case of FIFO priority policy PSC must be used to guarantee deterministic switchover to protected path by analyzing MEP_ID and introduction of tie breaking rule(s), not to leave it to an operator. yw> not sure that you are really saying anything different from what the text states. In the final analysis - the MEP_ID is assigned by the operator in the same way that an explicit priority would be assigned. The purpose of this section is merely to clarify that the assignment of priority and the consistency check of the priority definitions are out of scope of this document! > Section 3.3.1.1 - uni-directional non-locking 1:n scenario - simultaneous detection in opposite directions. yw> Not sure what the comment is - are you suggesting another scenario to be explained? > Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z remove W2 from P yw> There is a basic assumption here that the LER will not transport traffic from two working paths on the protection path simultaneously. Therefore, when the text states that an LER "bridges W1 into P" the implication is that the W2 traffic is no longer being tranported on P. > Section 4.3.2, as mentioned in note above, protection at LER-A and LER-Z might be triggered by almost simulteneous failures of two working paths, e.g. W1 and W2 respectively, of the same priority. Thus FIFO should be used but since LER-A would protect W1 while LER-Z - W2 a tiebreaker should be used to avoid situation where both working paths would be partially locked out and protection would not be useful. yw> Not sure what the comment here is - I agree that there is a need for a tiebreaker, but I am not sure where you found text that precludes this. > > Some generalization question: "Can, and if "yes", is it worth it, 1:n be viewed as special case of Shared Mesh Protection?" Personally, I think that 1:n can be viewed as special case of SMP but optimization of operation for 1:n makes it not worth of applying generic SMP solution. yw> My personal opinion is that 1:n has a major difference from SMP due to the fact that the endpoints of the working paths and the protection path are identical. Therefore there is no need for the additional coordination between the endpoints that is necessary in SMP. There is also no need to coordinate "shared segments" in 1:n protection - since the sharing here is of the entire protection path. > > Thank you for your kind consideration. > > Regards, > Greg > --20cf306f7266b3445504bc5dd969 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Greg, hi

Unfortunately, I am not sure that I fully understand all of your comment= s, but I will try to address them as well as possible inline.

BR,
yaacov

On Mar 29, 2012 9:35 AM, "Gregory Mirsky" <gregory.mirsky@ericsson.com> wrote: >
> Dear Authors, et al.,
> Please kindly consider my comments to the document:
> Section 1.2, second bullet. Is LER-A expecting to receive W1 from P af= ter is sends PSC message to LER-Z?

yw> Yes, LER-A is prepared to acept W1 traffic from the protection pa= th,=A0 but will not transport the traffic until it is sure that LER-Z can p= rocess it.

> Section 1.2, third bullet. I think that part of the last sentence d= oesn't correctly reflect LER-A to LER-Z flow of W1: "=85 LER-Z rec= eives the W1 data traffic from P =85". I believe that LER-Z would not = be receiving W1 until, as described in bullet #4, LER-A processes PSC reply= from LER-Z. Perhaps the following can replace the text in question: "= =85 LER-Z doesn't receive W1 data traffic =85" If the intention of= the phrase in question is to indicate that LER-Z is prepared to receive W1= from P, then wording might be something like "=85 LER-Z is ready to r= eceive the W1 data traffic from P if and when LER-A sends them =85"

yw> yes, your interpretation is correct and we will clarify the text.=

> Section 1.2 is not consistent with Section 3.3.1.2

yw> thank you for pointing this out - we will align the two descripti= ons.

> Section 1.4 I think that in case of FIFO priority policy PSC must b= e used to guarantee deterministic switchover to protected path by analyzing= MEP_ID and introduction of tie breaking rule(s), not to leave it to an ope= rator.

yw> not sure that you are really saying anything different from what = the text states. In the final analysis - the MEP_ID is assigned by the oper= ator in the same way that an explicit priority would be assigned.=A0 The pu= rpose of this section is merely to clarify that the assignment of priority = and the consistency check of the priority definitions are out of scope of t= his document!

> Section 3.3.1.1 - uni-directional non-locking 1:n scenario - simult= aneous detection in opposite directions.

yw> Not sure what the comment is - are you suggesting another scenari= o to be explained?

> Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z re= move W2 from P

yw> There is a basic assumption here that the LER will not transport = traffic from two working paths on the protection path simultaneously.=A0 Th= erefore, when the text states that an LER "bridges W1 into P" the= implication is that the W2 traffic is no longer being tranported on P.

> Section 4.3.2, as mentioned in note above, protection at LER-A and = LER-Z might be triggered by almost simulteneous failures of two working pat= hs, e.g. W1 and W2 respectively, of the same priority. Thus FIFO should be = used but since LER-A would protect W1 while LER-Z - W2 a tiebreaker should = be used to avoid situation where both working paths would be partially lock= ed out and protection would not be useful.

yw>=A0 Not sure what the comment here is - I agree that there is a ne= ed for a tiebreaker, but I am not sure where you found text that precludes = this.

> =A0
> Some generalization question: "Can, and if "yes", is it= worth it, 1:n be viewed as special case of Shared Mesh Protection?" P= ersonally, I think that 1:n can be viewed as special case of SMP but optimi= zation of operation for 1:n makes it not worth of applying generic SMP solu= tion.

yw> My personal opinion is that 1:n has a major difference from SMP d= ue to the fact that the endpoints of the working paths and the protection p= ath are identical.=A0 Therefore there is no need for the additional coordin= ation between the endpoints that is necessary in SMP.=A0 There is also no n= eed to coordinate "shared segments" in 1:n protection - since the= sharing here is of the entire protection path.
> =A0
> Thank you for your kind consideration.
> =A0
> =A0=A0=A0=A0=A0=A0=A0 Regards,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Greg
> =A0

--20cf306f7266b3445504bc5dd969-- From eosborne@cisco.com Thu Mar 29 02:00:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533BA21F88AC for ; Thu, 29 Mar 2012 02:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyeGib4PjgwM for ; Thu, 29 Mar 2012 02:00:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 02BE621F889C for ; Thu, 29 Mar 2012 02:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3719; q=dns/txt; s=iport; t=1333011644; x=1334221244; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ORu5QxclM8Tu8lJcOCkRKWyGdbfyTBS2aRgxwcJgO5s=; b=YhJ0AgyjBTQKsPnsCeN9NYr/ORLXVhSc8PUwfDeddmBM5A7aUSx/oi2G bK/KOLRiSquhhsoNLXSYPKuz26eMk2fjXnZGJm4267yvI9PCXFbqKuVAx R6JjWlmm8w8JJtcngdWeIsDIMG7Oop1I4PeIIkjgQWQr6ng9siXfBj5Y9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADckdE+tJV2a/2dsb2JhbAA9CLkOgQeCCQEBAQMBEgEdCkQHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggTB4djBZtUnxmKeYVDYwSIWJtOgWiDBYE2BQE X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="67351252" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 29 Mar 2012 09:00:43 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2T90hdu031825; Thu, 29 Mar 2012 09:00:43 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 04:00:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 04:00:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHA References: From: "Eric Osborne (eosborne)" To: "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 29 Mar 2012 09:00:42.0998 (UTC) FILETIME=[6BDE2160:01CD0D8A] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:00:45 -0000 Inline with EO#. I've also read Yaacov's comments and agree with most of tehm; we have some editorial cleanup to do, as you've indicated, and will do so in the next rev of the draft. > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 9:35 AM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Dear Authors, et al., > Please kindly consider my comments to the document: >=20 > * Section 1.2, second bullet. Is LER-A expecting to receive W1 from P > after is sends PSC message to LER-Z? > * Section 1.2, third bullet. I think that part of the last sentence > doesn't correctly reflect LER-A to LER-Z flow of W1: "... LER-Z receives the > W1 data traffic from P ...". I believe that LER-Z would not be receiving W1 > until, as described in bullet #4, LER-A processes PSC reply from LER-Z. > Perhaps the following can replace the text in question: "... LER-Z doesn't > receive W1 data traffic ..." If the intention of the phrase in question is > to indicate that LER-Z is prepared to receive W1 from P, then wording > might be something like "... LER-Z is ready to receive the W1 data traffic > from P if and when LER-A sends them ..." > * Section 1.2 is not consistent with Section 3.3.1.2 > * Section 1.4 I think that in case of FIFO priority policy PSC must be > used to guarantee deterministic switchover to protected path by analyzing > MEP_ID and introduction of tie breaking rule(s), not to leave it to an > operator. EO# Numerically sorting by MEP_ID may not be the best way to determine priority. Often the assignment of IDs (IP addrs, etc) comes from a different NMS system than does the determining of LSP priority. We are simply saying that there must be a priority mechanism, and that since we cannot signal priority, the exact mechanism is outside of the scope of the protocol. > * Section 3.3.1.1 - uni-directional non-locking 1:n scenario - > simultaneous detection in opposite directions. > * Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z > remove W2 from P > * Section 4.3.2, as mentioned in note above, protection at LER-A and > LER-Z might be triggered by almost simulteneous failures of two working > paths, e.g. W1 and W2 respectively, of the same priority. Thus FIFO should > be used but since LER-A would protect W1 while LER-Z - W2 a tiebreaker > should be used to avoid situation where both working paths would be > partially locked out and protection would not be useful. EO# I would argue that one should not have LSPs of the "same priority". There must be a tiebreaker that can handle all possible conflicts, no matter what order or how many failures. Once there is a deterministic mechanism for all cases, it means that all LSPs are of different priority. =20 >=20 >=20 > Some generalization question: "Can, and if "yes", is it worth it, 1:n be > viewed as special case of Shared Mesh Protection?" Personally, I think > that 1:n can be viewed as special case of SMP but optimization of > operation for 1:n makes it not worth of applying generic SMP solution. >=20 EO# The current SMP proposals (excepting the one from you and Dave) use PSC between the protection endpoints (nodes A and Z) and add communication within the protection endpoints (nodes B...Y) to coordinate the sharing. Nodes A and Z can use 1:n or 1:1, as they like; how SMP handles the preemption is a separate matter. eric > Thank you for your kind consideration. >=20 > Regards, > Greg >=20 From gregory.mirsky@ericsson.com Thu Mar 29 02:16:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D154621F8A27 for ; Thu, 29 Mar 2012 02:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxdicdtBDF+g for ; Thu, 29 Mar 2012 02:16:40 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6473E21F8A24 for ; Thu, 29 Mar 2012 02:16:40 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2T9GYsH026799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 04:16:34 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 29 Mar 2012 05:16:33 -0400 From: Gregory Mirsky To: Yaacov Weingarten Date: Thu, 29 Mar 2012 05:16:31 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NiVhfciU9ebh6QzWvajh0y8BLtQAAMa1w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13551008E80EUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:16:42 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13551008E80EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaakov, apologies for perhaps too much implicit commenting on my part. I've snipped= parts that we agree on and added couple comments tagged GIM>>. Regards, Greg ________________________________ [...] > Section 1.4 I think that in case of FIFO priority policy PSC must be use= d to guarantee deterministic switchover to protected path by analyzing MEP_= ID and introduction of tie breaking rule(s), not to leave it to an operator= . yw> not sure that you are really saying anything different from what the te= xt states. In the final analysis - the MEP_ID is assigned by the operator i= n the same way that an explicit priority would be assigned. The purpose of= this section is merely to clarify that the assignment of priority and the = consistency check of the priority definitions are out of scope of this docu= ment! GIM>> I've mentioned MEP-ID as potential source for tiebreaking but since M= EP-ID is not signalled by 1:n message, that's mute point. As suggested belo= w, document need to specify tiebraking procedure for bi-directional protect= ion switchover of two working paths of equal priority. > Section 3.3.1.1 - uni-directional non-locking 1:n scenario - simultaneous= detection in opposite directions. yw> Not sure what the comment is - are you suggesting another scenario to b= e explained? GIM>> It was original intention but now I realize that all working paths an= d protecting path are expected to be uni-directional, e.g. from LER-A to LE= R-Z and thus LER-A would do the local arbitration. > Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z remove W= 2 from P yw> There is a basic assumption here that the LER will not transport traffi= c from two working paths on the protection path simultaneously. Therefore,= when the text states that an LER "bridges W1 into P" the implication is th= at the W2 traffic is no longer being tranported on P. GIM>> Perhaps it can be made as explicit note in the document. > Section 4.3.2, as mentioned in note above, protection at LER-A and LER-Z = might be triggered by almost simulteneous failures of two working paths, e.= g. W1 and W2 respectively, of the same priority. Thus FIFO should be used b= ut since LER-A would protect W1 while LER-Z - W2 a tiebreaker should be use= d to avoid situation where both working paths would be partially locked out= and protection would not be useful. yw> Not sure what the comment here is - I agree that there is a need for a= tiebreaker, but I am not sure where you found text that precludes this. GIM>> I think that the document need to define such tiebreaking rule(s) not= merely allow them to be proprietary implemented. > > Some generalization question: "Can, and if "yes", is it worth it, 1:n be = viewed as special case of Shared Mesh Protection?" Personally, I think that= 1:n can be viewed as special case of SMP but optimization of operation for= 1:n makes it not worth of applying generic SMP solution. yw> My personal opinion is that 1:n has a major difference from SMP due to = the fact that the endpoints of the working paths and the protection path ar= e identical. Therefore there is no need for the additional coordination be= tween the endpoints that is necessary in SMP. There is also no need to coo= rdinate "shared segments" in 1:n protection - since the sharing here is of = the entire protection path. GIM>> I think we do agree on this one too. > > Thank you for your kind consideration. > > Regards, > Greg > --_000_FE60A4E52763E84B935532D7D9294FF13551008E80EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yaakov,
apologies for perhaps too much implicit commenting= on my=20 part. I've snipped parts that we agree on and added couple comments tagged= =20 GIM>>.
 
  &n= bsp; Regards,
        Greg

[...] 
 > Section 1.4 I think that in ca= se of=20 FIFO priority policy PSC must be used to guarantee deterministic switchover= to=20 protected path by analyzing MEP_ID and introduction of tie breaking rule(s)= , not=20 to leave it to an operator.

yw> not sure that you are really saying anything different from what = the=20 text states. In the final analysis - the MEP_ID is assigned by the operator= in=20 the same way that an explicit priority would be assigned.  The purpose= of=20 this section is merely to clarify that the assignment of priority and the=20 consistency check of the priority definitions are out of scope of this=20 document! 

GIM>> I've mentioned MEP-ID as potential source for=20 tiebreaking but since MEP-ID is not signalled by 1:n message, that's mute p= oint.=20 As suggested below, document need to specify tiebraking procedure=20 for bi-directional protection switchover of two working paths of= =20 equal priority. 

> Section 3.3.1.1 - uni-directional non-locking 1:n scenario -=20 simultaneous detection in opposite directions.

yw> Not sure what the comment is - are you suggesting another scenari= o to=20 be explained? 

GIM>> It was original intention but now I realize that all w= orking=20 paths and protecting path are expected to be uni-directional, e.g. from LER= -A to=20 LER-Z and thus LER-A would do the local arbitration.

> Section 3.3.3.3, Figure 8. Not clear when and if LER-A and LER-Z re= move=20 W2 from P

yw> There is a basic assumption here that the LER will not transport= =20 traffic from two working paths on the protection path simultaneously. = =20 Therefore, when the text states that an LER "bridges W1 into P" the implica= tion=20 is that the W2 traffic is no longer being tranported on P. 

GIM>> Perhaps it can be made as explicit note in the=20 document. 

> Section 4.3.2, as mentioned in note above, protection at LER-A and = LER-Z=20 might be triggered by almost simulteneous failures of two working paths, e.= g. W1=20 and W2 respectively, of the same priority. Thus FIFO should be used but sin= ce=20 LER-A would protect W1 while LER-Z - W2 a tiebreaker should be used to avoi= d=20 situation where both working paths would be partially locked out and protec= tion=20 would not be useful.

yw>  Not sure what the comment here is - I agree that there is a= need=20 for a tiebreaker, but I am not sure where you found text that precludes=20 this. 

GIM>> I think that the document need to define such tiebreak= ing=20 rule(s) not merely allow them to be proprietary=20 implemented. 

>  
> Some generalization question: "Can, and if "yes", is= it=20 worth it, 1:n be viewed as special case of Shared Mesh Protection?" Persona= lly,=20 I think that 1:n can be viewed as special case of SMP but optimization of=20 operation for 1:n makes it not worth of applying generic SMP solution.

yw> My personal opinion is that 1:n has a major difference from SMP d= ue to=20 the fact that the endpoints of the working paths and the protection path ar= e=20 identical.  Therefore there is no need for the additional coordination= =20 between the endpoints that is necessary in SMP.  There is also no need= to=20 coordinate "shared segments" in 1:n protection - since the sharing here is = of=20 the entire protection path. 

GIM>> I think we do agree on this one=20 too. 
>  
> Thank you for your kind=20 consideration.
>  
>       &= nbsp;=20 Regards,
>=20             &nb= sp;  =20 Greg
>  

--_000_FE60A4E52763E84B935532D7D9294FF13551008E80EUSAACMS0715e_-- From gregory.mirsky@ericsson.com Thu Mar 29 02:30:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BB221F8A27 for ; Thu, 29 Mar 2012 02:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp7hnZ9kmDgK for ; Thu, 29 Mar 2012 02:30:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA4C21F897A for ; Thu, 29 Mar 2012 02:30:03 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2T9U0Ha027047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 04:30:00 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 29 Mar 2012 05:29:59 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Thu, 29 Mar 2012 05:29:58 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:30:04 -0000 Dear Eric, I've snipped parts that we agree and in-lined my note tagged by GIM>> on ti= ebreaking of equal priority protection coordination. Regards, Greg=20 [...] EO# Numerically sorting by MEP_ID may not be the best way to determine pri= ority. Often the assignment of IDs (IP addrs, etc) comes from a different = NMS system than does the determining of LSP priority. We are simply saying= that there must be a priority mechanism, and that since we cannot signal p= riority, the exact mechanism is outside of the scope of the protocol. GIM>> I thought of using MEP-ID and wrote my original comment before I fini= shed reading the document to realize that MEP-ID is not being signaled. Mis= sed to edit my comment properly. [...] EO# I would argue that one should not have LSPs of the "same priority". There must be a tiebreaker that can handle all possible conflicts, no matte= r what order or how many failures. Once there is a deterministic mechanism= for all cases, it means that all LSPs are of different priority. =20 GIM>> Tiebreaking would be used only in case of simulteneous failure of two= working paths of equal priority. Otherwise, equal priority would not preem= pt one that is already is using the protection path, i.e. FIFO will fully w= ork in this case. From eosborne@cisco.com Thu Mar 29 04:38:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1668F21F88EB for ; Thu, 29 Mar 2012 04:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfJk8ERrUTFA for ; Thu, 29 Mar 2012 04:38:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFF21F88EA for ; Thu, 29 Mar 2012 04:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=1072; q=dns/txt; s=iport; t=1333021081; x=1334230681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tRWwWZmbvEkmVfmgo3UXqI2I+/ZS0OMfPWgY49A3+FE=; b=Ou4kyGtVNPHHKThdrYm5iwAWjInAW0kWLLig0SYK2YQAsWORn1KYvyjw 3JK1AoFVrfP2u2hsYMnZz2H5OAB9ZiWOcirYrdKOjxmBhJstd1jOr/qWj FmL6+4JiEhSqstjtXgwWTuftESnldN0a2VVCeOdBY9D4aygJw+fkywXdr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE5IdE+tJV2a/2dsb2JhbABEuQ+BB4IJAQEBAwESAR0KRAsCAQgiBhgGAVYBAQQBGhqHYwWbb58kkDxjBIhYm06BaIMF X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="70412928" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 29 Mar 2012 11:38:01 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBc10U003201; Thu, 29 Mar 2012 11:38:01 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 06:38:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 06:38:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQA== References: From: "Eric Osborne (eosborne)" To: "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 29 Mar 2012 11:38:01.0079 (UTC) FILETIME=[65670070:01CD0DA0] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:38:02 -0000 =20 > EO# I would argue that one should not have LSPs of the "same priority". > There must be a tiebreaker that can handle all possible conflicts, no > matter what order or how many failures. Once there is a deterministic > mechanism for all cases, it means that all LSPs are of different priority. >=20 > GIM>> Tiebreaking would be used only in case of simulteneous failure of > two working paths of equal priority. Otherwise, equal priority would not > preempt one that is already is using the protection path, i.e. FIFO will > fully work in this case. I think the behavior you describe is more about SMP than 1:n. In 1:n we'd always made the assumption that, in a given protection domain, only a single W can be protected at a time. To do otherwise (say, W1 and W2 using P) is not possible using PSC signaling since we can only indicate a single LSP in the FPath field. =20 Nothing precludes multiple protection domains from using the same underlying link and/or same endpoints, but that's a network design consideration. eric From maarten.vissers@huawei.com Thu Mar 29 04:44:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2521F8973 for ; Thu, 29 Mar 2012 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eM+pRe6fbmu for ; Thu, 29 Mar 2012 04:44:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 934A521F88E8 for ; Thu, 29 Mar 2012 04:44:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM23260; Thu, 29 Mar 2012 07:44:33 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:43:06 -0700 Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 04:43:02 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 12:43:00 +0100 From: Maarten vissers To: "mpls@ietf.org" Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALuLA Date: Thu, 29 Mar 2012 11:42:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:44:46 -0000 Traditional tiebreaker (in use in e.g. 1:n MSP in SDH) is the Working conne= ction identifier.=20 Wi has higher priority than Wj (i>j). With Protection connection being associated with identifier "0", Protection= has always higher priority than any of the Working connections. Regards, Maarten -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: donderdag 29 maart 2012 13:38 To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 =20 > EO# I would argue that one should not have LSPs of the "same priority". > There must be a tiebreaker that can handle all possible conflicts, no > matter what order or how many failures. Once there is a deterministic > mechanism for all cases, it means that all LSPs are of different priority. >=20 > GIM>> Tiebreaking would be used only in case of simulteneous failure of > two working paths of equal priority. Otherwise, equal priority would not > preempt one that is already is using the protection path, i.e. FIFO will > fully work in this case. I think the behavior you describe is more about SMP than 1:n. In 1:n we'd always made the assumption that, in a given protection domain, only a single W can be protected at a time. To do otherwise (say, W1 and W2 using P) is not possible using PSC signaling since we can only indicate a single LSP in the FPath field. =20 Nothing precludes multiple protection domains from using the same underlying link and/or same endpoints, but that's a network design consideration. eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Mar 29 04:51:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD50621F8902 for ; Thu, 29 Mar 2012 04:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izqqd0WhmKjV for ; Thu, 29 Mar 2012 04:51:10 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C4B2021F87B1 for ; Thu, 29 Mar 2012 04:51:10 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2TBp7O4031014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 06:51:07 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 29 Mar 2012 07:51:06 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Thu, 29 Mar 2012 07:51:05 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:51:11 -0000 Hi Eric, Below is scenario that in my view would benefit from a tiebreaking rule. Wo= uld appreciate your consideration and feedback whether this is realistic an= d not breaking PSC: - Assume that LSP P is not being used or used by working path of priority N= ; - LER-A detects failure of working path Wi of priority M, where M > N, LER-= A sends SF(1,0) to LER-Z listing Wi as Fpath; - almost simulteneously, at least before it receives SF from LER-A, LER-Z d= etects failure of Wj that has priority M. LER-Z sends SF(1,0) listing Wj as= Fpath; - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D Priority(= Wj) would not change to protecting Wi path; - LER-A receives SF(1,0) from LER-Z and for the same reason would keep Wi a= s path to protect. Is that sequence, scenario correct? Would LER-A and LER-Z converge on selec= ting one path they'd protect? Regards, Greg -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, March 29, 2012 4:38 AM To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 =20 > EO# I would argue that one should not have LSPs of the "same priority". > There must be a tiebreaker that can handle all possible conflicts, no=20 > matter what order or how many failures. Once there is a deterministic=20 > mechanism for all cases, it means that all LSPs are of different priority. >=20 > GIM>> Tiebreaking would be used only in case of simulteneous failure of > two working paths of equal priority. Otherwise, equal priority would not > preempt one that is already is using the protection path, i.e. FIFO will > fully work in this case. I think the behavior you describe is more about SMP than 1:n. In 1:n we'd = always made the assumption that, in a given protection domain, only a singl= e W can be protected at a time. To do otherwise (say, W1 and W2 using P) i= s not possible using PSC signaling since we can only indicate a single LSP = in the FPath field. =20 Nothing precludes multiple protection domains from using the same underlyin= g link and/or same endpoints, but that's a network design consideration. eric From eosborne@cisco.com Thu Mar 29 05:11:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC2221F89B2 for ; Thu, 29 Mar 2012 05:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYSXyHSHTzA6 for ; Thu, 29 Mar 2012 05:11:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB121F8912 for ; Thu, 29 Mar 2012 05:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=3882; q=dns/txt; s=iport; t=1333023060; x=1334232660; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=trHKzw4J1ggLJb/2aT2HO0NQfXNURtrnTImdwCfB9qE=; b=ek3FFQ9QdKAvfId6PKeeZ+V8OOZaiq/XOP8kxQHcQY+IJooIet+8SAj9 HAw9i6uMN/BZX7+WS7TN0r9riHI6nVJJ7e+q2rFApb4heQJ/xwIe53Pcy W+sw31C+jch/vVZ/mwQ2vGKYC3M4JlU9Wd75rnj0RmyclQWhMfL9C7UFH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOdPdE+tJXG//2dsb2JhbABEuQ+BB4IJAQEBBBIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2ibbJ8hkDxjBIhYm06BaIMF X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="70203890" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 29 Mar 2012 12:10:59 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TCAxMN011783; Thu, 29 Mar 2012 12:10:59 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 07:10:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 07:11:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52A= References: From: "Eric Osborne (eosborne)" To: "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 29 Mar 2012 12:10:59.0530 (UTC) FILETIME=[00A6AAA0:01CD0DA5] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:11:01 -0000 Let me rewrite the messages a little bit in your example. Rather than SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in question. And let's also say that the priority of Wi > Wj, just as you have done. I also note that setting Path=3D=3D0 means you're using locking mode. = This is certainly a valid case, I just want to confirm that it's your intention? at t0, no failure. at t1,=20 LER-A sends SF(Wi,0) to LER-Z AND LER-Z sends SF(Wj,0) to LER-Z at t2, LER-A receives SF(Wj,0). It ignores it, since it has already decided that Wi needs the protect channel. LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, shortly after t2. LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a unidirectional locking preemption case, as in section 3.3.3.2 of the draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what 3.3.3.2 describes as LER-A's behavior at t1. =20 In this way, both LER-A and LER-Z converge on protecting Wi. Since it is locking, no transmission of packets takes place since neither side had ACKd the other side's SF. Does that reflect your question, and does it answer it? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 1:51 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Eric, > Below is scenario that in my view would benefit from a tiebreaking rule. > Would appreciate your consideration and feedback whether this is realistic > and not breaking PSC: > - Assume that LSP P is not being used or used by working path of priority > N; > - LER-A detects failure of working path Wi of priority M, where M > N, > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > - almost simulteneously, at least before it receives SF from LER-A, LER-Z > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing Wj > as Fpath; > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D Priority(Wj) > would not change to protecting Wi path; > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep Wi > as path to protect. > Is that sequence, scenario correct? Would LER-A and LER-Z converge on > selecting one path they'd protect? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 4:38 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > > EO# I would argue that one should not have LSPs of the "same > priority". > > There must be a tiebreaker that can handle all possible conflicts, no > > matter what order or how many failures. Once there is a deterministic > > mechanism for all cases, it means that all LSPs are of different > priority. > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > of > > two working paths of equal priority. Otherwise, equal priority would > not > > preempt one that is already is using the protection path, i.e. FIFO > will > > fully work in this case. >=20 >=20 > I think the behavior you describe is more about SMP than 1:n. In 1:n we'd > always made the assumption that, in a given protection domain, only a > single W can be protected at a time. To do otherwise (say, W1 and W2 > using P) is not possible using PSC signaling since we can only indicate a > single LSP in the FPath field. >=20 > Nothing precludes multiple protection domains from using the same > underlying link and/or same endpoints, but that's a network design > consideration. >=20 >=20 >=20 >=20 > eric From gregory.mirsky@ericsson.com Thu Mar 29 05:21:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034BC21F8A39 for ; Thu, 29 Mar 2012 05:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7Em45O-YSuW for ; Thu, 29 Mar 2012 05:20:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8521F8A36 for ; Thu, 29 Mar 2012 05:20:58 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2TCKkHt031761; Thu, 29 Mar 2012 07:20:56 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 29 Mar 2012 08:20:48 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Thu, 29 Mar 2012 08:20:46 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:21:00 -0000 =20 Hi Eric, I agree with your logic and that current document handles scenario you pres= ent (prioties of simulteneously failed paths are different) well. But I sti= ll am concerned with case when priorities of Wi and Wj are equal. If you th= ink that it might present a problem, then I see two possible ways to addres= s: - disallow multiple LSPs being assigned equal priority (not the best way); - define tiebreaking rule(s). Regards, Greg -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, March 29, 2012 5:11 AM To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 Let me rewrite the messages a little bit in your example. Rather than SF(1= ,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in questi= on. And let's also say that the priority of Wi > Wj, just as you have done= . I also note that setting Path=3D=3D0 means you're using locking mode. This= is certainly a valid case, I just want to confirm that it's your intention= ? at t0, no failure. at t1, LER-A sends SF(Wi,0) to LER-Z AND LER-Z sends SF(Wj,0) to LER-Z at t2, LER-A receives SF(Wj,0). It ignores it, since it has already decide= d that Wi needs the protect channel. LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, shor= tly after t2. LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a unidirectional= locking preemption case, as in section 3.3.3.2 of the draft. LER-Z respon= ds to the SF(Wi,0) with NR(Wi,0). This is what 3.3.3.2 describes as LER-A's behavior at t1. =20 In this way, both LER-A and LER-Z converge on protecting Wi. Since it is l= ocking, no transmission of packets takes place since neither side had ACKd = the other side's SF. Does that reflect your question, and does it answer it? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 1:51 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten;=20 > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Eric, > Below is scenario that in my view would benefit from a tiebreaking rule. > Would appreciate your consideration and feedback whether this is realistic > and not breaking PSC: > - Assume that LSP P is not being used or used by working path of priority > N; > - LER-A detects failure of working path Wi of priority M, where M > N,=20 > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > - almost simulteneously, at least before it receives SF from LER-A, LER-Z > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing Wj > as Fpath; > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D Priority(Wj) > would not change to protecting Wi path; > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep Wi > as path to protect. > Is that sequence, scenario correct? Would LER-A and LER-Z converge on=20 > selecting one path they'd protect? >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 4:38 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;=20 > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > > EO# I would argue that one should not have LSPs of the "same > priority". > > There must be a tiebreaker that can handle all possible conflicts, no > > matter what order or how many failures. Once there is a deterministic > > mechanism for all cases, it means that all LSPs are of different > priority. > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > of > > two working paths of equal priority. Otherwise, equal priority would > not > > preempt one that is already is using the protection path, i.e. FIFO > will > > fully work in this case. >=20 >=20 > I think the behavior you describe is more about SMP than 1:n. In 1:n we'd > always made the assumption that, in a given protection domain, only a=20 > single W can be protected at a time. To do otherwise (say, W1 and W2=20 > using P) is not possible using PSC signaling since we can only indicate a > single LSP in the FPath field. >=20 > Nothing precludes multiple protection domains from using the same=20 > underlying link and/or same endpoints, but that's a network design=20 > consideration. >=20 >=20 >=20 >=20 > eric From eosborne@cisco.com Thu Mar 29 05:30:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48721F8A83 for ; Thu, 29 Mar 2012 05:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNsZQTcV59VS for ; Thu, 29 Mar 2012 05:30:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5121F8A7F for ; Thu, 29 Mar 2012 05:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=6483; q=dns/txt; s=iport; t=1333024240; x=1334233840; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TcP6P3j9zEOZp4n6jXASt9MEmWk7vdhlNkj1xNxmegU=; b=XqgLC2PoId0Lg4AGakQEXf5Q6g97+00ZmUhccIeKVEsj1n7h1CpNvle4 3EHt3SnMayatQDDPVgxLLq8h+RG+GATkQkC8sRiLhuSeiPD6sexNYberF GHH5iNpd5VZ3UPZ1gXQAllkQiIH12huz7AQjNfVxZHP9VTxTy0KefD0/Q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADVVdE+tJXHA/2dsb2JhbABEuQ2BB4IJAQEBBBIBHQpLBAIBCBEEAQELBhcBBgFFCQgCBAESCBqHaJtpnx+QPGMEiFibT4FogwU X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="70425492" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 29 Mar 2012 12:30:40 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2TCUd9M030694; Thu, 29 Mar 2012 12:30:39 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 07:30:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 07:30:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmA References: From: "Eric Osborne (eosborne)" To: "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 29 Mar 2012 12:30:39.0419 (UTC) FILETIME=[BFEB70B0:01CD0DA7] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:30:42 -0000 I still go back to my point that since only one W can ever use P, there really is no such thing as 'equal priority'. We must have a priority scheme, whether it is the channel number in Fpath or whether it's some other mechanism, so that we know that Wi always beats Wj no matter what order the events occur in. We had initially discussed leaving the exact priority scheme to the protection endpoints, but I see now that that may not work well across vendors.=20 I think we have a few choices: 1) some sort of explicit priority field 2) define priority as the FPath value, lower is better (as Maarten points out, this is the current practice in SDH). Either one of these have costs to them. =20 Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in locking mode means nobody is protected until both ends converge. This also makes things (potentially) very dynamic which is, I think, not what we want in a protocol that has to converge in real time. Doing #2 means that if I have W1...W5 already provisioned and I want to add W3.1, I need to reprovision W4 and W5, which may be disruptive. How often does this sort of thing happen in transport networks? Is it a real problem? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 2:21 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > Hi Eric, > I agree with your logic and that current document handles scenario you > present (prioties of simulteneously failed paths are different) well. But > I still am concerned with case when priorities of Wi and Wj are equal. If > you think that it might present a problem, then I see two possible ways to > address: > - disallow multiple LSPs being assigned equal priority (not the best way); > - define tiebreaking rule(s). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 5:11 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Let me rewrite the messages a little bit in your example. Rather than > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in > question. And let's also say that the priority of Wi > Wj, just as you > have done. >=20 > I also note that setting Path=3D=3D0 means you're using locking mode. This is > certainly a valid case, I just want to confirm that it's your intention? >=20 > at t0, no failure. >=20 > at t1, > LER-A sends SF(Wi,0) to LER-Z > AND > LER-Z sends SF(Wj,0) to LER-Z >=20 > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > decided that Wi needs the protect channel. >=20 > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, > shortly after t2. >=20 > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > unidirectional locking preemption case, as in section 3.3.3.2 of the > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > 3.3.3.2 describes as LER-A's behavior at t1. >=20 > In this way, both LER-A and LER-Z converge on protecting Wi. Since it is > locking, no transmission of packets takes place since neither side had > ACKd the other side's SF. >=20 > Does that reflect your question, and does it answer it? >=20 >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 1:51 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > Below is scenario that in my view would benefit from a tiebreaking > rule. > > Would appreciate your consideration and feedback whether this is > realistic > > and not breaking PSC: > > - Assume that LSP P is not being used or used by working path of > priority > > N; > > - LER-A detects failure of working path Wi of priority M, where M > N, > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > - almost simulteneously, at least before it receives SF from LER-A, > LER-Z > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing > Wj > > as Fpath; > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > Priority(Wj) > > would not change to protecting Wi path; > > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep > Wi > > as path to protect. > > Is that sequence, scenario correct? Would LER-A and LER-Z converge on > > selecting one path they'd protect? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 4:38 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > EO# I would argue that one should not have LSPs of the "same > > priority". > > > There must be a tiebreaker that can handle all possible conflicts, > no > > > matter what order or how many failures. Once there is a > deterministic > > > mechanism for all cases, it means that all LSPs are of different > > priority. > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > > of > > > two working paths of equal priority. Otherwise, equal priority would > > not > > > preempt one that is already is using the protection path, i.e. FIFO > > will > > > fully work in this case. > > > > > > I think the behavior you describe is more about SMP than 1:n. In 1:n > we'd > > always made the assumption that, in a given protection domain, only a > > single W can be protected at a time. To do otherwise (say, W1 and W2 > > using P) is not possible using PSC signaling since we can only > indicate a > > single LSP in the FPath field. > > > > Nothing precludes multiple protection domains from using the same > > underlying link and/or same endpoints, but that's a network design > > consideration. > > > > > > > > > > eric From cts@etri.re.kr Thu Mar 29 05:39:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1C21F8AF1 for ; Thu, 29 Mar 2012 05:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.331 X-Spam-Level: X-Spam-Status: No, score=-100.331 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_HTML_MOSTLY=0.001, MPART_ALT_DIFF=0.739, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGdiCAGoIoWD for ; Thu, 29 Mar 2012 05:39:40 -0700 (PDT) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by ietfa.amsl.com (Postfix) with ESMTP id 80A7C21F8AA9 for ; Thu, 29 Mar 2012 05:39:40 -0700 (PDT) Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Thu, 29 Mar 2012 21:39:38 +0900 Priority: normal thread-index: Ac0NqQDor5T0LgmDQx+B7Bd1dDYa6A== Thread-Topic: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 From: "Taesik Cheung" To: "Gregory Mirsky" , "Eric Osborne \(eosborne\)" , , "Yaacov Weingarten" , Date: Thu, 29 Mar 2012 21:39:37 +0900 Comment: ??, ?, Message-ID: <900BC12719FF47ED969EBEB931950B1B@etri.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3AA5_01CD0DF4.70D2FFF0" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 X-OriginalArrivalTime: 29 Mar 2012 12:39:38.0170 (UTC) FILETIME=[010A51A0:01CD0DA9] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Taesik Cheung List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:39:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_3AA5_01CD0DF4.70D2FFF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ------=_NextPart_000_3AA5_01CD0DF4.70D2FFF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IEFyaWFsOyBGT05ULVNJWkU6IDEwcHQiIGlkPW1zZ2Jv ZHk+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgV09SRC1CUkVBSzog YnJlYWstYWxsIj4NCjxESVY+DQo8RElWIHN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBGT05U LVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIEdyZWcsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD5JbiB5b3VyIHNjZW5hcmlvLCBzb21lIGNvcnJlY3Rpb25zIG1heSBiZSByZXF1 aXJlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+TEVSLUEgc2VuZHMgU0Yo aSwwKSBhbmQgcmVjZWl2ZXMgU0YoaiwwKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+TEVSLVogc2VuZHMgU0YoaiwwKSBhbmQgcmVjZWl2ZXMgU0YoaSwwKS48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsPkkgdGhpbmsgdGhhdCBzaWduYWwgbnVtYmVyIChpLGopIGNhbiBiZSB1c2Vk IGZvciB0aWUtYnJlYWtlciBhcyBNYWFydGluIHNhaWQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5SZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD5UYWVzaWs8L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPjwvRElWPjwvRElWPjwvRElWPjxCUj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxC Uj48Qj5Gcm9tOjwvQj4gIkdyZWdvcnkgTWlyc2t5IiAmbHQ7Z3JlZ29yeS5taXJza3lAZXJpY3Nz b24uY29tJmd0OzxCUj48Qj5Gcm9tIERhdGU6PC9CPiAyMDEyLTAzLTI5IFBNIDg6NTE6MDU8QlI+ PEI+VG86PC9CPiAiRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkiICZsdDtlb3Nib3JuZUBjaXNjby5j b20mZ3Q7LCAiemhhbmcuZmVpM0B6dGUuY29tLmNuIiAmbHQ7emhhbmcuZmVpM0B6dGUuY29tLmNu Jmd0OywgIllhYWNvdiBXZWluZ2FydGVuIiAmbHQ7d3lhYWNvdkBnbWFpbC5jb20mZ3Q7LCAibXBs c0BpZXRmLm9yZyIgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7PEJSPjxCPkNjOjwvQj4gPEJSPjxCPlN1 YmplY3Q6PC9CPiBSZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWV6eS1tcGxzLTF0b24tcHJv dGVjdGlvbi0wMTxCUj48QlI+DQo8RElWPjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBm b3JtYXQgLS0+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPkhpIEVyaWMsPEJSPkJlbG93IGlzIHNjZW5h cmlvIHRoYXQgaW4gbXkgdmlldyB3b3VsZCBiZW5lZml0IGZyb20gYSB0aWVicmVha2luZyBydWxl LiBXb3VsZCBhcHByZWNpYXRlIHlvdXIgY29uc2lkZXJhdGlvbiBhbmQgZmVlZGJhY2sgd2hldGhl ciB0aGlzIGlzIHJlYWxpc3RpYyBhbmQgbm90IGJyZWFraW5nIFBTQzo8QlI+LSBBc3N1bWUgdGhh dCBMU1AgUCBpcyBub3QgYmVpbmcgdXNlZCBvciB1c2VkIGJ5IHdvcmtpbmcgcGF0aCBvZiBwcmlv cml0eSBOOzxCUj4tIExFUi1BIGRldGVjdHMgZmFpbHVyZSBvZiB3b3JraW5nIHBhdGggV2kgb2Yg cHJpb3JpdHkgTSwgd2hlcmUgTSAmZ3Q7IE4sIExFUi1BIHNlbmRzIFNGKDEsMCkgdG8gTEVSLVog bGlzdGluZyBXaSBhcyBGcGF0aDs8QlI+LSBhbG1vc3Qgc2ltdWx0ZW5lb3VzbHksIGF0IGxlYXN0 IGJlZm9yZSBpdCByZWNlaXZlcyBTRiBmcm9tIExFUi1BLCBMRVItWiBkZXRlY3RzIGZhaWx1cmUg b2YgV2ogdGhhdCBoYXMgcHJpb3JpdHkgTS4gTEVSLVogc2VuZHMgU0YoMSwwKSBsaXN0aW5nIFdq IGFzIEZwYXRoOzxCUj4tIExFUi1aIHJlY2VpdmVzIFNGKDEsMCkgZnJvbSBMRVItQSBhbmQgc2lu Y2UgUHJpb3JpdHkoV2kpID09IFByaW9yaXR5KFdqKSB3b3VsZCBub3QgY2hhbmdlIHRvIHByb3Rl Y3RpbmcgV2kgcGF0aDs8QlI+LSBMRVItQSByZWNlaXZlcyBTRigxLDApIGZyb20gTEVSLVogYW5k IGZvciB0aGUgc2FtZSByZWFzb24gd291bGQga2VlcCBXaSBhcyBwYXRoIHRvIHByb3RlY3QuPEJS PklzIHRoYXQgc2VxdWVuY2UsIHNjZW5hcmlvIGNvcnJlY3Q/IFdvdWxkIExFUi1BIGFuZCBMRVIt WiBjb252ZXJnZSBvbiBzZWxlY3Rpbmcgb25lIHBhdGggdGhleSdkIHByb3RlY3Q/PEJSPjxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPEJSPjxCUj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj5Gcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbPEEgaHJlZj0ibWFpbHRv OmVvc2Jvcm5lQGNpc2NvLmNvbSIgdGFyZ2V0PV9ibGFuaz5tYWlsdG86ZW9zYm9ybmVAY2lzY28u Y29tPC9BPl08QlI+U2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDEyIDQ6MzggQU08QlI+VG86 IEdyZWdvcnkgTWlyc2t5OyB6aGFuZy5mZWkzQHp0ZS5jb20uY247IFlhYWNvdiBXZWluZ2FydGVu OyBtcGxzQGlldGYub3JnPEJSPlN1YmplY3Q6IFJFOiBDb21tZW50cyBvbiBkcmFmdC1lenktbXBs cy0xdG9uLXByb3RlY3Rpb24tMDE8QlI+PEJSPjxCUj4mZ3Q7IEVPIyZuYnNwOyBJIHdvdWxkIGFy Z3VlIHRoYXQgb25lIHNob3VsZCBub3QgaGF2ZSBMU1BzIG9mIHRoZSAic2FtZTxCUj5wcmlvcml0 eSIuPEJSPiZndDsgVGhlcmUgbXVzdCBiZSBhIHRpZWJyZWFrZXIgdGhhdCBjYW4gaGFuZGxlIGFs bCBwb3NzaWJsZSBjb25mbGljdHMsIG5vPEJSPiZndDsgbWF0dGVyIHdoYXQgb3JkZXIgb3IgaG93 IG1hbnkgZmFpbHVyZXMuJm5ic3A7IE9uY2UgdGhlcmUgaXMgYSBkZXRlcm1pbmlzdGljPEJSPiZn dDsgbWVjaGFuaXNtIGZvciBhbGwgY2FzZXMsIGl0IG1lYW5zIHRoYXQgYWxsIExTUHMgYXJlIG9m IGRpZmZlcmVudDxCUj5wcmlvcml0eS48QlI+Jmd0OzxCUj4mZ3Q7IEdJTSZndDsmZ3Q7IFRpZWJy ZWFraW5nIHdvdWxkIGJlIHVzZWQgb25seSBpbiBjYXNlIG9mIHNpbXVsdGVuZW91cyBmYWlsdXJl PEJSPm9mPEJSPiZndDsgdHdvIHdvcmtpbmcgcGF0aHMgb2YgZXF1YWwgcHJpb3JpdHkuIE90aGVy d2lzZSwgZXF1YWwgcHJpb3JpdHkgd291bGQ8QlI+bm90PEJSPiZndDsgcHJlZW1wdCBvbmUgdGhh dCBpcyBhbHJlYWR5IGlzIHVzaW5nIHRoZSBwcm90ZWN0aW9uIHBhdGgsIGkuZS4gRklGTzxCUj53 aWxsPEJSPiZndDsgZnVsbHkgd29yayBpbiB0aGlzIGNhc2UuPEJSPjxCUj48QlI+SSB0aGluayB0 aGUgYmVoYXZpb3IgeW91IGRlc2NyaWJlIGlzIG1vcmUgYWJvdXQgU01QIHRoYW4gMTpuLiZuYnNw OyBJbiAxOm4gd2UnZCBhbHdheXMgbWFkZSB0aGUgYXNzdW1wdGlvbiB0aGF0LCBpbiBhIGdpdmVu IHByb3RlY3Rpb24gZG9tYWluLCBvbmx5IGEgc2luZ2xlIFcgY2FuIGJlIHByb3RlY3RlZCBhdCBh IHRpbWUuJm5ic3A7IFRvIGRvIG90aGVyd2lzZSAoc2F5LCBXMSBhbmQgVzIgdXNpbmcgUCkgaXMg bm90IHBvc3NpYmxlIHVzaW5nIFBTQyBzaWduYWxpbmcgc2luY2Ugd2UgY2FuIG9ubHkgaW5kaWNh dGUgYSBzaW5nbGUgTFNQIGluIHRoZSBGUGF0aCBmaWVsZC4mbmJzcDs8QlI+PEJSPk5vdGhpbmcg cHJlY2x1ZGVzIG11bHRpcGxlIHByb3RlY3Rpb24gZG9tYWlucyBmcm9tIHVzaW5nIHRoZSBzYW1l IHVuZGVybHlpbmcgbGluayBhbmQvb3Igc2FtZSBlbmRwb2ludHMsIGJ1dCB0aGF0J3MgYSBuZXR3 b3JrIGRlc2lnbiBjb25zaWRlcmF0aW9uLjxCUj48QlI+PEJSPjxCUj48QlI+ZXJpYzxCUj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5tcGxzIG1haWxp bmcgbGlzdDxCUj5tcGxzQGlldGYub3JnPEJSPjxBIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PV9ibGFuaz5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L0E+PEJSPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+PC9E SVY+ ------=_NextPart_000_3AA5_01CD0DF4.70D2FFF0-- From maarten.vissers@huawei.com Thu Mar 29 05:56:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B82021F8AC9 for ; Thu, 29 Mar 2012 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2QUeqJ4qtjH for ; Thu, 29 Mar 2012 05:56:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D021F8AC0 for ; Thu, 29 Mar 2012 05:56:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM27100; Thu, 29 Mar 2012 08:55:59 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 05:54:25 -0700 Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 05:54:30 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 13:54:27 +0100 From: Maarten vissers To: "Eric Osborne (eosborne)" , Gregory Mirsky , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MA= Date: Thu, 29 Mar 2012 12:54:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:56:01 -0000 1:n protection in a transport network at the path layer is not a very commo= n protection switching application. This is due to the fact that 1:n protec= tion requires n+1 diverse routed paths. How many of those diverse routed pa= ths will be available in typical transport networks? Not many... very often= two diverse routed paths is all you can get... and this is only truly guar= anteed over time if the network domain is organized as separate A and a B n= etworks. Otherwise maintenance on the network may result in temporary rerou= ting of virtual links, resulting in routing W and P connections over the sa= me fiber, node or duct. With n>2, separate networks can not be used and one has to find n+1 diverse= routed paths through the network and guarantee that neither maintenance ac= tivities, nor network upgrades result in rerouting of the virtual links so = that W and P connections pass through the same fiber, node or duct. 1:n protection has been used in SDH/SONET for SDH/SONET regenerator protect= ion (1:7 and 1:11 systems, in early 90's) and for SDH line card protection = (end of 90's). Regards, Maarten -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: donderdag 29 maart 2012 14:31 To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 I still go back to my point that since only one W can ever use P, there really is no such thing as 'equal priority'. We must have a priority scheme, whether it is the channel number in Fpath or whether it's some other mechanism, so that we know that Wi always beats Wj no matter what order the events occur in. We had initially discussed leaving the exact priority scheme to the protection endpoints, but I see now that that may not work well across vendors.=20 I think we have a few choices: 1) some sort of explicit priority field 2) define priority as the FPath value, lower is better (as Maarten points out, this is the current practice in SDH). Either one of these have costs to them. =20 Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in locking mode means nobody is protected until both ends converge. This also makes things (potentially) very dynamic which is, I think, not what we want in a protocol that has to converge in real time. Doing #2 means that if I have W1...W5 already provisioned and I want to add W3.1, I need to reprovision W4 and W5, which may be disruptive. How often does this sort of thing happen in transport networks? Is it a real problem? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 2:21 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > Hi Eric, > I agree with your logic and that current document handles scenario you > present (prioties of simulteneously failed paths are different) well. But > I still am concerned with case when priorities of Wi and Wj are equal. If > you think that it might present a problem, then I see two possible ways to > address: > - disallow multiple LSPs being assigned equal priority (not the best way); > - define tiebreaking rule(s). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 5:11 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Let me rewrite the messages a little bit in your example. Rather than > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in > question. And let's also say that the priority of Wi > Wj, just as you > have done. >=20 > I also note that setting Path=3D=3D0 means you're using locking mode. This is > certainly a valid case, I just want to confirm that it's your intention? >=20 > at t0, no failure. >=20 > at t1, > LER-A sends SF(Wi,0) to LER-Z > AND > LER-Z sends SF(Wj,0) to LER-Z >=20 > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > decided that Wi needs the protect channel. >=20 > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, > shortly after t2. >=20 > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > unidirectional locking preemption case, as in section 3.3.3.2 of the > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > 3.3.3.2 describes as LER-A's behavior at t1. >=20 > In this way, both LER-A and LER-Z converge on protecting Wi. Since it is > locking, no transmission of packets takes place since neither side had > ACKd the other side's SF. >=20 > Does that reflect your question, and does it answer it? >=20 >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 1:51 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > Below is scenario that in my view would benefit from a tiebreaking > rule. > > Would appreciate your consideration and feedback whether this is > realistic > > and not breaking PSC: > > - Assume that LSP P is not being used or used by working path of > priority > > N; > > - LER-A detects failure of working path Wi of priority M, where M > N, > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > - almost simulteneously, at least before it receives SF from LER-A, > LER-Z > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing > Wj > > as Fpath; > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > Priority(Wj) > > would not change to protecting Wi path; > > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep > Wi > > as path to protect. > > Is that sequence, scenario correct? Would LER-A and LER-Z converge on > > selecting one path they'd protect? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 4:38 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > EO# I would argue that one should not have LSPs of the "same > > priority". > > > There must be a tiebreaker that can handle all possible conflicts, > no > > > matter what order or how many failures. Once there is a > deterministic > > > mechanism for all cases, it means that all LSPs are of different > > priority. > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > > of > > > two working paths of equal priority. Otherwise, equal priority would > > not > > > preempt one that is already is using the protection path, i.e. FIFO > > will > > > fully work in this case. > > > > > > I think the behavior you describe is more about SMP than 1:n. In 1:n > we'd > > always made the assumption that, in a given protection domain, only a > > single W can be protected at a time. To do otherwise (say, W1 and W2 > > using P) is not possible using PSC signaling since we can only > indicate a > > single LSP in the FPath field. > > > > Nothing precludes multiple protection domains from using the same > > underlying link and/or same endpoints, but that's a network design > > consideration. > > > > > > > > > > eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Mar 29 05:59:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0014B21F8AF2 for ; Thu, 29 Mar 2012 05:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvV8qW5oWskq for ; Thu, 29 Mar 2012 05:59:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2689421F8AB0 for ; Thu, 29 Mar 2012 05:59:02 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2TCwss5002417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Mar 2012 07:58:55 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 29 Mar 2012 08:58:54 -0400 From: Gregory Mirsky To: "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Thu, 29 Mar 2012 08:58:52 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAAETIeA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:59:04 -0000 Hi Eric, I think that we're converging and agree that there's scenario that requires= either explicit priority signaling or tiebreaking rule based on available = information. Personally I prefer option #2. I think that paths can be index= ed with some gaps so that, if need to be, new paths of the same priority ca= n be added with lower indexes. Regards, Greg -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: Thursday, March 29, 2012 5:31 AM To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 I still go back to my point that since only one W can ever use P, there rea= lly is no such thing as 'equal priority'. We must have a priority scheme, = whether it is the channel number in Fpath or whether it's some other mechan= ism, so that we know that Wi always beats Wj no matter what order the event= s occur in. We had initially discussed leaving the exact priority scheme to the protect= ion endpoints, but I see now that that may not work well across vendors.=20 I think we have a few choices: 1) some sort of explicit priority field 2) define priority as the FPath value, lower is better (as Maarten points o= ut, this is the current practice in SDH). Either one of these have costs to them. =20 Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in lock= ing mode means nobody is protected until both ends converge. This also mak= es things (potentially) very dynamic which is, I think, not what we want in= a protocol that has to converge in real time. Doing #2 means that if I have W1...W5 already provisioned and I want to add= W3.1, I need to reprovision W4 and W5, which may be disruptive. How often= does this sort of thing happen in transport networks? Is it a real proble= m? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 2:21 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten;=20 > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > Hi Eric, > I agree with your logic and that current document handles scenario you=20 > present (prioties of simulteneously failed paths are different) well. But > I still am concerned with case when priorities of Wi and Wj are equal. If > you think that it might present a problem, then I see two possible ways to > address: > - disallow multiple LSPs being assigned equal priority (not the best way); > - define tiebreaking rule(s). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 5:11 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;=20 > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Let me rewrite the messages a little bit in your example. Rather than=20 > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in > question. And let's also say that the priority of Wi > Wj, just as you > have done. >=20 > I also note that setting Path=3D=3D0 means you're using locking mode. This is > certainly a valid case, I just want to confirm that it's your intention? >=20 > at t0, no failure. >=20 > at t1, > LER-A sends SF(Wi,0) to LER-Z > AND > LER-Z sends SF(Wj,0) to LER-Z >=20 > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already=20 > decided that Wi needs the protect channel. >=20 > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3,=20 > shortly after t2. >=20 > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a=20 > unidirectional locking preemption case, as in section 3.3.3.2 of the=20 > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > 3.3.3.2 describes as LER-A's behavior at t1. >=20 > In this way, both LER-A and LER-Z converge on protecting Wi. Since it is > locking, no transmission of packets takes place since neither side had=20 > ACKd the other side's SF. >=20 > Does that reflect your question, and does it answer it? >=20 >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 1:51 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > Below is scenario that in my view would benefit from a tiebreaking > rule. > > Would appreciate your consideration and feedback whether this is > realistic > > and not breaking PSC: > > - Assume that LSP P is not being used or used by working path of > priority > > N; > > - LER-A detects failure of working path Wi of priority M, where M > N, > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > - almost simulteneously, at least before it receives SF from LER-A, > LER-Z > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing > Wj > > as Fpath; > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > Priority(Wj) > > would not change to protecting Wi path; > > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep > Wi > > as path to protect. > > Is that sequence, scenario correct? Would LER-A and LER-Z converge on > > selecting one path they'd protect? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 4:38 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;=20 > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > EO# I would argue that one should not have LSPs of the "same > > priority". > > > There must be a tiebreaker that can handle all possible conflicts, > no > > > matter what order or how many failures. Once there is a > deterministic > > > mechanism for all cases, it means that all LSPs are of different > > priority. > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > > of > > > two working paths of equal priority. Otherwise, equal priority would > > not > > > preempt one that is already is using the protection path, i.e. FIFO > > will > > > fully work in this case. > > > > > > I think the behavior you describe is more about SMP than 1:n. In 1:n > we'd > > always made the assumption that, in a given protection domain, only a > > single W can be protected at a time. To do otherwise (say, W1 and W2 > > using P) is not possible using PSC signaling since we can only > indicate a > > single LSP in the FPath field. > > > > Nothing precludes multiple protection domains from using the same=20 > > underlying link and/or same endpoints, but that's a network design=20 > > consideration. > > > > > > > > > > eric From maarten.vissers@huawei.com Thu Mar 29 06:08:19 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4921F8A89 for ; Thu, 29 Mar 2012 06:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ7X5MmXaPGJ for ; Thu, 29 Mar 2012 06:08:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 489EC21F89F7 for ; Thu, 29 Mar 2012 06:08:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEM27848; Thu, 29 Mar 2012 09:08:18 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 06:06:15 -0700 Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 06:06:20 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.01.0323.003; Thu, 29 Mar 2012 14:06:10 +0100 From: Maarten vissers To: Maarten vissers , "Eric Osborne (eosborne)" , Gregory Mirsky , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUA== Date: Thu, 29 Mar 2012 13:05:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:08:19 -0000 Below is a copy of the equal priority text in G.873.1 (OTN linear protectio= n): 8.10 Equal priority requests In general, once a switch has been completed due to a request, it will not = be overridden by another request of the same priority (first come, first se= rved behaviour). When equal priority requests occur simultaneously, the con= flict is resolved in favour of the request with the lowest entity number. I= n bidirectional switching, a request received over the APS channel with a l= ower entity number will always override an identical priority local request= with a higher entity number. Equal priority requests for the same entity n= umber from both sides of a bidirectional protection group are both consider= ed valid, and equivalent to a received "RR" from a near-end processing stan= dpoint. Regards, Maarten -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Maa= rten vissers Sent: donderdag 29 maart 2012 14:54 To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov = Weingarten; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 1:n protection in a transport network at the path layer is not a very commo= n protection switching application. This is due to the fact that 1:n protec= tion requires n+1 diverse routed paths. How many of those diverse routed pa= ths will be available in typical transport networks? Not many... very often= two diverse routed paths is all you can get... and this is only truly guar= anteed over time if the network domain is organized as separate A and a B n= etworks. Otherwise maintenance on the network may result in temporary rerou= ting of virtual links, resulting in routing W and P connections over the sa= me fiber, node or duct. With n>2, separate networks can not be used and one has to find n+1 diverse= routed paths through the network and guarantee that neither maintenance ac= tivities, nor network upgrades result in rerouting of the virtual links so = that W and P connections pass through the same fiber, node or duct. 1:n protection has been used in SDH/SONET for SDH/SONET regenerator protect= ion (1:7 and 1:11 systems, in early 90's) and for SDH line card protection = (end of 90's). Regards, Maarten -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: donderdag 29 maart 2012 14:31 To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 I still go back to my point that since only one W can ever use P, there really is no such thing as 'equal priority'. We must have a priority scheme, whether it is the channel number in Fpath or whether it's some other mechanism, so that we know that Wi always beats Wj no matter what order the events occur in. We had initially discussed leaving the exact priority scheme to the protection endpoints, but I see now that that may not work well across vendors.=20 I think we have a few choices: 1) some sort of explicit priority field 2) define priority as the FPath value, lower is better (as Maarten points out, this is the current practice in SDH). Either one of these have costs to them. =20 Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in locking mode means nobody is protected until both ends converge. This also makes things (potentially) very dynamic which is, I think, not what we want in a protocol that has to converge in real time. Doing #2 means that if I have W1...W5 already provisioned and I want to add W3.1, I need to reprovision W4 and W5, which may be disruptive. How often does this sort of thing happen in transport networks? Is it a real problem? eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, March 29, 2012 2:21 PM > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > Hi Eric, > I agree with your logic and that current document handles scenario you > present (prioties of simulteneously failed paths are different) well. But > I still am concerned with case when priorities of Wi and Wj are equal. If > you think that it might present a problem, then I see two possible ways to > address: > - disallow multiple LSPs being assigned equal priority (not the best way); > - define tiebreaking rule(s). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: Thursday, March 29, 2012 5:11 AM > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Let me rewrite the messages a little bit in your example. Rather than > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs in > question. And let's also say that the priority of Wi > Wj, just as you > have done. >=20 > I also note that setting Path=3D=3D0 means you're using locking mode. This is > certainly a valid case, I just want to confirm that it's your intention? >=20 > at t0, no failure. >=20 > at t1, > LER-A sends SF(Wi,0) to LER-Z > AND > LER-Z sends SF(Wj,0) to LER-Z >=20 > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > decided that Wi needs the protect channel. >=20 > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, > shortly after t2. >=20 > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > unidirectional locking preemption case, as in section 3.3.3.2 of the > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > 3.3.3.2 describes as LER-A's behavior at t1. >=20 > In this way, both LER-A and LER-Z converge on protecting Wi. Since it is > locking, no transmission of packets takes place since neither side had > ACKd the other side's SF. >=20 > Does that reflect your question, and does it answer it? >=20 >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 1:51 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > Below is scenario that in my view would benefit from a tiebreaking > rule. > > Would appreciate your consideration and feedback whether this is > realistic > > and not breaking PSC: > > - Assume that LSP P is not being used or used by working path of > priority > > N; > > - LER-A detects failure of working path Wi of priority M, where M > N, > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > - almost simulteneously, at least before it receives SF from LER-A, > LER-Z > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) listing > Wj > > as Fpath; > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > Priority(Wj) > > would not change to protecting Wi path; > > - LER-A receives SF(1,0) from LER-Z and for the same reason would keep > Wi > > as path to protect. > > Is that sequence, scenario correct? Would LER-A and LER-Z converge on > > selecting one path they'd protect? > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 4:38 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > EO# I would argue that one should not have LSPs of the "same > > priority". > > > There must be a tiebreaker that can handle all possible conflicts, > no > > > matter what order or how many failures. Once there is a > deterministic > > > mechanism for all cases, it means that all LSPs are of different > > priority. > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous failure > > of > > > two working paths of equal priority. Otherwise, equal priority would > > not > > > preempt one that is already is using the protection path, i.e. FIFO > > will > > > fully work in this case. > > > > > > I think the behavior you describe is more about SMP than 1:n. In 1:n > we'd > > always made the assumption that, in a given protection domain, only a > > single W can be protected at a time. To do otherwise (say, W1 and W2 > > using P) is not possible using PSC signaling since we can only > indicate a > > single LSP in the FPath field. > > > > Nothing precludes multiple protection domains from using the same > > underlying link and/or same endpoints, but that's a network design > > consideration. > > > > > > > > > > eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls